idnits 2.17.00 (12 Aug 2021) /tmp/idnits32942/draft-raza-mpls-ldp-applicability-label-adv-00.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC5036], [RFC4447]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (July 1, 2011) is 3976 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) == Missing Reference: 'RFC2119' is mentioned on line 128, but not defined == Missing Reference: 'LDP-UPSTREAM' is mentioned on line 216, but not defined == Unused Reference: 'UPSTREAM-LDP' is defined on line 303, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) == Outdated reference: A later version (-04) exists of draft-ietf-pwe3-p2mp-pw-02 == Outdated reference: draft-ietf-mpls-ldp-p2mp has been published as RFC 6388 == Outdated reference: draft-ietf-pwe3-iccp has been published as RFC 7275 == Outdated reference: draft-ietf-mpls-ldp-upstream has been published as RFC 6389 Summary: 1 error (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Kamran Raza 2 Internet Draft Sami Boutros 3 Updates: 5036, 4447 (if approved) Luca Martini 4 Intended status: Standards Track 5 Expires: December 31, 2011 Cisco Systems, Inc. 7 July 1, 2011 9 Applicability of LDP Label Advertisement Mode 11 draft-raza-mpls-ldp-applicability-label-adv-00.txt 13 Abstract 15 An LDP speaker negotiates the label advertisement mode with its LDP 16 peer at the time of session establishment. Although different 17 applications sharing the same LDP session may need different modes 18 of label distribution and advertisement, there is only one type of 19 label advertisement mode that is negotiated and used per LDP 20 session. This document clarifies the use and the applicability of 21 session's negotiated label advertisement mode, and categorizes LDP 22 applications into two broad categories of negotiated mode-bound and 23 mode-independent applications. This document proposal and 24 clarification thus updates [RFC5036] and [RFC4447]. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six 37 months and may be updated, replaced, or obsoleted by other documents 38 at any time. It is inappropriate to use Internet-Drafts as 39 reference material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html 47 This Internet-Draft will expire on December 31, 2011. 49 Copyright Notice 51 Copyright (c) 2011 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with 59 respect to this document. Code Components extracted from this 60 document must include Simplified BSD License text as described in 61 Section 4.e of the Trust Legal Provisions and are provided without 62 warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction 3 67 2. Conventions used in this document 3 68 3. Label Advertisement Mode Applicability 4 69 3.1. Label Advertisement Mode Negotiation 4 70 3.2. LDP Applications Categorization 4 71 3.2.1. Session mode-bound Applications 5 72 3.2.2. Session mode-independent Applications 5 73 3.3. Update to RFC-5036 6 74 3.4. Update to RFC-4447 6 75 4. Future Work 6 76 5. Security Considerations 6 77 6. IANA Considerations 7 78 7. References 7 79 7.1. Normative References 7 80 7.2. Informative References 7 81 8. Acknowledgments 7 83 1. Introduction 85 The MPLS architecture [RFC3031] defines two modes of label 86 advertisement for an LSR: 88 1. Downstream-on-Demand 90 2. Unsolicited Downstream 92 The "Downstream-on-Demand" mode requires an LSR to explicitly 93 request the label binding for FECs from its peer, whereas 94 "Unsolicited Downstream" mode allows an LSR to distribute the label 95 binding for FECs unsolicitedly to LSR peers that have not explicitly 96 requested them. The MPLS architecture [RFC3031] also specifies that 97 on any given label distribution adjacency, the upstream LSR and the 98 downstream LSR must agree to using a single label advertisement 99 mode. 101 Label Distribution Protocol (LDP) [RFC5036] allows label 102 advertisement mode negotiation at the session establishment time 103 (section 3.5.3 [RFC5036]). To comply with MPLS architecture, LDP 104 specification also dictates that only one label advertisement mode 105 is agreed and used on a given LDP session between two LSRs. 107 With the advent of new applications, such as L2VPN [RFC4447], mLDP 108 [MLDP], ICCP [ICCP], running on top of LDP, there are situations 109 when an LDP session is shared across more than one application to 110 exchange label bindings for different type of FECs. Although 111 different applications sharing the same LDP session may need 112 different type of label advertisement mode negotiated, there is only 113 one type of label advertisement mode that is negotiated and agreed 114 at the time of establishment of LDP session. 116 This document clarifies the use and the applicability of session's 117 label advertisement mode for each application using the session. It 118 also categorizes LDP applications into two broad categories of 119 negotiated mode-bound and mode-independent applications. This 120 document proposal and clarification thus updates [RFC5036] and 121 [RFC4447]. 123 2. Conventions used in this document 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in RFC-2119 [RFC2119]. 129 The unqualified term "mode" used in document refers to "label 130 advertisement mode". 132 Please also note that LDP specification [RFC5036] uses the term 133 "Downstream Unsolicited" to refer to "Unsolicited Downstream", as 134 well as uses the terms "label distribution" and "label 135 advertisement" interchangeably. This document also uses these 136 terms interchangeably. 138 3. Label Advertisement Mode Applicability 140 3.1. Label Advertisement Mode Negotiation 142 Label advertisement mode is negotiated between participating LSR 143 peers at the time of session establishment. The label advertisement 144 mode is specified in LDP Initialization message's "Common Session 145 Parameter" TLV by setting A-bit (Label Advertisement Discipline bit) 146 to 1 or 0 for Downstream-on-Demand or Downstream-Unsolicited modes 147 respectively [RFC5036]. The negotiation of the A-bit is specified in 148 section 3.5.3 of [RFC5036] as follows: 150 "If one LSR proposes Downstream Unsolicited and the other proposes 151 Downstream on Demand, the rules for resolving this difference is: 153 - If the session is for a label-controlled ATM link or a label- 154 controlled Frame Relay link, then Downstream on Demand MUST be 155 used. 157 - Otherwise, Downstream Unsolicited MUST be used." 159 Once label advertisement mode has been negotiated and agreed, both 160 LSRs must use the same mode for label binding exchange. 162 3.2. LDP Applications Categorization 164 At the time of standardization of LDP base specification RFC-3036, 165 the earlier applications using LDP to exchange their FEC bindings 166 were: 168 . Dynamic Label Switching for IP Prefixes 170 . Label-controlled ATM/FR 172 Since then, several new applications have emerged that use LDP to 173 signal their FEC bindings and/or application data: 175 . L2VPN P2P PW ([RFC4447]) 176 . L2VPN P2MP PW ([P2MP-PW]) 178 . mLDP ([MLDP]) 180 . ICCP ([ICCP]) 182 We divide these LDP applications into two broad categories from 183 label advertisement mode usage point of view: 185 1. Session mode-bound Applications (i.e. use the negotiated label 186 advertisement mode) 188 2. Session mode-independent Applications (i.e. do not care about the 189 negotiated label advertisement mode) 191 3.2.1. Session mode-bound Applications 193 The FEC label binding exchange for such LDP applications MUST use the 194 negotiated label advertisement mode. 196 The early LDP applications "Dynamic Label Switching for IP Prefixes" 197 and "Label-controlled ATM/FR" fall into this category. 199 3.2.2. Session mode-independent Applications 201 The FEC label binding, or any other application data, exchange for 202 such LDP applications does not care about, nor tied to the 203 negotiated label advertisement mode of the session; rather, the 204 information exchange is driven by the application need and 205 procedures as described by their respective specifications. For 206 example, [MLDP] specifies procedures to advertise P2MP FEC label 207 binding in an unsolicited manner, irrespective of the negotiated 208 label advertisement mode of the session. 210 The applications, PW (P2P and P2MP), MLDP, and ICCP, fall into this 211 category of LDP application. 213 3.2.2.1. Upstream Label Assignment 215 As opposed to downstream assigned label advertisement defined by 216 [RFC3031], [LDP-UPSTREAM] specification defines new mode of label 217 advertisement where label advertisement and distribution occurs for 218 upstream assigned labels. 220 As stated in earlier section 3.1 of this document, [RFC5036] only 221 allows specifying Downstream-Unsolicited or Downstream-on-Demand 222 mode. This means that any LDP application that requires upstream 223 assigned label advertisement also falls under the category of Session 224 mode-independent application. 226 3.3. Update to RFC-5036 228 For clarification reasons, section 3.5.3 of [RFC5036] is updated to 229 add following two statements under the description of "A, Label 230 Advertisement Discipline": 232 - The negotiated label advertisement discipline only applies to FEC 233 label binding advertisement of "Address Prefix" FECs; 235 - Any document specifying a new FEC SHOULD state the applicability 236 of the negotiated label advertisement discipline for that FEC. 238 3.4. Update to RFC-4447 240 [RFC4447] specifies LDP extensions and procedures to exchange label 241 bindings for P2P PW FECs. The section 3 of [RFC4447] states: 243 "LDP MUST be used in its downstream unsolicited mode." 245 Since PW application falls under session mode-independent 246 application category, the above statement in [RFC4447] should be 247 read to mean as follows: 249 "LDP MUST exchange PW FEC label bindings in downstream unsolicited 250 manner, independent of the negotiated label advertisement mode of 251 the LDP session." 253 4. Future Work 255 This document only clarifies the existing behavior for LDP label 256 advertisement mode for different applications without defining any 257 protocol extensions. In future, a new LDP capability [RFC5561] based 258 mechanism can be defined to signal/negotiate label advertisement 259 mode per FEC/application. 261 5. Security Considerations 263 This document specification only clarifies the applicability of LDP 264 session's label advertisement mode, and hence does not add any LDP 265 security mechanics and considerations to those already defined in 266 LDP specification [RFC5036]. 268 6. IANA Considerations 270 None. 272 7. References 274 7.1. Normative References 276 [RFC5036] Andersson, L., Menei, I., and Thomas, B., Editors, "LDP 277 Specification", RFC 5036, September 2007. 279 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol 280 Label Switching Architecture", RFC 3031, January 2001. 282 7.2. Informative References 284 [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. 285 Heron, "Pseudowire Setup and Maintenance using the Label 286 Distribution Protocol", RFC 4447, April 2006. 288 [P2MP-PW] Boutros, S., Martini, L., Sivabalan, S., Del Vecchio, G., 289 Kamite, Jin, L., "Signaling Root-Initiated P2MP PWs using 290 LDP", draft-ietf-pwe3-p2mp-pw-02.txt, Work in Progress, 291 March 2011. 293 [MLDP] Minei, I., Kompella, K., Wijnands, I., and Thomas, B., 294 "LDP Extensions for Point-to-Multipoint and Multipoint-to- 295 Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp 296 -14.txt, Work in Progress, June 2011. 298 [ICCP] Martini, L., Salam, S., Sajassi, A., and Matsushima, S., 299 "Inter-Chassis Communication Protocol for L2VPN PE 300 Redundancy", draft-ietf-pwe3-iccp-05.txt, Work in 301 Progress, April 2011. 303 [UPSTREAM-LDP] Aggarwal, R., and Le Roux, J.L., "MPLS Upstream Label 304 Assignment for LDP", draft-ietf-mpls-ldp-upstream-10.txt, 305 Work in Progress, February 2011. 307 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and Le 308 Roux, JL., "LDP Capabilities", RFC 5561, July 2009. 310 8. Acknowledgments 312 The authors would like to acknowledge Eric Rosen and Rajiv Asati for 313 their review and input. 315 This document was prepared using 2-Word-v2.0.template.dot. 317 Authors' Addresses 319 Kamran Raza 320 Cisco Systems, Inc. 321 2000 Innovation Drive, 322 Kanata, ON K2K-3E8, Canada. 323 E-mail: skraza@cisco.com 325 Sami Boutros 326 Cisco Systems, Inc. 327 3750 Cisco Way, 328 San Jose, CA 95134, USA. 329 E-mail: sboutros@cisco.com 331 Luca Martini 332 Cisco Systems, Inc. 333 9155 East Nichols Avenue, Suite 400, 334 Englewood, CO 80112, USA. 335 E-mail: lmartini@cisco.com