idnits 2.17.1 draft-ietf-mpls-special-purpose-labels-06.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 abstract seems to indicate that this document updates RFC6391, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC5921, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC6478, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC5960, but the header doesn't have an 'Updates:' line to match this. -- The abstract seems to indicate that this document updates RFC5586, but the header doesn't have an 'Updates:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3032, updated by this document, for RFC5378 checks: 1997-11-20) -- 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 (March 18, 2014) is 3664 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 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet-Draft Juniper Networks 4 Updates: 3032, 3038, 3209, 3811, 4182, 4928, 5331, L. Andersson 5 5586, 5921, 5960, 6391, 6478, 6790 (if approved) Huawei 6 A. Farrel 7 Intended status: Standards Track Juniper Networks 8 Expires: Septmeber 18, 2014 March 18, 2014 10 Allocating and Retiring Special Purpose MPLS Labels 11 draft-ietf-mpls-special-purpose-labels-06 13 Abstract 15 Some MPLS labels have been allocated for specific purposes. A block 16 of labels (0-15) has been set aside to this end, and are commonly 17 called "reserved labels". They will be called "special purpose 18 labels" in this document. 20 As there are only 16 of these special purpose labels, caution is 21 needed in the allocation of new special purpose labels, yet at the 22 same time allow forward progress when one is called for. 24 This memo defines new procedures to follow in the allocation and 25 retirement of special purpose labels, as well as a method to extend 26 the special purpose label space. Finally, this memo renames the IANA 27 registry for these labels to "Special Purpose MPLS Label Values", and 28 creates a new one called the "Extended Special Purpose MPLS Label 29 Values" registry. 31 This document updates a number of previous RFCs that used the term 32 "reserved label". Specifically, this document updates RFC 3032, RFC 33 3038, RFC 3209, RFC 3811, RFC 4182, RFC 4928, RFC 5331, RFC 5586, RFC 34 5921, RFC 5960, RFC 6391, RFC 6478, and RFC 6790. 36 Status of this Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 50 This Internet-Draft will expire on September 18, 2014. 52 Copyright Notice 54 Copyright (c) 2014 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 respect 62 to this document. Code Components extracted from this document must 63 include Simplified BSD License text as described in Section 4.e of 64 the Trust Legal Provisions and are provided without warranty as 65 described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.1. Conventions used . . . . . . . . . . . . . . . . . . . . . 3 71 2. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1. Extended Special Purpose MPLS Label Values . . . . . . . . 6 74 3.2. Process for Retiring Special Purpose Labels . . . . . . . 7 75 4. Updated RFCs . . . . . . . . . . . . . . . . . . . . . . . . . 8 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 81 8.2. Informational References . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction 86 The specification of the Label Stack Encoding for Multi-Protocol 87 Label Switching (MPLS) [RFC3032] defined four special purpose label 88 values (0 to 3), and set aside values 4 through 15 for future use. 89 These labels have special significance in both the control and the 90 data plane. Since then, three further values have been allocated 91 (values 7, 13, and 14 in [RFC6790], [RFC5586] and [RFC3429], 92 respectively), leaving nine unassigned values from the original space 93 of sixteen. 95 While the allocation of three out of the remaining twelve special 96 purpose label values in the space of about 12 years is not in itself 97 a cause for concern, the scarcity of special purpose labels is. 98 Furthermore, many of the special purpose labels require special 99 processing by forwarding hardware, changes to which are often 100 expensive, and sometimes impossible. Thus, documenting a newly 101 allocated special purpose label value is important. 103 This memo outlines some of the issues in allocating and retiring 104 special purpose label values, and defines mechanisms to address 105 these. This memo also extends the space of special purpose labels. 107 1.1. Conventions used 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in [RFC2119]. 113 Two new acronyms are introduced: 115 XL The Extension Label that indicates that an extended special 116 purpose label follows. 118 ESPL An Extended Special Purpose Label. A Special Purpose Label that 119 is placed in the label stack after the Extension Label. The 120 combination of XL and ESPL might be regarded as a new form of 121 "compound label" comprising more than one consecutive entry in 122 the label stack. 124 2. Questions 126 In re-appraising MPLS special purpose labels, the following questions 127 come to mind: 129 1. What allocation policies should be applied by IANA for the 130 allocation of special purpose labels? Should Early Allocation 131 [RFC7120] be allowed? Should there be labels for Experimental 132 Use or Private Use [RFC5226]? 134 2. What documentation is required for special purpose labels 135 allocated henceforth? 137 3. Should a special purpose label ever be retired? What criteria 138 are relevant here? Can a retired special purpose label ever be 139 re-allocated for a different purpose? What procedures and time 140 frames are appropriate? 142 4. The special purpose label value of 3 (the "Implicit Null Label", 143 [RFC3032]) is only used in signaling, never in the data plane. 144 Could it (and should it) be used in the data plane? If so, how 145 and for what purpose? 147 5. What is a feasible mechanism to extend the space of special 148 purpose labels, should this become necessary? 150 6. Should extended special purpose labels be used for load 151 balancing? 153 3. Answers 155 This section provides answers to the questions posed in the previous 156 section. 158 1. 160 A. Allocation of special purpose MPLS labels is via "Standards 161 Action". 163 B. The IANA registry will be renamed "Special Purpose MPLS 164 Labels". 166 C. Early allocation may be allowed on a case-by-case basis. 168 D. The current space of 16 special purpose labels is too small 169 for setting aside values for experimental or private use. 170 However, the extended special purpose labels registry created 171 by this document has enough space, and this document defines 172 a range for experimental use. 174 2. A Standards Track RFC must accompany a request for allocation of 175 Standards Action special purpose labels, as per [RFC5226]. 177 3. The retirement of a special purpose MPLS label value must follow 178 a strict and well-documented process. This is necessary since we 179 must avoid orphaning the use of this label value in existing 180 deployments. This process is detailed in Section 3.2. 182 4. For now, the use of the "implicit null label" (label 3) in the 183 data plane will not be allowed. If this decision is revisited 184 later, an accompanying Standards Track RFC that details the use 185 of the label, a discussion of possible sources of confusion 186 between signaling and data plane, and mitigation thereof shall be 187 required. 189 5. A special purpose label (the "extension" label, XL, label 15) is 190 set aside for the purpose of extending the space of special 191 purpose labels. Further details are described in Section 3.1. 193 6. [RFC6790] says that special purpose labels MUST NOT be used for 194 load balancing. The same logic applies to extended special 195 purpose labels (ESPLs). Thus, this document specifies that ESPLs 196 MUST NOT be used for load balancing. It is noted that existing 197 implementations would violate this, as they do not recognize XL 198 as anything other than a single Special Purpose Label and will 199 not expect an ESPL to follow. The consequence is that if ESPLs 200 are used in some packets of a flow, these packets may be 201 delivered on different paths and so could be re-ordered. 202 However, it is important to specify the correct behavior for 203 future implementations, hence the use of "MUST NOT". 205 A further question that needed to be settled in this regard was 206 whether a "regular" special purpose label retains its meaning if it 207 follows the XL. The answer to this question is provided in Section 208 3.1. 210 3.1. Extended Special Purpose MPLS Label Values 212 The XL MUST be followed by another label L (and thus MUST have the 213 bottom-of-stack bit clear). L MUST be interpreted as an ESPL and 214 interpreted as defined in a new registry created by this document 215 (see Section 5). Whether or not L has the bottom-of-stack bit set 216 depends on whether other labels follow L. The XL only assigns 217 special meaning to L. A label after L (if any) is parsed as usual, 218 and thus may be a regular label or a special purpose label; if the 219 latter, it may be the XL, and thus followed by another ESPL. 221 The label value 15 is set aside as the XL as shown in Section 5. 223 Values 0-6 and 8-15 of the Extended Special Purpose Label registry 224 are set aside as reserved; these MUST NOT appear in the data plane. 225 If an LSR encounters such ESPL values it MUST treat the packet as 226 malformed and discard it per [RFC3031]. 228 Label 7 (when received) retains its meaning as ELI whether a regular 229 special purpose label or an ESPL; this is because of backwards 230 compatibility with existing implemented and deployed code and 231 hardware that looks for the ELI without verifying if the previous 232 label is XL or not. However, when an LSR insert an entropy label 233 it MUST insert the ELI as a regular special purpose label, not as 234 an ESPL. 236 3.1.1. Forwarding Packets with Extended Special Purpose Labels 238 If an LSR encounters the XL at the top of stack and it doesn't 239 understand extension labels, it SHOULD drop the packet as specified 240 for the handling of any unknown label according to [RFC3031]. If an 241 LSR encounters an ESPL at the top of stack (after the XL) and does 242 not understand the ESPL, it SHOULD drop the packet, again following 243 the procedures for unknown labels as set out in [RFC3031]. In either 244 case, the LSR MAY log the event, but such logging MUST be rate- 245 limited. 247 An LSR SHOULD NOT make forwarding decisions on labels not at the top 248 of stack. For load balancing decisions, see Answer 6 of Section 3. 250 3.1.2. Choosing a New Special Purpose Label 252 When allocating a new Special Purpose Label, protocol designers 253 should consider whether they could use an Extended Special Purpose 254 Label. Doing so would help to preserve the scarce resources of 255 "normal" Special Purpose Labels for use in cases where minimizing the 256 label stack size is particularly important. 258 3.2. Process for Retiring Special Purpose Labels 260 While the following process is defined for the sake of completeness, 261 note that retiring special purpose labels is difficult. It is 262 recommended that this process be used sparingly. 264 a. A label value that has been assigned from the "Special Purpose 265 MPLS Label Values" may be deprecated by IETF consensus with 266 review by the MPLS working group (or designated experts if the 267 working group or a successor does not exist). An RFC with at 268 least Informational status is required. 270 The RFC will direct the IANA to mark the label value as 271 "deprecated" in the registry, but will not release it at this 272 stage. 274 Deprecating means that no further specifications using the 275 deprecated value will be documented. 277 At the same time this is an indication to vendors not to include 278 the deprecated value in new implementations, and to operators to 279 avoid including it in new deployments. 281 b. 12 months after the RFC deprecating the label value is published, 282 an IETF-wide survey may be conducted to determine if the 283 deprecated label value is still in use. If the survey indicates 284 that the deprecated label value is in use, the survey may be 285 repeated after a further 6 months. 287 c. 24 months after the RFC that deprecated the label value was 288 published and if the survey indicates that deprecated label value 289 is not in use, publication may be requested of an IETF Standards 290 Track Internet-Draft that retires the deprecated the label value. 291 This document will request IANA to release the label value for 292 future use and assignment. 294 4. Updated RFCs 296 The following RFCs contain references to the term "reserved labels": 298 o [RFC3032] ("MPLS Label Stack Encoding"), 299 o [RFC3038] ("VCID Notification for LDP") 300 o [RFC3209] ("Extensions to RSVP for LSP Tunnels") 301 o [RFC3811] ("MPLS TC MIB") 302 o [RFC4182] ("Removing a Restriction on the use of MPLS") 303 o [RFC4928] ("Avoiding ECMP Treatment in MPLS Networks") 304 o [RFC5331], [RFC5586] ("G-ACh and GAL") 305 o [RFC5921] ("MPLS Transport Profile Framework") 306 o [RFC5960] ("MPLS-TP Data Plane Architecture") 307 o [RFC6391] ("FAT-PW") 308 o [RFC6478] ("Pseudowire Status for Static Pseudowires") 309 o [RFC6790] ("MPLS Entropy Labels"). 311 All such references should be read as "special purpose labels". 313 5. IANA Considerations 315 This document requests IANA to make the following changes and 316 additions to its registration of MPLS Labels. 318 1. Change the name of the "Multiprotocol Label Switching 319 Architecture (MPLS) Label Values" registry to the "Special 320 Purpose MPLS Label Values". 322 2. Change the allocations policy for the "Special Purpose MPLS Label 323 Values" registry to Standards Action. 325 3. Assign label 15 from the "Special Purpose MPLS Label Values" 326 registry, naming it the "extension label", and citing this 327 document as the reference. 329 4. Create a new registry called the "Extended Special Purpose MPLS 330 Label Values" registry. The ranges and allocation policies for 331 this registry are as follows in Table 1 (using terminology from 332 [RFC5226]). Early allocation following the policy defined in 333 [RFC7120] is allowed only for those values assigned by Standards 334 Action. 336 +---------------------+---------------------------------------------+ 337 | Range | Allocation Policy | 338 +---------------------+---------------------------------------------+ 339 | 0 - 15 | Reserved. Not to be allocated. | 340 | | | 341 | 16 - 239 | Standards Action | 342 | | | 343 | 240 - 255 | Experimental | 344 | | | 345 | 256 - 1048575 | Reserved. Not to be allocated without a new | 346 | | Standards Track RFC to define an allocation | 347 | | policy. 348 +---------------------+---------------------------------------------+ 350 Table 1 352 6. Security Considerations 354 This document does not make a large change to the operation of the 355 MPLS data plane and security considerations are largely unchanged 356 from those specified in the MPLS architecture [RFC3031] and in the 357 MPLS and GMPLS Security Framework [RFC5920]. 359 However, it should be noted that increasing the label stack can cause 360 packet fragmentation and may also make packets unprocessable by some 361 implementations. This document provides a protocol-legal way to 362 increase the label stack through the insertion of additional 363 {XL,ESPL} pairs at a greater rate than insertion of single "rogue" 364 labels. This might provide a way to attack some nodes in a network 365 that can only process label stacks of a certain size without 366 violating the protocol rules. 368 This document also describes events that may cause an LSR to issue 369 event logs at a per-packet rate. It is critically important that 370 implementations rate-limit such logs. 372 7. Acknowledgments 374 Thanks to Pablo Frank and Lizhong Jin for useful discussions. 375 Thanks to Curtis Villamizar, Mach Chen, Alia Atlas, Eric Rosen, 376 Maria Napierala, Roni Even, Stewart Bryant, John Drake, Andy Malis, 377 and Tom Yu for useful comments. 379 8. References 381 8.1. Normative References 383 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 384 Requirement Levels", BCP 14, RFC 2119, March 1997. 386 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 387 Label Switching Architecture", RFC 3031, January 2001. 389 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 390 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 391 Encoding", RFC 3032, January 2001. 393 [RFC3038] Nagami, K., Katsube, Y., Demizu, N., Esaki, H., and P. 394 Doolan, "VCID Notification over ATM link for LDP", 395 RFC 3038, January 2001. 397 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 398 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 399 Tunnels", RFC 3209, December 2001. 401 [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual 402 Conventions (TCs) for Multiprotocol Label Switching (MPLS) 403 Management", RFC 3811, June 2004. 405 [RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS 406 Explicit NULL", RFC 4182, September 2005. 408 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 409 Cost Multipath Treatment in MPLS Networks", BCP 128, 410 RFC 4928, June 2007. 412 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 413 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 414 May 2008. 416 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 417 Label Assignment and Context-Specific Label Space", 418 RFC 5331, August 2008. 420 [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport 421 Profile Data Plane Architecture", RFC 5960, August 2010. 423 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 424 J., and S. Amante, "Flow-Aware Transport of Pseudowires 425 over an MPLS Packet Switched Network", RFC 6391, 426 November 2011. 428 [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, 429 "Pseudowire Status for Static Pseudowires", RFC 6478, 430 May 2012. 432 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 433 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 434 RFC 6790, November 2012. 436 [RFC7120] Cotton, M., "Early IANA Allocation of Standards Track Code 437 Points", BCP 100, RFC 7120, January 2014. 439 8.2. Informational References 441 [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for 442 Multiprotocol Label Switching Architecture (MPLS) 443 Operation and Maintenance (OAM) Functions", RFC 3429, 444 November 2002. 446 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 447 Associated Channel", RFC 5586, June 2009. 449 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 450 Networks", RFC 5920, July 2010. 452 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 453 Berger, "A Framework for MPLS in Transport Networks", 454 RFC 5921, July 2010. 456 Authors' Addresses 458 Kireeti Kompella 459 Juniper Networks 460 1194 N. Mathilda Ave 461 Sunnyvale, CA 94089 462 US 464 Email: kireeti.kompella@gmail.com 466 Loa Andersson 467 Huawei 469 Email: loa@mail01.huawei.com 471 Adrian Farrel 472 Juniper Networks 474 Email: adrian@olddog.co.uk