Label Switched Path (LSP) Self-Ping
draft-ietf-mpls-self-ping-06

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: "IETF-Announce" <ietf-announce@ietf.org>
Cc: mpls@ietf.org, draft-ietf-mpls-self-ping@ietf.org, db3546@att.com, mpls-chairs@ietf.org, "The IESG" <iesg@ietf.org>, rfc-editor@rfc-editor.org, loa@pi.nu
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/

Ballot Text

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.

RFC Editor Note