MPLS Working Group Kamran RazaInternetDraft SamiEngineering Task Force (IETF) K. Raza Request for Comments: 7358 S. Boutros Updates: 3212, 4447, 5036, 5918, 6388, 7140LucaL. MartiniIntended status:Category: Standards Track Cisco Systems, Inc.Expires: October 01, 2014 NicolaiISSN: 2070-1721 N. Leymann Deutsche TelekomApril 02,October 2014 Label Advertisement Discipline for LDPFECs draft-ietf-mpls-ldp-applicability-label-adv-03.txtForwarding Equivalence Classes (FECs) Abstract The label advertising behavior of an LDP speaker for a givenFECForwarding Equivalence Class (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 factclear, as well asclear. It also updatesRFCRFCs 3212,RFC4447,RFC5918,RFC6388, andRFC7140 by specifying the label advertisement mode for all currently defined LDP FEC types. Status ofthisThis Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product 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. Internet-Drafts are draft documents valid for a maximum(IETF). It represents the consensus ofsix monthsthe IETF community. It has received public review andmay be updated, replaced, or obsoletedhas been approved for publication byother documents at any time. Itthe Internet Engineering Steering Group (IESG). Further information on Internet Standards isinappropriate to use Internet-Drafts as reference material or to cite them other than as "workavailable inprogress." The listSection 2 of RFC 5741. Information about the currentInternet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The liststatus ofInternet-Draft Shadow Directories canthis document, any errata, and how to provide feedback on it may beaccessedobtained athttp://www.ietf.org/shadow.html This Internet-Draft will expire on October 01, 2014.http://www.rfc-editor.org/info/rfc7358. 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction2....................................................2 2. Label Advertisement Discipline3..................................3 2.1. Update toRFC-5036 3RFC 5036 .........................................3 2.2. Specification for LDP FECs4.................................4 3. Security Considerations4.........................................4 4. IANA Considerations5.............................................4 5. References7......................................................6 5.1. Normative References7.......................................6 5.2. Informative References7 6......................................7 Acknowledgments8....................................................7 Authors' Addresses .................................................7 1. Introduction The Label Distribution Protocol (LDP) [RFC5036] allows label advertisement mode negotiation at the time of session establishment. The LDP specification also dictates that only a single label advertisement modeisbe negotiated, agreed upon, and used for a given LDP session between twoLSRs.Label Switching Routers (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 someFECs,Forwarding Equivalence Classes (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 factclear, as well asclear. It also updates [RFC3212], [RFC4447], [RFC5918], [RFC6388], and [RFC7140] toindicateindicate, for each FEC type that has already beendefineddefined, 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 a label advertisement disciplineamongstamong different FEC types sharing a common LDP session, this document specifies a label advertisementdisciplinesdiscipline for FEC types. This document introduces the following types for specifying a label advertisement discipline for a FEC type: - DU (Downstream Unsolicited) - DoD (DownstreamOnon Demand) - As negotiated (DU or DoD) - Upstream ([RFC6389]) - NotApplicableapplicable - Unknown 2.1. Update toRFC-5036 The sectionRFC 5036 Section 3.5.3 of [RFC5036] is updated to add the 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 advertisement discipline does not apply to the FEC, the document must also explicitly state the discipline to be used for the FEC. - This document defines the label advertisement discipline for the following FEC types: +----------+----------+--------------------------------+ | FEC Type | FEC Name | Labeladvertisement disciplineAdvertisement Discipline | +----------+----------+--------------------------------+ | 0x01 | Wildcard | Not applicable | | 0x02 | Prefix | As negotiated (DU or DoD) | +----------+----------+--------------------------------+ 2.2. Specification for LDP FECsFollowing is the specification ofThe label advertisementdisciplines to be useddiscipline for currently defined LDP FECtypes. 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]types is listed in Section4 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]4. This document updates the respective RFCs in whichabovethese FECs are introduced and defined. 3. Security Considerations This documentspecificationonly clarifies the applicability of an LDP session's label advertisementmode,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 FECtype,type and henceextendsIANA's "Forwarding Equivalence Class (FEC) Type Name Space" registry under IANA's "Label Distribution Protocol (LDP) Parameters" registry has been extended as follows: -AddAdded a new column titled "Label Advertisement Discipline" with the 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, populateMade thiscolumn withdocument an additional reference for thevalues listed under section 2.2. - Keepregistry itself and for all affected registrations. - Kept other columns of the registry in place and populated ascurrently.they were. For the currently assigned FEC types, the updated registry looks like:+=====+====+===============+==============+=========+============++=====+====+===============+==============+===========+============+ |Value|Hex | Name |Label|Reference|Notes/| Reference |Notes/ | | | | |Advertisement | |Registration| | | | |Discipline | |Date |+=====+====+===============+==============+=========+============++=====+====+===============+==============+===========+============+ | 0 |0x00|Reserved | | | |+-----+----+---------------+--------------+---------+------------++-----+----+---------------+--------------+-----------+------------+ | 1 |0x01|Wildcard |Notapplicable|[RFC5036]|applicable| [RFC5036] | | | | | ||[thisRFC]||+-----+----+---------------+--------------+---------+------------+[RFC7358] | | +-----+----+---------------+--------------+-----------+------------+ | 2 |0x02|Prefix |As negotiated|[RFC5036]|| [RFC5036] | | | | | |(DU or DoD)|[thisRFC]||+-----+----+---------------+--------------+---------+------------+[RFC7358] | | +-----+----+---------------+--------------+-----------+------------+ | 4 |0x04|CR-LSP |DoD|[RFC3212]|| [RFC3212] | | | | | | | [RFC7358] ||[thisRFC]||+-----+----+---------------+--------------+---------+------------+ +-----+----+---------------+--------------+---------+------------++-----+----+---------------+--------------+-----------+------------+ | 5 |0x05|Typed Wildcard |Notapplicable|[RFC5918]|applicable| [RFC5918] | | | | |FEC Element ||[thisRFC]||+-----+----+---------------+--------------+---------+------------+[RFC7358] | | +-----+----+---------------+--------------+-----------+------------+ | 6 |0x06|P2MP |DU|[RFC6388]|| [RFC6388] | | | | | ||[thisRFC]||+-----+----+---------------+--------------+---------+------------+[RFC7358] | | +-----+----+---------------+--------------+-----------+------------+ | 7 |0x07|MP2MP-up |DU|[RFC6388]|| [RFC6388] | | | | | | ||[thisRFC]|[RFC7358] |+-----+----+---------------+--------------+---------+------------+| +-----+----+---------------+--------------+-----------+------------+ | 8 |0x08|MP2MP-down |DU|[RFC6388]|| [RFC6388] | | | | | ||[thisRFC]||+-----+----+---------------+--------------+---------+------------+[RFC7358] | | +-----+----+---------------+--------------+-----------+------------+ | 9 |0x09|HSMP-upstream |DU|[RFC7140]|| [RFC7140] | 2014-01-09 | | ||[thisRFC]||+-----+----+---------------+--------------+---------+------------+| | [RFC7358] | | +-----+----+---------------+--------------+-----------+------------+ | 10 |0x0A|HSMP-downstream|DU, Upstream|[RFC7140]|| [RFC7140] | 2014-01-09 | | | ||[thisRFC]||+-----+----+---------------+--------------+---------+------------+| [RFC7358] | | +-----+----+---------------+--------------+-----------+------------+ | 128 |0x80|PWid |DU|[RFC4447]|| [RFC4447] | | | | |FEC Element ||[thisRFC]||+-----+----+---------------+--------------+---------+------------+[RFC7358] | | +-----+----+---------------+--------------+-----------+------------+ | 129 |0x81|Generalized |DU|[RFC4447]|| [RFC4447] | | | | |PWid ||[thisRFC]|| [RFC7358] | | | | |FEC Element | | | |+-----+----+---------------+--------------+---------+------------++-----+----+---------------+--------------+-----------+------------+ | 130 |0x82|P2MP PW |Upstream|[draft-| [P2MP-PW] | 2009-06-03 | ||Upstream||ietf-pwe3||Upstream | | [RFC7358] ||FEC Element||-p2mp-pw]|| | |FEC Element | | ||[thisRFC]||+-----+----+---------------+--------------+---------+------------++-----+----+---------------+--------------+-----------+------------+ +-----+----+---------------+--------------+-----------+------------+ | 131 |0x83|Protection |DU|[draft-ietf||[FAST-PROT]| 2010-02-26 | | | |FEC Element ||-pwe3-end | | | | | | |point-fast| [RFC7358] | || | | |protection]| | | | | | |[thisRFC] | | +-----+----+---------------+--------------+---------+------------++-----+----+---------------+--------------+-----------+------------+ | 132 |0x84|P2MP PW |DU|[draft-| [P2MP-PW] | 2014-04-04 | ||Downstream||ietf-pwe3||Downstream | | [RFC7358] ||FEC Element||-p2mp-pw]|| | |FEC Element | | ||[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.,B., Ed., Andersson, L., Callon, R., Dantu, R., Wu, L., Doolan, P., Worster, T., Feldman, N., Fredette, A., Girish, M., Gray, E., Heinanen, J., Kilty, T., and A. Malis, "Constraint-Based LSP Setup using LDP", RFC 3212, January20022002, <http://www.rfc-editor.org/info/rfc3212>. [RFC4447]L.Martini,Editor, E.L., Ed., Rosen, E., El-Aawar,T.N., Smith, T., and G. Heron, "Pseudowire Setup and MaintenanceusingUsing the Label DistributionProtocol",Protocol (LDP)", RFC 4447, April2006.2006, <http://www.rfc-editor.org/info/rfc4447>. [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>. [RFC5918]R.Asati,I.R., Minei, I., and B. Thomas, "Label Distribution ProtocolTyped Wildcard FEC",(LDP) 'Typed Wildcard' Forward Equivalence Class (FEC)", RFC 5918, August2010.2010, <http://www.rfc-editor.org/info/rfc5918>. [RFC6388]I. Minei, I.Wijnands,K.IJ., Ed., Minei, I., Ed., Kompella, K., and B. Thomas,"LDP"Label Distribution Protocol Extensions forP2MPPoint-to-Multipoint andMP2MP LSPs",Multipoint-to-Multipoint Label Switched Paths", RFC 6388, November2011.2011, <http://www.rfc-editor.org/info/rfc6388>. [RFC6389]R.Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, November2011.2011, <http://www.rfc-editor.org/info/rfc6389>. [RFC7140]L.Jin,F.L., Jounay,I. Wijnands ,F., Wijnands, IJ., and N. Leymann, "LDP Extensions for Hub and Spoke Multipoint Label Switched Path", RFC 7140, March2014. [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.2014, <http://www.rfc-editor.org/info/rfc7140>. 5.2. Informative References [FAST-PROT] Shen,R.Y., Aggarwal,W.R., Henderickx, W., and Y. Jiang, "PW Endpoint Fast Failure Protection",draft-ietf-pwe3-endpoint-fast-protection-00,Work inprogress, December 2013. 5.2. Informative References None. 6.Progress, draft-ietf-pwe3-endpoint-fast-protection-01, July 2014. [P2MP-PW] Sivabalan, S., Ed., Boutros, S., Ed., Martini, L., Konstantynowicz, M., Del Vecchio, G., Nadeau, T., Jounay, F., Niger, P., Kamite, Y., Jin, L., Vigoureux, M., Ciavaglia, L., Delord, S., and K. Raza, "Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP", Work in Progress, draft-ietf-pwe3-p2mp-pw-04, March 2012. 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.Authors' Addresses Kamran Raza Cisco Systems, Inc. 2000 InnovationDrive,Drive Ottawa, ONK2K-3E8, Canada. E-mail:K2K-3E8 Canada EMail: skraza@cisco.com Sami Boutros Cisco Systems, Inc. 3750 CiscoWay,Way San Jose, CA95134, USA. E-mail:95134 United States EMail: sboutros@cisco.com Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite400,400 Englewood, CO80112, USA. E-mail:80112 United States EMail: lmartini@cisco.com Nicolai Leymann Deutsche TelekomAG,AG Winterfeldtstrasse21,21 Berlin10781, Germany. E-mail:10781 Germany EMail: N.Leymann@telekom.de