Signaling LDP Label Advertisement Completion
Draft of message to be sent after approval:
From: The IESG <email@example.com> To: IETF-Announce <firstname.lastname@example.org> Cc: Internet Architecture Board <email@example.com>, RFC Editor <firstname.lastname@example.org>, mpls mailing list <email@example.com>, mpls chair <firstname.lastname@example.org> Subject: Protocol Action: 'Signaling LDP Label Advertisement Completion' to Proposed Standard 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 (email@example.com) is the Document Shepherd. Adrian Farrel (firstname.lastname@example.org) is the Responsible Area Director.