--- 1/draft-ietf-mpls-ldp-applicability-label-adv-02.txt 2014-04-02 10:14:35.416231350 -0700 +++ 2/draft-ietf-mpls-ldp-applicability-label-adv-03.txt 2014-04-02 10:14:35.436231839 -0700 @@ -1,32 +1,32 @@ MPLS Working Group Kamran Raza Internet Draft Sami Boutros -Updates: 5036, 4447, 5918, 6388, 3212 Luca Martini +Updates: 3212, 4447, 5036, 5918, 6388, 7140 Luca Martini Intended status: Standards Track Cisco Systems, Inc. -Expires: July 19, 2014 +Expires: October 01, 2014 Nicolai Leymann Deutsche Telekom - January 20, 2014 + April 02, 2014 Label Advertisement Discipline for LDP FECs - draft-ietf-mpls-ldp-applicability-label-adv-02.txt + draft-ietf-mpls-ldp-applicability-label-adv-03.txt Abstract The label advertising behavior of an LDP speaker for a given FEC is governed by the FEC type and not necessarily by the LDP session's negotiated label advertisement mode. This document updates RFC 5036 - to make that fact clear, as well as updates RFC 3212, RFC 4447, - RFC 5918, and RFC 6388 by specifying the label advertisement mode - for all currently defined FECs. + to make that fact clear, as well as updates RFC 3212, RFC 4447, RFC + 5918, RFC 6388, and RFC 7140 by specifying the label advertisement + mode for all currently defined LDP FEC types. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -35,21 +35,21 @@ months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 - This Internet-Draft will expire on July 19, 2014. + This Internet-Draft will expire on October 01, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,65 +59,66 @@ Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction 2 2. Label Advertisement Discipline 3 2.1. Update to RFC-5036 3 2.2. Specification for LDP FECs 4 3. Security Considerations 4 - 4. IANA Considerations 4 - 5. References 5 - 5.1. Normative References 5 - 5.2. Informative References 5 - 6. Acknowledgments 5 + 4. IANA Considerations 5 + 5. References 7 + 5.1. Normative References 7 + 5.2. Informative References 7 + 6. Acknowledgments 8 1. Introduction Label Distribution Protocol (LDP) [RFC5036] allows label advertisement mode negotiation at the time of session establishment. LDP specification also dictates that only single label advertisement mode is negotiated, agreed and used for a given LDP session between two LSRs. The negotiated label advertisement mode defined in RFC 5036 and carried in the LDP Initialization message is only indicative. It indicates how the LDP speakers on a session will advertise labels for some FECs, but it is not a rule that restricts the speakers to behave in a specific way. Furthermore, for some FEC types the advertising behavior of the LDP speaker is governed by the FEC type and not by the negotiated behavior. - This document updates [RFC5036] to make that fact clear, and updates - [RFC3212], [RFC4447], [RFC5036], [RFC5918], and [RFC6388] to indicate - for each FEC type that has already been defined whether the label - binding advertisements for the FEC are constrained by the negotiated - label advertisement mode or not. Furthermore, this document specifies - the label advertisement mode to be used for all currently defined - LDP FECs. + This document updates [RFC5036] to make that fact clear, as well as + updates [RFC3212], [RFC4447], [RFC5918], [RFC6388], and [RFC7140] to + indicate for each FEC type that has already been defined whether the + label binding advertisements for the FEC are constrained by the + negotiated label advertisement mode or not. Furthermore, this + document specifies the label advertisement mode to be used for all + currently defined FECs. 2. Label Advertisement Discipline To remove any ambiguity and conflict regarding label advertisement discipline amongst different FEC types sharing a common LDP session, this document specifies a label advertisement disciplines for FEC types. This document introduces following types for specifying a label advertisement discipline for a FEC type: - DU (Downstream Unsolicited) - DoD (Downstream On Demand) - As negotiated (DU or DoD) - Upstream ([RFC6389]) - Not Applicable + - Unknown 2.1. Update to RFC-5036 The section 3.5.3 of [RFC5036] is updated to add following two statements under the description of "A, Label Advertisement Discipline": - Each document defining an LDP FEC must state the applicability of the negotiated label advertisement discipline for label binding advertisements for that FEC. If the negotiated label @@ -133,63 +134,133 @@ +----------+----------+--------------------------------+ | 0x01 | Wildcard | Not applicable | | 0x02 | Prefix | As negotiated (DU or DoD) | +----------+----------+--------------------------------+ 2.2. Specification for LDP FECs Following is the specification of label advertisement disciplines to be used for currently defined LDP FEC types. - +------+----------------+--------------------------------+------+ - | FEC | FEC Name | Label advertisement discipline |RFC | - | Type | | | | - +------+----------------+--------------------------------+------+ - | 0x01 | Wildcard | Not applicable | 5036 | - | 0x02 | Prefix | As negotiated (DU or DoD) | 5036 | - | 0x04 | CR-LSP | DoD | 3212 | - | 0x05 | Typed Wildcard | Not applicable | 5918 | - | 0x06 | P2MP | DU | 6388 | - | 0x07 | MP2MP-up | DU | 6388 | - | 0x08 | MP2MP-down | DU | 6388 | - | 0x80 | PWid | DU | 4447 | - | 0x81 | Gen. PWid | DU | 4447 | - +------+----------------+--------------------------------+------+ + FEC FEC Label advertisement Notes + Type Name discipline + ---- ---------------- ------------------- ---------------------- + 0x01 Wildcard Not applicable + 0x02 Prefix As negotiated + (DU or DoD) + 0x04 CR-LSP DoD + 0x05 Typed Wildcard Not applicable + 0x06 P2MP DU + 0x07 MP2MP-up DU + 0x08 MP2MP-down DU + 0x09 HSMP-upstream DU + 0x10 HSMP-downstream DU, Upstream [RFC7140] Section 4 + 0x80 PWid DU + 0x81 Gen. PWid DU + 0x82 P2MP PW Upstream Upstream [ID.pwe3-p2mp-pw] + 0x84 P2MP PW Downstream DU [ID.pwe3-p2mp-pw] + 0x83 Protection DU [ID.pwe3-endpoint- + fast-protection] - The above table also lists the RFC (in which given FEC type is - defined), and hence this document updates all the above listed RFCs. + This document updates the RFCs in which above FECs are defined. 3. Security Considerations This document specification only clarifies the applicability of LDP session's label advertisement mode, and hence does not add any LDP security mechanics and considerations to those already defined in the LDP specification [RFC5036]. 4. IANA Considerations This document mandates the specification of a label advertisement discipline for each defined FEC type, and hence extends IANA's "Forwarding Equivalence Class (FEC) Type Name Space" registry under IANA's "Label Distribution Protocol (LDP) Parameters" as follows: - - Add a new column titled "Label advertisement discipline" with + - Add a new column titled "Label Advertisement Discipline" with following possible values: o DU o DoD o As negotiated (DU or DoD) o Upstream o Not applicable + o Unknown - For the existing FEC types, populate this column with the values listed under section 2.2. + - Keep all other columns of the registry in place and populated + as currently. + + For the currently assigned FEC types, the updated registry looks + like: + + +=====+====+===============+==============+=========+============+ + |Value|Hex | Name |Label |Reference|Notes/ | + | | | |Advertisement | |Registration| + | | | |Discipline | |Date | + +=====+====+===============+==============+=========+============+ + | 0 |0x00|Reserved | | | | + +-----+----+---------------+--------------+---------+------------+ + | 1 |0x01|Wildcard |Not applicable|[RFC5036]| | + | | | | |[thisRFC]| | + +-----+----+---------------+--------------+---------+------------+ + | 2 |0x02|Prefix |As negotiated |[RFC5036]| | + | | | |(DU or DoD) |[thisRFC]| | + +-----+----+---------------+--------------+---------+------------+ + | 4 |0x04|CR-LSP |DoD |[RFC3212]| | + | | | | |[thisRFC]| | + +-----+----+---------------+--------------+---------+------------+ + +-----+----+---------------+--------------+---------+------------+ + | 5 |0x05|Typed Wildcard |Not applicable|[RFC5918]| | + | | |FEC Element | |[thisRFC]| | + +-----+----+---------------+--------------+---------+------------+ + | 6 |0x06|P2MP |DU |[RFC6388]| | + | | | | |[thisRFC]| | + +-----+----+---------------+--------------+---------+------------+ + | 7 |0x07|MP2MP-up |DU |[RFC6388]| | + | | | | |[thisRFC]| | + +-----+----+---------------+--------------+---------+------------+ + | 8 |0x08|MP2MP-down |DU |[RFC6388]| | + | | | | |[thisRFC]| | + +-----+----+---------------+--------------+---------+------------+ + | 9 |0x09|HSMP-upstream |DU |[RFC7140]| | + | | | | |[thisRFC]| | + +-----+----+---------------+--------------+---------+------------+ + | 10 |0x0A|HSMP-downstream|DU, Upstream |[RFC7140]| | + | | | | |[thisRFC]| | + +-----+----+---------------+--------------+---------+------------+ + | 128 |0x80|PWid |DU |[RFC4447]| | + | | |FEC Element | |[thisRFC]| | + +-----+----+---------------+--------------+---------+------------+ + | 129 |0x81|Generalized |DU |[RFC4447]| | + | | |PWid | |[thisRFC]| | + | | |FEC Element | | | | + +-----+----+---------------+--------------+---------+------------+ + | 130 |0x82|P2MP PW |Upstream |[draft- | | + | | |Upstream | |ietf-pwe3| | + | | |FEC Element | |-p2mp-pw]| | + | | | | |[thisRFC]| | + +-----+----+---------------+--------------+---------+------------+ + | 131 |0x83|Protection |DU |[draft-ietf| | + | | |FEC Element | |-pwe3-end | | + | | | | |point-fast | | + | | | | |protection]| | + | | | | |[thisRFC] | | + +-----+----+---------------+--------------+---------+------------+ + | 132 |0x84|P2MP PW |DU |[draft- | | + | | |Downstream | |ietf-pwe3| | + | | |FEC Element | |-p2mp-pw]| | + | | | | |[thisRFC]| | + +-----+----+---------------+--------------+---------+------------+ + 5. References 5.1. Normative References [RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP Specification", RFC 5036, September 2007. [RFC3212] B. Jamoussi, et al., "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002 @@ -200,20 +271,33 @@ [RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution Protocol Typed Wildcard FEC", RFC 5918, August 2010. [RFC6388] I. Minei, I. Wijnands, K. Kompella, and B. Thomas, "LDP Extensions for P2MP and MP2MP LSPs", RFC 6388, November 2011. [RFC6389] R. Aggarwal, and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, November 2011. + [RFC7140] L. Jin, F. Jounay, I. Wijnands , and N. Leymann, "LDP + Extensions for Hub and Spoke Multipoint Label Switched + Path", RFC 7140, March 2014. + + [ID.pwe3-p2mp-pw] S. Sivabalan et al., "Signaling Root-Initiated + Point-to-Multipoint PseudoWire using LDP", draft-ietf- + pwe3-p2mp-pw-04, Work in progress, March 2012. + + [ID.pwe3-endpoint-fast-protection] Y. Shen, R. Aggarwal, W. + Henderickx, and Y. Jiang, "PW Endpoint Fast Failure + Protection", draft-ietf-pwe3-endpoint-fast-protection-00, + Work in progress, December 2013. + 5.2. Informative References None. 6. Acknowledgments We acknowledge Eric Rosen and Rajiv Asati for their initial review and input on the document. This document was prepared using 2-Word-v2.0.template.dot.