--- 1/draft-ietf-mpls-ldp-applicability-label-adv-01.txt 2014-01-20 08:14:33.767757497 -0800 +++ 2/draft-ietf-mpls-ldp-applicability-label-adv-02.txt 2014-01-20 08:14:33.783757922 -0800 @@ -1,37 +1,32 @@ MPLS Working Group Kamran Raza Internet Draft Sami Boutros -Updates: 5036, 4447 (if approved) Luca Martini +Updates: 5036, 4447, 5918, 6388, 3212 Luca Martini Intended status: Standards Track Cisco Systems, Inc. -Expires: August 14, 2013 +Expires: July 19, 2014 Nicolai Leymann Deutsche Telekom - February 15, 2013 + January 20, 2014 - Applicability of LDP Label Advertisement Mode + Label Advertisement Discipline for LDP FECs - draft-ietf-mpls-ldp-applicability-label-adv-01.txt + draft-ietf-mpls-ldp-applicability-label-adv-02.txt Abstract - An LDP speaker negotiates the label advertisement mode with its LDP - peer at the time of session establishment. Although different - applications sharing the same LDP session may need different modes - of label distribution and advertisement, there is only one type of - label advertisement mode that is negotiated and used per LDP - session. This document clarifies the use and the applicability of - session's negotiated label advertisement mode, and categorizes LDP - applications into two broad categories of negotiated mode-bound and - mode-independent applications. The document updates RFC5036 and - RFC4447 to remove any ambiguity and conflict in the area of using - correct label advertisement mode for a given application. + 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. 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. @@ -36,317 +31,197 @@ other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six 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 August 14, 2013. + This Internet-Draft will expire on July 19, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + 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. Introduction 3 - 2. Conventions used in this document 3 - 3. Label Advertisement Mode Applicability 4 - 3.1. Label Advertisement Mode Negotiation 4 - 3.2. Mode-based Categorization of LDP Applications 4 - 3.2.1. Session mode-bound Applications 5 - 3.2.2. Session mode-independent Applications 5 - 3.3. Unacceptable label advertisement mode 6 - 4. Clarification on Mode Applicability 6 - 4.1. Update to RFC-5036 7 - 4.2. Update to RFC-4447 7 - 5. Security Considerations 7 - 6. IANA Considerations 7 - 7. References 7 - 7.1. Normative References 7 - 7.2. Informative References 8 - 8. Acknowledgments 8 + 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 1. Introduction - The MPLS architecture [RFC3031] defines two modes of label - advertisement for an LSR: - - 1. Downstream-on-Demand - - 2. Unsolicited Downstream - - The "Downstream-on-Demand" mode requires an LSR to explicitly - request the label binding for FECs from its peer, whereas - "Unsolicited Downstream" mode allows an LSR to distribute the label - binding for FECs to LSR peers that have not explicitly requested - them. The MPLS architecture also specifies that on any given label - distribution adjacency, the upstream LSR and the downstream LSR must - agree to use a single label advertisement mode. - Label Distribution Protocol (LDP) [RFC5036] allows label - advertisement mode negotiation at time of session establishment - (section 3.5.3 [RFC5036]). To comply with MPLS architecture, LDP - specification also dictates that only single label advertisement - mode is agreed and used for a given LDP session between two LSRs. - - With the advent of new LDP applications, such as L2VPN [RFC4447], - mLDP [RFC6388], ICCP [ICCP], there are situations when an LDP - session is shared across more than one application to exchange label - bindings for different types of FEC. Although different applications - sharing the same LDP session may need a different type of label - advertisement mode negotiated, there is only one type of label - advertisement mode that is negotiated and agreed at the time of - establishment of LDP session. - - This document clarifies the use and the applicability of label - advertisement mode of a session for each application using the - session. It also categorizes LDP applications into two broad - categories of mode-bound and mode-independent applications. - - The document also suggests an update to RFC-5036 and RFC-4447 to - remove any ambiguity and conflict in the area of using correct label - advertisement mode for a given LDP application. - -2. Conventions used in this document - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC-2119 [RFC2119]. - - The unqualified term "mode" used in document refers to "label - advertisement mode". - - Please also note that LDP specification [RFC5036] uses the term - "Downstream Unsolicited" to refer to "Unsolicited Downstream". The - LDP specification also uses the terms "label distribution mode" and - "label advertisement mode" interchangeably. Like LDP specification - document, this document also uses these terms interchangeably. - -3. Label Advertisement Mode Applicability - -3.1. Label Advertisement Mode Negotiation - - Label advertisement mode is negotiated between LSR peers at the time - of session establishment. The label advertisement mode is specified - in LDP Initialization message's "Common Session Parameter" TLV by - setting A-bit (Label Advertisement Discipline bit) to 1 or 0 for - Downstream-on-Demand or Downstream-Unsolicited modes respectively. - The negotiation of the A-bit is specified in section 3.5.3 of - [RFC5036] as follows: - - "If one LSR proposes Downstream Unsolicited and the other proposes - Downstream on Demand, the rules for resolving this difference is: - - - If the session is for a label-controlled ATM link or a - label- controlled Frame Relay link, then Downstream on Demand - MUST be used. - - - Otherwise, Downstream Unsolicited MUST be used." - - Once label advertisement mode has been negotiated and agreed, both - LSR peers must use the same mode for label binding exchange. - -3.2. Mode-based Categorization of LDP Applications - - The earlier applications, defined and identified at the time of - standardization of LDP base specification RFC-3036, using LDP to - exchange their FEC bindings were: - - . Dynamic Label Switching for IP Prefixes - - . Label-controlled ATM/FR - - Since then, several new applications have emerged that use LDP to - signal their FEC bindings and/or application data. These include: - - . L2VPN P2P PW ([RFC4447]) - . L2VPN P2MP PW ([P2MP-PW]) - - . mLDP ([RFC6388]) - - . ICCP ([ICCP]) - - We divide the LDP applications into two broad categories from label - advertisement mode usage point of view: - - 1. Session mode-bound Applications - - 2. Session mode-independent Applications - -3.2.1. Session mode-bound Applications - - We define a "session mode-bound application" to be an application - which uses the negotiated label advertisement mode. This means that - the FEC-label binding exchange for such an LDP application MUST use - the label advertisement mode negotiated for the LDP session. - - The early LDP applications "Dynamic Label Switching for IP Prefixes" - and "Label-controlled ATM/FR" are included into this category. - -3.2.2. Session mode-independent Applications - - We define a "session mode-independent application" to be an - application which does not care about the negotiated label - advertisement mode. This means that the FEC-label binding, or any - other application data, exchange for such an LDP application does - not care about, nor tied to the "negotiated" label advertisement - mode of the session; rather, the information exchange is driven by - the application need and procedures as described by its - specification document. For example, [RFC6388] specifies procedures - to advertise P2MP FEC label binding in an unsolicited manner, - irrespective of the negotiated label advertisement mode of the - session. - - The applications, PW (P2P and P2MP), MLDP, and ICCP, are included - into this category of LDP applications. - -3.2.2.1. Upstream Label Assignment - - As opposed to downstream assigned label advertisement defined by - [RFC3031], [RFC6389] specification defines new mode of label - advertisement where label advertisement and distribution occurs for - upstream assigned labels. - - As stated earlier in this document, LDP base specification RFC-5036 - only allows specifying Downstream-Unsolicited or Downstream-on-Demand - mode. This means that any LDP application that requires upstream - assigned label advertisement also falls under the category of Session - mode-independent application. + 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. -3.3. Unacceptable label advertisement mode + 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. - The procedures related to unacceptable label advertisement mode, as - defined in RFC-5036 section 3.5.3, continue to apply for any "mode- - bound" FEC/application. For a "mode-independent" FEC/application, - mode negotiation does not apply and hence both LSRs MUST operate in - the mode specified for the given application by the respective - specification. + 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. - If a session is jointly shared amongst mode-bound and mode- - independent FEC/applications, session will not be established if the - label advertisement mode is unacceptable (between the LSRs) for a - given mode-bound FEC/application type. This is inline with RFC-5036 - section 3.5.3 specification for unacceptable mode. +2. Label Advertisement Discipline -4. Clarification on Mode Applicability + 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. - To remove any ambiguity and conflict amongst different - specifications with regards to the use of LDP session's label - advertisement mode, we propose an update to LDP base specification - RFC-5036 to clarify the applicability of session's negotiated mode. + This document introduces following types for specifying a label + advertisement discipline for a FEC type: - Furthermore, RFC-4447 specifies LDP extensions and procedures to - exchange label bindings for P2P PW FECs [RFC4447], and dictates the - use of Downstream-Unsolicited mode for an LDP session related to - L2VPN PW. This mode dictation creates a direct conflict in - situations when a PW LDP session is shared with an LDP application - with Downstream-on-Demand mode (such as Label switching Application - for IP prefixes). To remove such a conflict, we also propose an - update to a section of RFC-4447. + - DU (Downstream Unsolicited) + - DoD (Downstream On Demand) + - As negotiated (DU or DoD) + - Upstream ([RFC6389]) + - Not Applicable -4.1. Update to RFC-5036 +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": - - The negotiated label advertisement discipline only applies to FEC - label binding advertisement of "Address Prefix" FECs; + - 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. - - Any new document specifying a new FEC MUST state the - applicability of the negotiated label advertisement discipline for - that FEC. + - This document defines the label advertisement discipline for + the following FEC types: -4.2. Update to RFC-4447 + +----------+----------+--------------------------------+ + | FEC Type | FEC Name | Label advertisement discipline | + +----------+----------+--------------------------------+ + | 0x01 | Wildcard | Not applicable | + | 0x02 | Prefix | As negotiated (DU or DoD) | + +----------+----------+--------------------------------+ - The section 3 of [RFC4447] states: +2.2. Specification for LDP FECs - "LDP MUST be used in its downstream unsolicited mode." + Following is the specification of label advertisement disciplines to + be used for currently defined LDP FEC types. - Since PW application falls under session mode-independent - application category, the above statement in [RFC4447] should be - read to mean as follows: + +------+----------------+--------------------------------+------+ + | 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 | + +------+----------------+--------------------------------+------+ - "LDP MUST exchange PW FEC label bindings in downstream unsolicited - manner, independent of the negotiated label advertisement mode of - the LDP session". + The above table also lists the RFC (in which given FEC type is + defined), and hence this document updates all the above listed RFCs. -5. Security Considerations +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]. -6. IANA Considerations +4. IANA Considerations - None. + 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: -7. References + - 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 -7.1. Normative References + - For the existing FEC types, populate this column with the + values listed under section 2.2. + +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 + [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. Heron, "Pseudowire Setup and Maintenance using the Label Distribution Protocol", RFC 4447, April 2006. - [RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol - Label Switching Architecture", RFC 3031, January 2001. - - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - -7.2. Informative References + [RFC5918] R. Asati, I. Minei, and B. Thomas, "Label Distribution + Protocol Typed Wildcard FEC", RFC 5918, August 2010. - [P2MP-PW] S. Boutros, L. Martini, S. Sivabalan, G. Del Vecchio, - Kamite, L. Jin, "Signaling Root-Initiated P2MP PWs using - LDP", draft-ietf-pwe3-p2mp-pw-04.txt, Work in Progress, - March 2012. + [RFC6388] I. Minei, I. Wijnands, K. Kompella, and B. Thomas, "LDP + Extensions for P2MP and MP2MP LSPs", RFC 6388, November + 2011. - [RFC6388] I. Minei, I. Wijnand, K. Kompella, B., "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. - [ICCP] L. Martini, S. Salam, A. Sajassi, and S. Matsushima, - "Inter-Chassis Communication Protocol for L2VPN PE - Redundancy", draft-ietf-pwe3-iccp-09.txt, Work in - Progress, July 2012. +5.2. Informative References - [RFC6389] R. Aggarwal, and J.L. Le Roux, "MPLS Upstream Label - Assignment for LDP", RFC 6389, November 2011. + None. -8. Acknowledgments +6. Acknowledgments - We acknowledge the authors of [RFC5036] and [RFC4447] since some of - the text in this document is borrowed from their specification. We - also acknowledge Eric Rosen and Rajiv Asati for their review and - input. + 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 Innovation Drive, Ottawa, ON K2K-3E8, Canada. E-mail: skraza@cisco.com