idnits 2.17.1 draft-ietf-mpls-ldp-applicability-label-adv-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4447, updated by this document, for RFC5378 checks: 2002-08-12) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2013) is 4086 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-16) exists of draft-ietf-pwe3-iccp-09 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Kamran Raza 2 Internet Draft Sami Boutros 3 Updates: 5036, 4447 (if approved) Luca Martini 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 14, 2013 6 Nicolai Leymann 7 Deutsche Telekom 9 February 15, 2013 11 Applicability of LDP Label Advertisement Mode 13 draft-ietf-mpls-ldp-applicability-label-adv-01.txt 15 Abstract 17 An LDP speaker negotiates the label advertisement mode with its LDP 18 peer at the time of session establishment. Although different 19 applications sharing the same LDP session may need different modes 20 of label distribution and advertisement, there is only one type of 21 label advertisement mode that is negotiated and used per LDP 22 session. This document clarifies the use and the applicability of 23 session's negotiated label advertisement mode, and categorizes LDP 24 applications into two broad categories of negotiated mode-bound and 25 mode-independent applications. The document updates RFC5036 and 26 RFC4447 to remove any ambiguity and conflict in the area of using 27 correct label advertisement mode for a given application. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months and may be updated, replaced, or obsoleted by other documents 41 at any time. It is inappropriate to use Internet-Drafts as 42 reference material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 This Internet-Draft will expire on August 14, 2013. 51 Copyright Notice 53 Copyright (c) 2013 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with 61 respect to this document. Code Components extracted from this 62 document must include Simplified BSD License text as described in 63 Section 4.e of the Trust Legal Provisions and are provided without 64 warranty as described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction 3 69 2. Conventions used in this document 3 70 3. Label Advertisement Mode Applicability 4 71 3.1. Label Advertisement Mode Negotiation 4 72 3.2. Mode-based Categorization of LDP Applications 4 73 3.2.1. Session mode-bound Applications 5 74 3.2.2. Session mode-independent Applications 5 75 3.3. Unacceptable label advertisement mode 6 76 4. Clarification on Mode Applicability 6 77 4.1. Update to RFC-5036 7 78 4.2. Update to RFC-4447 7 79 5. Security Considerations 7 80 6. IANA Considerations 7 81 7. References 7 82 7.1. Normative References 7 83 7.2. Informative References 8 84 8. Acknowledgments 8 86 1. Introduction 88 The MPLS architecture [RFC3031] defines two modes of label 89 advertisement for an LSR: 91 1. Downstream-on-Demand 93 2. Unsolicited Downstream 95 The "Downstream-on-Demand" mode requires an LSR to explicitly 96 request the label binding for FECs from its peer, whereas 97 "Unsolicited Downstream" mode allows an LSR to distribute the label 98 binding for FECs to LSR peers that have not explicitly requested 99 them. The MPLS architecture also specifies that on any given label 100 distribution adjacency, the upstream LSR and the downstream LSR must 101 agree to use a single label advertisement mode. 103 Label Distribution Protocol (LDP) [RFC5036] allows label 104 advertisement mode negotiation at time of session establishment 105 (section 3.5.3 [RFC5036]). To comply with MPLS architecture, LDP 106 specification also dictates that only single label advertisement 107 mode is agreed and used for a given LDP session between two LSRs. 109 With the advent of new LDP applications, such as L2VPN [RFC4447], 110 mLDP [RFC6388], ICCP [ICCP], there are situations when an LDP 111 session is shared across more than one application to exchange label 112 bindings for different types of FEC. Although different applications 113 sharing the same LDP session may need a different type of label 114 advertisement mode negotiated, there is only one type of label 115 advertisement mode that is negotiated and agreed at the time of 116 establishment of LDP session. 118 This document clarifies the use and the applicability of label 119 advertisement mode of a session for each application using the 120 session. It also categorizes LDP applications into two broad 121 categories of mode-bound and mode-independent applications. 123 The document also suggests an update to RFC-5036 and RFC-4447 to 124 remove any ambiguity and conflict in the area of using correct label 125 advertisement mode for a given LDP application. 127 2. Conventions used in this document 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in RFC-2119 [RFC2119]. 133 The unqualified term "mode" used in document refers to "label 134 advertisement mode". 136 Please also note that LDP specification [RFC5036] uses the term 137 "Downstream Unsolicited" to refer to "Unsolicited Downstream". The 138 LDP specification also uses the terms "label distribution mode" and 139 "label advertisement mode" interchangeably. Like LDP specification 140 document, this document also uses these terms interchangeably. 142 3. Label Advertisement Mode Applicability 144 3.1. Label Advertisement Mode Negotiation 146 Label advertisement mode is negotiated between LSR peers at the time 147 of session establishment. The label advertisement mode is specified 148 in LDP Initialization message's "Common Session Parameter" TLV by 149 setting A-bit (Label Advertisement Discipline bit) to 1 or 0 for 150 Downstream-on-Demand or Downstream-Unsolicited modes respectively. 151 The negotiation of the A-bit is specified in section 3.5.3 of 152 [RFC5036] as follows: 154 "If one LSR proposes Downstream Unsolicited and the other proposes 155 Downstream on Demand, the rules for resolving this difference is: 157 - If the session is for a label-controlled ATM link or a 158 label- controlled Frame Relay link, then Downstream on Demand 159 MUST be used. 161 - Otherwise, Downstream Unsolicited MUST be used." 163 Once label advertisement mode has been negotiated and agreed, both 164 LSR peers must use the same mode for label binding exchange. 166 3.2. Mode-based Categorization of LDP Applications 168 The earlier applications, defined and identified at the time of 169 standardization of LDP base specification RFC-3036, using LDP to 170 exchange their FEC bindings were: 172 . Dynamic Label Switching for IP Prefixes 174 . Label-controlled ATM/FR 176 Since then, several new applications have emerged that use LDP to 177 signal their FEC bindings and/or application data. These include: 179 . L2VPN P2P PW ([RFC4447]) 180 . L2VPN P2MP PW ([P2MP-PW]) 182 . mLDP ([RFC6388]) 184 . ICCP ([ICCP]) 186 We divide the LDP applications into two broad categories from label 187 advertisement mode usage point of view: 189 1. Session mode-bound Applications 191 2. Session mode-independent Applications 193 3.2.1. Session mode-bound Applications 195 We define a "session mode-bound application" to be an application 196 which uses the negotiated label advertisement mode. This means that 197 the FEC-label binding exchange for such an LDP application MUST use 198 the label advertisement mode negotiated for the LDP session. 200 The early LDP applications "Dynamic Label Switching for IP Prefixes" 201 and "Label-controlled ATM/FR" are included into this category. 203 3.2.2. Session mode-independent Applications 205 We define a "session mode-independent application" to be an 206 application which does not care about the negotiated label 207 advertisement mode. This means that the FEC-label binding, or any 208 other application data, exchange for such an LDP application does 209 not care about, nor tied to the "negotiated" label advertisement 210 mode of the session; rather, the information exchange is driven by 211 the application need and procedures as described by its 212 specification document. For example, [RFC6388] specifies procedures 213 to advertise P2MP FEC label binding in an unsolicited manner, 214 irrespective of the negotiated label advertisement mode of the 215 session. 217 The applications, PW (P2P and P2MP), MLDP, and ICCP, are included 218 into this category of LDP applications. 220 3.2.2.1. Upstream Label Assignment 222 As opposed to downstream assigned label advertisement defined by 223 [RFC3031], [RFC6389] specification defines new mode of label 224 advertisement where label advertisement and distribution occurs for 225 upstream assigned labels. 227 As stated earlier in this document, LDP base specification RFC-5036 228 only allows specifying Downstream-Unsolicited or Downstream-on-Demand 229 mode. This means that any LDP application that requires upstream 230 assigned label advertisement also falls under the category of Session 231 mode-independent application. 233 3.3. Unacceptable label advertisement mode 235 The procedures related to unacceptable label advertisement mode, as 236 defined in RFC-5036 section 3.5.3, continue to apply for any "mode- 237 bound" FEC/application. For a "mode-independent" FEC/application, 238 mode negotiation does not apply and hence both LSRs MUST operate in 239 the mode specified for the given application by the respective 240 specification. 242 If a session is jointly shared amongst mode-bound and mode- 243 independent FEC/applications, session will not be established if the 244 label advertisement mode is unacceptable (between the LSRs) for a 245 given mode-bound FEC/application type. This is inline with RFC-5036 246 section 3.5.3 specification for unacceptable mode. 248 4. Clarification on Mode Applicability 250 To remove any ambiguity and conflict amongst different 251 specifications with regards to the use of LDP session's label 252 advertisement mode, we propose an update to LDP base specification 253 RFC-5036 to clarify the applicability of session's negotiated mode. 255 Furthermore, RFC-4447 specifies LDP extensions and procedures to 256 exchange label bindings for P2P PW FECs [RFC4447], and dictates the 257 use of Downstream-Unsolicited mode for an LDP session related to 258 L2VPN PW. This mode dictation creates a direct conflict in 259 situations when a PW LDP session is shared with an LDP application 260 with Downstream-on-Demand mode (such as Label switching Application 261 for IP prefixes). To remove such a conflict, we also propose an 262 update to a section of RFC-4447. 264 4.1. Update to RFC-5036 266 The section 3.5.3 of [RFC5036] is updated to add following two 267 statements under the description of "A, Label Advertisement 268 Discipline": 270 - The negotiated label advertisement discipline only applies to FEC 271 label binding advertisement of "Address Prefix" FECs; 273 - Any new document specifying a new FEC MUST state the 274 applicability of the negotiated label advertisement discipline for 275 that FEC. 277 4.2. Update to RFC-4447 279 The section 3 of [RFC4447] states: 281 "LDP MUST be used in its downstream unsolicited mode." 283 Since PW application falls under session mode-independent 284 application category, the above statement in [RFC4447] should be 285 read to mean as follows: 287 "LDP MUST exchange PW FEC label bindings in downstream unsolicited 288 manner, independent of the negotiated label advertisement mode of 289 the LDP session". 291 5. Security Considerations 293 This document specification only clarifies the applicability of LDP 294 session's label advertisement mode, and hence does not add any LDP 295 security mechanics and considerations to those already defined in 296 the LDP specification [RFC5036]. 298 6. IANA Considerations 300 None. 302 7. References 304 7.1. Normative References 306 [RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP 307 Specification", RFC 5036, September 2007. 309 [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. 310 Heron, "Pseudowire Setup and Maintenance using the Label 311 Distribution Protocol", RFC 4447, April 2006. 313 [RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol 314 Label Switching Architecture", RFC 3031, January 2001. 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 7.2. Informative References 321 [P2MP-PW] S. Boutros, L. Martini, S. Sivabalan, G. Del Vecchio, 322 Kamite, L. Jin, "Signaling Root-Initiated P2MP PWs using 323 LDP", draft-ietf-pwe3-p2mp-pw-04.txt, Work in Progress, 324 March 2012. 326 [RFC6388] I. Minei, I. Wijnand, K. Kompella, B., "LDP Extensions for 327 P2MP and MP2MP LSPs", RFC 6388, November 2011. 329 [ICCP] L. Martini, S. Salam, A. Sajassi, and S. Matsushima, 330 "Inter-Chassis Communication Protocol for L2VPN PE 331 Redundancy", draft-ietf-pwe3-iccp-09.txt, Work in 332 Progress, July 2012. 334 [RFC6389] R. Aggarwal, and J.L. Le Roux, "MPLS Upstream Label 335 Assignment for LDP", RFC 6389, November 2011. 337 8. Acknowledgments 339 We acknowledge the authors of [RFC5036] and [RFC4447] since some of 340 the text in this document is borrowed from their specification. We 341 also acknowledge Eric Rosen and Rajiv Asati for their review and 342 input. 344 This document was prepared using 2-Word-v2.0.template.dot. 346 Authors' Addresses 348 Kamran Raza 349 Cisco Systems, Inc. 350 2000 Innovation Drive, 351 Ottawa, ON K2K-3E8, Canada. 352 E-mail: skraza@cisco.com 353 Sami Boutros 354 Cisco Systems, Inc. 355 3750 Cisco Way, 356 San Jose, CA 95134, USA. 357 E-mail: sboutros@cisco.com 359 Luca Martini 360 Cisco Systems, Inc. 361 9155 East Nichols Avenue, Suite 400, 362 Englewood, CO 80112, USA. 363 E-mail: lmartini@cisco.com 365 Nicolai Leymann 366 Deutsche Telekom AG, 367 Winterfeldtstrasse 21, 368 Berlin 10781, Germany. 369 E-mail: N.Leymann@telekom.de