--- 1/draft-ietf-mpls-ldp-capabilities-00.txt 2008-02-08 20:12:10.000000000 +0100 +++ 2/draft-ietf-mpls-ldp-capabilities-01.txt 2008-02-08 20:12:10.000000000 +0100 @@ -1,25 +1,27 @@ - Network Working Group Bob Thomas Internet Draft Cisco Systems, Inc. -Expiration Date: November 2007 - S. Aggarwal +Expiration Date: August 2008 +Intended Status: Proposed Standard S. Aggarwal Juniper Networks R. Aggarwal Juniper Networks J.L. Le Roux France Telecom + + February 2008 + LDP Capabilities - draft-ietf-mpls-ldp-capabilities-00.txt + draft-ietf-mpls-ldp-capabilities-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -32,21 +34,21 @@ material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice - Copyright (C) The IETF TRUST (2007). + Copyright (C) The IETF TRUST (2008). Abstract A number of enhancements to the Label Distribution Protocol (LDP) have been proposed. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. At present LDP has no guidelines for advertising such enhancements at LDP session initialization time. There is also no mechanism to enable and disable enhancements after the session is established. This document @@ -70,42 +72,42 @@ 12 Security Considerations ....................................... 10 13 IANA Considerations ........................................... 10 14 Acknowledgements .............................................. 11 15 References .................................................... 11 16 Author Information ............................................ 12 17 Intellectual Property Statement ............................... 12 18 Full Copyright Statement ...................................... 13 1. Introduction - A number of enhancements to LDP as specified in [RFC3036] have been + A number of enhancements to LDP as specified in [RFC5036] have been proposed. These include LDP Graceful Restart [RFC3478], Fault Tolerant LDP [RFC3479], multicast extensions [MLDP], signaling for layer 2 circuits [RFC4447], a method for learning labels advertised by next next hop routers in support of fast reroute node protection [NNHOP], upstream label allocation [UPSTREAM_LDP], and extensions for signaling inter-area LSPs [IALDP]. Some have been implemented, and some are advancing toward standardization. It is likely that additional enhancements will be proposed in the future. At present LDP has no guidelines for advertising such enhancements at LDP session initialization time. There is also no mechanism to enable and disable enhancements after the session is established. This document provides guidelines for advertising LDP enhancements at session initialization time. It also defines a mechanism to enable and disable enhancements after LDP session establishment. LDP capability advertisement provides means for an LDP speaker to announce what it can receive and process. It also provides means for a speaker to inform peers of deviations from behavior specified by - [RFC3036]. An example of such a deviation is LDP graceful restart + [RFC5036]. An example of such a deviation is LDP graceful restart where a speaker retains MPLS forwarding state for LDP-signaled LSPs when its LDP control plane goes down. It is important to point out that not all LDP enhancements require capability advertisement. For example, upstream label allocation does but inbound label filtering, where a speaker installs forwarding state for only certain FECs, does not. 2. Specification Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", @@ -187,25 +189,25 @@ |U|F| TLV Code Point | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Reserved | | +-+-+-+-+-+-+-+-+ Capability Data | | +-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: U and F bits: - As specified in [RFC3036]. + As specified in [RFC5036]. TLV Code Point: - The TLV type which identifies a specific capability. The "IANA - Considerations" section of [RFC3036] specifies the assignment of + The TLV type, which identifies a specific capability. The "IANA + Considerations" section of [RFC5036] specifies the assignment of code points for LDP TLVs. S-bit: The State Bit indicates whether the sender is advertising or withdrawing the capability corresponding to the TLV Code Point. The State bit is used as follows: 1 - The TLV is advertising the capability specified by the TLV Code Point. 0 - The TLV is withdrawing the capability specified by the @@ -310,21 +312,21 @@ Notification message SHOULD be Unsupported Capability, and the message SHOULD contain the unsupported capabilities (see Section 9 for more details). In this case the session SHOULD NOT be re- established automatically. How the session is re-established is beyond the scope of this document. It depends on the LDP capability and MUST be specified along with the procedures specifying the capability. An LDP speaker that supports capability advertisement and includes a Capability Parameter in its Initialization message SHOULD set the TLV - U bit to 1. This ensures that an [RFC3036] compliant peer that does + U bit to 1. This ensures that an [RFC5036] compliant peer that does not support the capability mechanism will ignore the Capability Parameter and allow the session to be established. 8. Procedures for Capability Parameters in Capability Messages An LDP speaker MUST NOT send a Capability message to a peer unless its peer had advertised the Dynamic Capability Announcement capability in its session Initialization message (see Section 10). An LDP speaker MAY send a Capability message to a peer if its peer @@ -388,35 +390,35 @@ capability cannot be disabled. An LDP speaker that receives a Capability message from a peer that includes the Dynamic Capability Announcement Parameter SHOULD silently ignore the parameter and process any other Capability Parameters in the message. 11. Backward Compatibility From the point of view of the LDP capability advertisement mechanism - an [RFC3036] compliant peer has label distribution for IPv4 enabled - by default. To ensure compatibility with an [RFC3036] compliant peer + an [RFC5036] compliant peer has label distribution for IPv4 enabled + by default. To ensure compatibility with an [RFC5036] compliant peer LDP implementations that support capability advertisement have label distribution for IPv4 enabled until it is explicitly disabled and MUST assume that their peers do as well. Section 3 identifies a set of Backward Compatibility TLVs that may appear in Initialization messages in the role of a Capability Parameter. This permits existing LDP enhancements that use an ad hoc mechanism for enabling capabilities at sesssion initialization time to continue to do so. 12. Security Considerations - The security considerations described in [RFC3036] that apply to the + The security considerations described in [RFC5036] that apply to the base LDP specification apply to the capability mechanism described in this document. 13. IANA Considerations This document specifies the following which require code points assigned by IANA: - LDP message code point for the Capability message. The authors request message type 0x0202 for the Capability message. @@ -432,22 +434,22 @@ 14. Acknowledgements The authors wish to thank Enke Chen, Vanson Lim, Ina Minei, Bin Mo, Yakov Rekhter, and Eric Rosen for their comments. 15. References Normative References - [RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A. and - Thomas, B., "LDP Specification", RFC 3036, January 2001. + [RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP + Specification", RFC 5036, September 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC2119, March 1997. [RFC3479] Farrel, A., Editor, "Fault Tolerance for the Label Distribution Protocol (LDP)", RFC 3479, February 2003. Informative References [IALDP] Decraene, B., Le Roux, JL., Minei, I, "LDP Extensions for @@ -517,21 +519,21 @@ http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 18. Full Copyright Statement - Copyright (C) The IETF Trust (2007). + Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT