Return Path Specified Label Switched Path (LSP) Ping
draft-ietf-mpls-return-path-specified-lsp-ping-15

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    mpls mailing list <mpls@ietf.org>,
    mpls chair <mpls-chairs@tools.ietf.org>
Subject: Protocol Action: 'Return Path Specified LSP Ping' to Proposed Standard (draft-ietf-mpls-return-path-specified-lsp-ping-15.txt)

The IESG has approved the following document:
- 'Return Path Specified LSP Ping'
  (draft-ietf-mpls-return-path-specified-lsp-ping-15.txt) as Proposed
Standard

This document is the product of the Multiprotocol Label Switching Working
Group.

The IESG contact persons are Adrian Farrel and Stewart Bryant.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-mpls-return-path-specified-lsp-ping/


Technical Summary

   This document defines extensions to the data-plane failure-detection
   protocol for Multiprotocol Label Switching (MPLS) Label Switched
   Paths (LSPs) known as "LSP Ping".  These extensions allow selection
   of the LSP to use for the echo reply return path.  Enforcing a
   specific return path can be used to verify bidirectional connectivity
   and also increase LSP ping robustness.

Working Group Summary 

  There has not been anything in the working group process that 
  needs to be mentioned, other than we had a strong support to 
  accept it as a working group draft, after that the discussion 
  on the mailing were low for almost a year, but has pick up lately 
  and we have had a good discussion, where all comments been 
  focused on improving the and no indication that the draft is not 
  needed.  

  The document has support in the working group, and operators has 
  participated in writing it, and has been well reviewed. 
  After improving the IANA section (mostly off-line) the document 
  shepherd now believes we have a stable document ready to be 
  published. 

  A further two months' discussion focused on a discussion of the IANA 
  section of this document. We have earlier made "early allocations" 
  of code points for this document, after discussion we have 
  decided not use them, but reuse (identical) sub-TLVs allocated 
  by RFC4379. A spin-off of the IANA discussion for this 
  document is that we are discussing/thiking of writing an update 
  to the IANA allocation of RFC4379. 

  The AD review raised still further issues with the IANA section and
  this delayed the document by many months while the working group
  grappled with an understanding of how the registries were supposed
  to work. Agreement has finally been reached leading to the latest 
  revision and a new draft in the working group to clarify the registries
  for future generations.

Document Quality 

  This is a very minor update to the LSP-Ping that does not have 
  any affect on the operations of existing LSP Ping implementations 
  and deployments, even if nodes with the new functionality are 
  introduced. 

  The working group mailing list has been polled for existing 
  implementations and intentions to implement this specification. 

  We know of vendors that intend to implement and at least one 
  operator that plans to deploy this functionality.

Personnel 

  Loa Andersson (loa@pi.nu) is the document shepherd. 
  Adrian Farrel (adrian@olddog.co.uk) is the responsible AD. 

RFC Editor Note

Section 3.2.
OLD
The A bit and B bit set MUST NOT both be set
NEW
The A flag and B flag MUST NOT both be set


Section 6.4
OLD
   The range of 0x0008-0xfffb is not allocated and reserved for future
   extensions and is allocated via Standard Action, the range of 0xfffc-
   0xffff is for Experimental Use.
NEW
   The range of 0x0006-0xfffb is not allocated and reserved for future
   extensions and is allocated via Standard Action, the range of 0xfffc-
   0xffff is for Experimental Use.
END

===

IANA Note

IANA, please see the text in the RFC Editor Note