idnits 2.17.00 (12 Aug 2021) /tmp/idnits31213/draft-raza-mpls-ldp-applicability-label-adv-02.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC5036, but the abstract doesn't seem to directly say this. It does mention RFC5036 though, so this could be OK. -- The draft header indicates that this document updates RFC4447, but the abstract doesn't seem to directly say this. It does mention RFC4447 though, so this could be OK. 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 (January 13, 2012) is 3780 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 (-04) exists of draft-ietf-pwe3-p2mp-pw-03 == Outdated reference: draft-ietf-pwe3-iccp has been published as RFC 7275 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 4 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: July 12, 2012 6 Nicolai Leymann 7 Deutsche Telekom 9 January 13, 2012 11 Applicability of LDP Label Advertisement Mode 13 draft-raza-mpls-ldp-applicability-label-adv-02.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 also suggests an update 26 to RFC5036 and RFC4447 to remove any ambiguity and conflict in the 27 area of using correct label advertisement mode for a given 28 application. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six 41 months and may be updated, replaced, or obsoleted by other documents 42 at any time. It is inappropriate to use Internet-Drafts as 43 reference material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html 50 This Internet-Draft will expire on July 12, 2012. 52 Copyright Notice 54 Copyright (c) 2012 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents 59 (http://trustee.ietf.org/license-info) in effect on the date of 60 publication of this document. Please review these documents 61 carefully, as they describe your rights and restrictions with 62 respect to this document. Code Components extracted from this 63 document must include Simplified BSD License text as described in 64 Section 4.e of the Trust Legal Provisions and are provided without 65 warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction ................................................... 3 70 2. Conventions used in this document .............................. 3 71 3. Label Advertisement Mode Applicability ......................... 4 72 3.1. Label Advertisement Mode Negotiation ...................... 4 73 3.2. Mode-based Categorization of LDP Applications ............. 4 74 3.2.1. Session mode-bound Applications .................... 5 75 3.2.2. Session mode-independent Applications .............. 5 76 4. Clarification on Mode Applicability ............................ 6 77 4.1. Update to RFC-5036 ........................................ 6 78 4.2. Update to RFC-4447 ........................................ 6 79 5. Future Work .................................................... 7 80 6. Security Considerations ........................................ 7 81 7. IANA Considerations ............................................ 7 82 8. References ..................................................... 7 83 8.1. Normative References ...................................... 7 84 8.2. Informative References .................................... 7 85 9. Acknowledgments ................................................ 8 87 1. Introduction 89 The MPLS architecture [RFC3031] defines two modes of label 90 advertisement for an LSR: 92 1. Downstream-on-Demand 94 2. Unsolicited Downstream 96 The "Downstream-on-Demand" mode requires an LSR to explicitly 97 request the label binding for FECs from its peer, whereas 98 "Unsolicited Downstream" mode allows an LSR to distribute the label 99 binding for FECs unsolicitedly to LSR peers that have not explicitly 100 requested them. The MPLS architecture also specifies that on any 101 given label distribution adjacency, the upstream LSR and the 102 downstream LSR must agree to using a single label advertisement 103 mode. 105 Label Distribution Protocol (LDP) [RFC5036] allows label 106 advertisement mode negotiation at the session establishment time 107 (section 3.5.3 [RFC5036]). To comply with MPLS architecture, LDP 108 specification also dictates that only single label advertisement 109 mode is agreed and used on a given LDP session between two LSRs. 111 With the advent of new LDP applications, such as L2VPN [RFC4447], 112 mLDP [RFC6388], ICCP [ICCP], there are situations when an LDP 113 session is shared across more than one application to exchange label 114 bindings for different types of FEC. Although different applications 115 sharing the same LDP session may need a different type of label 116 advertisement mode negotiated, there is only one type of label 117 advertisement mode that is negotiated and agreed at the time of 118 establishment of LDP session. 120 This document clarifies the use and the applicability of session's 121 label advertisement mode for each application using the session. It 122 also categorizes LDP applications into two broad categories of mode- 123 bound and mode-independent applications. 125 The document also suggests an update to RFC-5036 and RFC-4447 to 126 remove any ambiguity and conflict in the area of using correct label 127 advertisement mode for a given LDP application. 129 2. Conventions used in this document 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in RFC-2119 [RFC2119]. 135 The unqualified term "mode" used in document refers to "label 136 advertisement mode". 138 Please also note that LDP specification [RFC5036] uses the term 139 "Downstream Unsolicited" to refer to "Unsolicited Downstream". The 140 LDP specification also uses the terms "label distribution mode" and 141 "label advertisement mode" interchangeably. Like LDP specification 142 document, this document also uses these terms interchangeably. 144 3. Label Advertisement Mode Applicability 146 3.1. Label Advertisement Mode Negotiation 148 Label advertisement mode is negotiated between LSR peers at the time 149 of session establishment. The label advertisement mode is specified 150 in LDP Initialization message's "Common Session Parameter" TLV by 151 setting A-bit (Label Advertisement Discipline bit) to 1 or 0 for 152 Downstream-on-Demand or Downstream-Unsolicited modes respectively. 153 The negotiation of the A-bit is specified in section 3.5.3 of 154 [RFC5036] as follows: 156 "If one LSR proposes Downstream Unsolicited and the other proposes 157 Downstream on Demand, the rules for resolving this difference is: 159 - If the session is for a label-controlled ATM link or a 160 label- controlled Frame Relay link, then Downstream on Demand 161 MUST be used. 163 - Otherwise, Downstream Unsolicited MUST be used." 165 Once label advertisement mode has been negotiated and agreed, both 166 LSR peers must use the same mode for label binding exchange. 168 3.2. Mode-based Categorization of LDP Applications 170 The earlier applications, defined and identified at the time of 171 standardization of LDP base specification RFC-3036, using LDP to 172 exchange their FEC bindings were: 174 . Dynamic Label Switching for IP Prefixes 176 . Label-controlled ATM/FR 178 Since then, several new applications have emerged that use LDP to 179 signal their FEC bindings and/or application data. These include: 181 . L2VPN P2P PW ([RFC4447]) 182 . L2VPN P2MP PW ([P2MP-PW]) 184 . mLDP ([RFC6388]) 186 . ICCP ([ICCP]) 188 We divide the LDP applications into two broad categories from label 189 advertisement mode usage point of view: 191 1. Session mode-bound Applications 193 2. Session mode-independent Applications 195 3.2.1. Session mode-bound Applications 197 We define a "session mode-bound application" to be an application 198 which uses the negotiated label advertisement mode. This means that 199 the FEC-label binding exchange for such an LDP applications MUST use 200 the label advertisement mode negotiated for the LDP session. 202 The early LDP applications "Dynamic Label Switching for IP Prefixes" 203 and "Label-controlled ATM/FR" fall into this category. 205 3.2.2. Session mode-independent Applications 207 We define a "session mode-independent application" to be an 208 application which does not care about the negotiated label 209 advertisement mode. This means that the FEC-label binding, or any 210 other application data, exchange for such an LDP application does 211 not care about, nor tied to the "negotiated" label advertisement 212 mode of the session; rather, the information exchange is driven by 213 the application need and procedures as described by its 214 specification document. For example, [RFC6388] specifies procedures 215 to advertise P2MP FEC label binding in an unsolicited manner, 216 irrespective of the negotiated label advertisement mode of the 217 session. 219 The applications, PW (P2P and P2MP), MLDP, and ICCP, fall into this 220 category of LDP application. 222 3.2.2.1. Upstream Label Assignment 224 As opposed to downstream assigned label advertisement defined by 225 [RFC3031], [RFC6389] specification defines new mode of label 226 advertisement where label advertisement and distribution occurs for 227 upstream assigned labels. 229 As stated in earlier section 3.1 of this document, LDP base 230 specification RFC-5036 only allows specifying Downstream-Unsolicited 231 or Downstream-on-Demand mode. This means that any LDP application 232 that requires upstream assigned label advertisement also falls under 233 the category of Session mode-independent application. 235 4. Clarification on Mode Applicability 237 To remove any ambiguity and conflict amongst different 238 specifications with regards to the use of LDP session's label 239 advertisement mode, we propose an update to LDP base specification 240 RFC-5036 to clarify the applicability of session's negotiated mode. 242 Furthermore, RFC-4447 specifies LDP extensions and procedures to 243 exchange label bindings for P2P PW FECs [RFC4447], and dictates the 244 use of Downstream-Unsolicited mode for an LDP session related to 245 L2VPN PW. This mode dictation creates a direct conflict in 246 situations when a PW LDP session is shared with an LDP application 247 with Downstream-on-Demand mode (such as Label switching Application 248 for IP prefixes). To remove such a conflict, we also propose an 249 update to a section of RFC-4447. 251 4.1. Update to RFC-5036 253 The section 3.5.3 of [RFC5036] is updated to add following two 254 statements under the description of "A, Label Advertisement 255 Discipline": 257 - The negotiated label advertisement discipline only applies to FEC 258 label binding advertisement of "Address Prefix" FECs; 260 - Any document specifying a new FEC SHOULD state the applicability 261 of the negotiated label advertisement discipline for that FEC. 263 4.2. Update to RFC-4447 265 The section 3 of [RFC4447] states: 267 "LDP MUST be used in its downstream unsolicited mode." 269 Since PW application falls under session mode-independent 270 application category, the above statement in [RFC4447] should be 271 read to mean as follows: 273 "LDP MUST exchange PW FEC label bindings in downstream unsolicited 274 manner, independent of the negotiated label advertisement mode of 275 the LDP session". 277 5. Future Work 279 This document only clarifies the existing behavior for LDP label 280 advertisement mode for different applications without defining any 281 protocol extensions. In future, a new LDP capability [RFC5561] based 282 mechanism can also be defined to signal/negotiate label 283 advertisement mode per FEC/application. 285 Moreover, it is RECOMMENDED to clearly categorize any new LDP 286 application in future with regards to the advertisement mode (as per 287 section 3.2. ). The specification document of such an application 288 SHOULD explicitly state the application category. 290 6. Security Considerations 292 This document specification only clarifies the applicability of LDP 293 session's label advertisement mode, and hence does not add any LDP 294 security mechanics and considerations to those already defined in 295 LDP specification [RFC5036]. 297 7. IANA Considerations 299 None. 301 8. References 303 8.1. Normative References 305 [RFC5036] L. Andersson, I. Minei, and B. Thomas, "LDP 306 Specification", RFC 5036, September 2007. 308 [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. 309 Heron, "Pseudowire Setup and Maintenance using the Label 310 Distribution Protocol", RFC 4447, April 2006. 312 [RFC3031] E. Rosen, A. Viswanathan, and R. Callon, "Multiprotocol 313 Label Switching Architecture", RFC 3031, January 2001. 315 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC2119, March 1997. 319 8.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-03.txt, Work in Progress, 324 October 2011. 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-06.txt, Work in 332 Progress, July 2011. 334 [RFC6389] R. Aggarwal, and J.L. Le Roux, "MPLS Upstream Label 335 Assignment for LDP", RFC 6389, November 2011. 337 [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, and J.L. Le 338 Roux, "LDP Capabilities", RFC 5561, July 2009. 340 9. Acknowledgments 342 We acknowledge the authors of [RFC5036] and [RFC4447] since some of 343 the text in this document is borrowed from their specification. We 344 also acknowledge Eric Rosen and Rajiv Asati for their review and 345 input. 347 This document was prepared using 2-Word-v2.0.template.dot. 349 Authors' Addresses 351 Kamran Raza 352 Cisco Systems, Inc. 353 2000 Innovation Drive, 354 Ottawa, ON K2K-3E8, Canada. 355 Email: skraza@cisco.com 357 Sami Boutros 358 Cisco Systems, Inc. 359 3750 Cisco Way, 360 San Jose, CA 95134, USA. 361 Email: sboutros@cisco.com 363 Luca Martini 364 Cisco Systems, Inc. 365 9155 East Nichols Avenue, Suite 400, 366 Englewood, CO 80112, USA. 367 Email: lmartini@cisco.com 368 Nicolai Leymann 369 Deutsche Telekom, 370 Winterfeldtstrae 21-27, 371 10781 Berlin, Germany. 372 Email: N.Leymann@telekom.de