Label Switched Path (LSP) Self-Ping
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: "IETF-Announce" <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, "The IESG" <email@example.com>, firstname.lastname@example.org, email@example.com Subject: Protocol Action: 'LSP Self-Ping' to Proposed Standard (draft-ietf-mpls-self-ping-06.txt) The IESG has approved the following document: - 'LSP Self-Ping' (draft-ietf-mpls-self-ping-06.txt) as Proposed Standard This document is the product of the Multiprotocol Label Switching Working Group. The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah Brungard. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-mpls-self-ping/
Technical Summary This document fixes a problem relating to when in the establishment of an LSP, traffic may be sent on an LSP. When certain RSVP-TE optimizations are implemented, ingress LSRs can receive RSVP RESV messages before forwarding state has been installed on all downstream nodes. According to the RSVP-TE specification, the ingress LSR can forward traffic through an LSP as soon as it receives a RESV message. However, if the ingress LSR forwards traffic through the LSP before forwarding state has been installed on all downstream nodes, traffic can be lost. The document describes new procedures called LSP Self-ping. When an ingress LSR receives an RESV message, it can invoke LSP Self-ping procedures to ensure that forwarding state has been installed on all downstream nodes. LSP Self-ping is an extremely light-weight mechanism. It does not consume control plane resources on transit or egress LSRs. Even though there is a naming similarity between "MPLS Self Ping" and "MPLS LSP Ping" the protocols really has nothing in common. The protocols diagnose a different set of problems, listen for input on different UDP ports and behave differently. The only thing that they have in common is that they are named similarly. Working Group Summary The only thing worth mentioning here is that there were a lot of discussion taking place at the time when the draft was accepted as a working group document. Especially there were discussion on whether there is an overlap with BFD mechanisms in documents that are developed in in the BFD working group. It is understood that on a very high level such an overlap exists, but when we get down to details this draft is quite separate from what is is done in BFD. The MPLS working converged on the understanding that this draft is very specific for LSP establishment with RSVP-TE and fills a gap that needs to be filled. The BFD mechanisms are much more generic. The support for the draft in the wg is quite good, and the progress through the working group has been easy, once the discussion around adopting the draft as a working document had converged. Document Quality Yes there is at least one implementation. We have started an implementation poll and will update the Write-Up once we have further information. The review of the document is quite good, it has been through the mpls review team review and been discussed on the mailing list. No further specialist reviews are necessary. Personnel Loa Andersson is the Document Shepherd. Deborah Brungard is the responsible AD.