idnits 2.17.00 (12 Aug 2021) /tmp/idnits31897/draft-raza-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: ---------------------------------------------------------------------------- == 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 11, 2011) is 3966 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 130, but not defined == Missing Reference: 'LDP-UPSTREAM' is mentioned on line 218, but not defined == Unused Reference: 'UPSTREAM-LDP' is defined on line 305, 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 Cisco Systems, Inc. 5 Expires: January 10, 2012 6 Nicolai Leymann 7 Deutsche Telekom 9 July 11, 2011 11 Applicability of LDP Label Advertisement Mode 13 draft-raza-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. This document proposal and 26 clarification thus updates [RFC5036] and [RFC4447]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six 39 months and may be updated, replaced, or obsoleted by other documents 40 at any time. It is inappropriate to use Internet-Drafts as 41 reference material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 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 January 10, 2012. 51 Copyright Notice 53 Copyright (c) 2011 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. LDP Applications Categorization 4 73 3.2.1. Session mode-bound Applications 5 74 3.2.2. Session mode-independent Applications 5 75 3.3. Update to RFC-5036 6 76 3.4. Update to RFC-4447 6 77 4. Future Work 6 78 5. Security Considerations 6 79 6. IANA Considerations 7 80 7. References 7 81 7.1. Normative References 7 82 7.2. Informative References 7 83 8. Acknowledgments 7 85 1. Introduction 87 The MPLS architecture [RFC3031] defines two modes of label 88 advertisement for an LSR: 90 1. Downstream-on-Demand 92 2. Unsolicited Downstream 94 The "Downstream-on-Demand" mode requires an LSR to explicitly 95 request the label binding for FECs from its peer, whereas 96 "Unsolicited Downstream" mode allows an LSR to distribute the label 97 binding for FECs unsolicitedly to LSR peers that have not explicitly 98 requested them. The MPLS architecture [RFC3031] also specifies that 99 on any given label distribution adjacency, the upstream LSR and the 100 downstream LSR must agree to using a single label advertisement 101 mode. 103 Label Distribution Protocol (LDP) [RFC5036] allows label 104 advertisement mode negotiation at the session establishment time 105 (section 3.5.3 [RFC5036]). To comply with MPLS architecture, LDP 106 specification also dictates that only one label advertisement mode 107 is agreed and used on a given LDP session between two LSRs. 109 With the advent of new applications, such as L2VPN [RFC4447], mLDP 110 [MLDP], ICCP [ICCP], running on top of LDP, there are situations 111 when an LDP session is shared across more than one application to 112 exchange label bindings for different type of FECs. Although 113 different applications sharing the same LDP session may need 114 different type of label advertisement mode negotiated, there is only 115 one type of label advertisement mode that is negotiated and agreed 116 at the time of establishment of LDP session. 118 This document clarifies the use and the applicability of session's 119 label advertisement mode for each application using the session. It 120 also categorizes LDP applications into two broad categories of 121 negotiated mode-bound and mode-independent applications. This 122 document proposal and clarification thus updates [RFC5036] and 123 [RFC4447]. 125 2. Conventions used in this document 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in RFC-2119 [RFC2119]. 131 The unqualified term "mode" used in document refers to "label 132 advertisement mode". 134 Please also note that LDP specification [RFC5036] uses the term 135 "Downstream Unsolicited" to refer to "Unsolicited Downstream", as 136 well as uses the terms "label distribution" and "label 137 advertisement" interchangeably. This document also uses these 138 terms interchangeably. 140 3. Label Advertisement Mode Applicability 142 3.1. Label Advertisement Mode Negotiation 144 Label advertisement mode is negotiated between participating LSR 145 peers at the time of session establishment. The label advertisement 146 mode is specified in LDP Initialization message's "Common Session 147 Parameter" TLV by setting A-bit (Label Advertisement Discipline bit) 148 to 1 or 0 for Downstream-on-Demand or Downstream-Unsolicited modes 149 respectively [RFC5036]. The negotiation of the A-bit is specified in 150 section 3.5.3 of [RFC5036] as follows: 152 "If one LSR proposes Downstream Unsolicited and the other proposes 153 Downstream on Demand, the rules for resolving this difference is: 155 - If the session is for a label-controlled ATM link or a label- 156 controlled Frame Relay link, then Downstream on Demand MUST be 157 used. 159 - Otherwise, Downstream Unsolicited MUST be used." 161 Once label advertisement mode has been negotiated and agreed, both 162 LSRs must use the same mode for label binding exchange. 164 3.2. LDP Applications Categorization 166 At the time of standardization of LDP base specification RFC-3036, 167 the earlier applications using LDP to exchange their FEC bindings 168 were: 170 . Dynamic Label Switching for IP Prefixes 172 . Label-controlled ATM/FR 174 Since then, several new applications have emerged that use LDP to 175 signal their FEC bindings and/or application data: 177 . L2VPN P2P PW ([RFC4447]) 178 . L2VPN P2MP PW ([P2MP-PW]) 180 . mLDP ([MLDP]) 182 . ICCP ([ICCP]) 184 We divide these LDP applications into two broad categories from 185 label advertisement mode usage point of view: 187 1. Session mode-bound Applications (i.e. use the negotiated label 188 advertisement mode) 190 2. Session mode-independent Applications (i.e. do not care about the 191 negotiated label advertisement mode) 193 3.2.1. Session mode-bound Applications 195 The FEC label binding exchange for such LDP applications MUST use the 196 negotiated label advertisement mode. 198 The early LDP applications "Dynamic Label Switching for IP Prefixes" 199 and "Label-controlled ATM/FR" fall into this category. 201 3.2.2. Session mode-independent Applications 203 The FEC label binding, or any other application data, exchange for 204 such LDP applications does not care about, nor tied to the 205 negotiated label advertisement mode of the session; rather, the 206 information exchange is driven by the application need and 207 procedures as described by their respective specifications. For 208 example, [MLDP] specifies procedures to advertise P2MP FEC label 209 binding in an unsolicited manner, irrespective of the negotiated 210 label advertisement mode of the session. 212 The applications, PW (P2P and P2MP), MLDP, and ICCP, fall into this 213 category of LDP application. 215 3.2.2.1. Upstream Label Assignment 217 As opposed to downstream assigned label advertisement defined by 218 [RFC3031], [LDP-UPSTREAM] specification defines new mode of label 219 advertisement where label advertisement and distribution occurs for 220 upstream assigned labels. 222 As stated in earlier section 3.1 of this document, [RFC5036] only 223 allows specifying Downstream-Unsolicited or Downstream-on-Demand 224 mode. This means that any LDP application that requires upstream 225 assigned label advertisement also falls under the category of Session 226 mode-independent application. 228 3.3. Update to RFC-5036 230 For clarification reasons, section 3.5.3 of [RFC5036] is updated to 231 add following two statements under the description of "A, Label 232 Advertisement Discipline": 234 - The negotiated label advertisement discipline only applies to FEC 235 label binding advertisement of "Address Prefix" FECs; 237 - Any document specifying a new FEC SHOULD state the applicability 238 of the negotiated label advertisement discipline for that FEC. 240 3.4. Update to RFC-4447 242 [RFC4447] specifies LDP extensions and procedures to exchange label 243 bindings for P2P PW FECs. The section 3 of [RFC4447] states: 245 "LDP MUST be used in its downstream unsolicited mode." 247 Since PW application falls under session mode-independent 248 application category, the above statement in [RFC4447] should be 249 read to mean as follows: 251 "LDP MUST exchange PW FEC label bindings in downstream unsolicited 252 manner, independent of the negotiated label advertisement mode of 253 the LDP session." 255 4. Future Work 257 This document only clarifies the existing behavior for LDP label 258 advertisement mode for different applications without defining any 259 protocol extensions. In future, a new LDP capability [RFC5561] based 260 mechanism can be defined to signal/negotiate label advertisement 261 mode per FEC/application. 263 5. Security Considerations 265 This document specification only clarifies the applicability of LDP 266 session's label advertisement mode, and hence does not add any LDP 267 security mechanics and considerations to those already defined in 268 LDP specification [RFC5036]. 270 6. IANA Considerations 272 None. 274 7. References 276 7.1. Normative References 278 [RFC5036] Andersson, L., Minei, I., and Thomas, B., Editors, "LDP 279 Specification", RFC 5036, September 2007. 281 [RFC3031] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol 282 Label Switching Architecture", RFC 3031, January 2001. 284 7.2. Informative References 286 [RFC4447] L. Martini, Editor, E. Rosen, El-Aawar, T. Smith, G. 287 Heron, "Pseudowire Setup and Maintenance using the Label 288 Distribution Protocol", RFC 4447, April 2006. 290 [P2MP-PW] Boutros, S., Martini, L., Sivabalan, S., Del Vecchio, G., 291 Kamite, Jin, L., "Signaling Root-Initiated P2MP PWs using 292 LDP", draft-ietf-pwe3-p2mp-pw-02.txt, Work in Progress, 293 March 2011. 295 [MLDP] Minei, I., Kompella, K., Wijnands, I., and Thomas, B., 296 "LDP Extensions for Point-to-Multipoint and Multipoint-to- 297 Multipoint Label Switched Paths", draft-ietf-mpls-ldp-p2mp 298 -14.txt, Work in Progress, June 2011. 300 [ICCP] Martini, L., Salam, S., Sajassi, A., and Matsushima, S., 301 "Inter-Chassis Communication Protocol for L2VPN PE 302 Redundancy", draft-ietf-pwe3-iccp-05.txt, Work in 303 Progress, April 2011. 305 [UPSTREAM-LDP] Aggarwal, R., and Le Roux, J.L., "MPLS Upstream Label 306 Assignment for LDP", draft-ietf-mpls-ldp-upstream-10.txt, 307 Work in Progress, February 2011. 309 [RFC5561] Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and Le 310 Roux, JL., "LDP Capabilities", RFC 5561, July 2009. 312 8. Acknowledgments 314 The authors would like to acknowledge Eric Rosen and Rajiv Asati for 315 their review and input. 317 This document was prepared using 2-Word-v2.0.template.dot. 319 Authors' Addresses 321 Kamran Raza 322 Cisco Systems, Inc. 323 2000 Innovation Drive, 324 Kanata, ON K2K-3E8, Canada. 325 E-mail: skraza@cisco.com 327 Sami Boutros 328 Cisco Systems, Inc. 329 3750 Cisco Way, 330 San Jose, CA 95134, USA. 331 E-mail: sboutros@cisco.com 333 Luca Martini 334 Cisco Systems, Inc. 335 9155 East Nichols Avenue, Suite 400, 336 Englewood, CO 80112, USA. 337 E-mail: lmartini@cisco.com 339 Nicolai Leymann 340 Deutsche Telekom, 341 Email: N.Leymann@telekom.de