[mpls] Protocol Action: 'Signaling LDP Label Advertisement Completion' to Proposed Standard

The IESG <iesg-secretary@ietf.org> Wed, 02 September 2009 14:39 UTC

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <20090902143956.B76203A6BA7@core3.amsl.com>
Date: Wed, 02 Sep 2009 07:39:56 -0700
Cc: mpls mailing list <mpls@ietf.org>, mpls chair <mpls-chairs@tools.ietf.org>, Internet Architecture Board <iab@iab.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [mpls] Protocol Action: 'Signaling LDP Label Advertisement Completion' to Proposed Standard
Precedence: list

The IESG has approved the following document:

- 'Signaling LDP Label Advertisement Completion '
   <draft-ietf-mpls-ldp-end-of-lib-04.txt> as a Proposed Standard


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

The IESG contact persons are Adrian Farrel and Ross Callon.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-mpls-ldp-end-of-lib-04.txt

Technical Summary

   There are situations following LDP session establishment where it
   would be useful for a Label Distribution Protocol (LDP) speaker to 
   know when its peer has advertised all of its labels.  For example, 
   when an LDP speaker is using LDP-IGP synchronization procedures, it 
   would be useful for the speaker to know when its peer has completed 
   advertisement of its IP label bindings.

   Similarly, after an LDP session is re-established when LDP Graceful 
   Restart is in effect, it would be helpful for each peer to signal the 
   other after it has advertised all its label bindings.

   The LDP specification (RFC 5036) provides no mechanism for an LDP 
   speaker to notify a peer when it has completed its initial label 
   advertisements to that peer.

   This document specifies use of a Notification message with the "End-
   of-LIB" Status Code for an LDP speaker to signal completion of its 
   label advertisements following session establishment.

   RFC 5036 implicitly assumes that new Status Codes will be defined 
   over the course of time.  However, it does not explicitly define the 
   behavior of an LDP speaker which does not understand the Status Code 
   in a Notification message.  To avoid backward compatibility issues 
   this document specifies use of the LDP capability mechanism at 
   session establishment time for informing a peer that an LDP speaker 
   is capable of handling a Notification message that carries an 
   unrecognized Status Code.

Working Group Summary

   Nothing of note.

Document Quality
   There are no implementations that we know of. We have polled the 
   WG list but received no responses

Personnel

   Loa Andersson (loa@pi.nu) is the Document Shepherd.
   Adrian Farrel (adrian.farrel@huawei.com) is the Responsible Area 
   Director.

[mpls] Protocol Action: 'Signaling LDP Label Adve… The IESG