idnits 2.17.1 draft-kompella-mpls-special-purpose-labels-04.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 RFC4928, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3038, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5331, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC6L., but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3811, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5921, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC4182, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3032, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC3209, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5960, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC5586, but the abstract doesn't seem to mention this, which it should. 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 (May 27, 2013) is 3987 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 4020 (Obsoleted by RFC 7120) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5920 ** Downref: Normative reference to an Informational RFC: RFC 5921 Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 13 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,5586,5921,5960,6L. Andersson 5 Intended status: Standards Track Huawei 6 Expires: November 28, 2013 A. Farrel 7 Juniper Networks 8 May 27, 2013 10 Allocating and Retiring Special Purpose MPLS Labels 11 draft-kompella-mpls-special-purpose-labels-04 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. As there are only 16 of these labels, 19 caution is needed in the allocation of new special purpose labels, 20 yet at the same time allow forward progress when one is called for. 21 This memo defines some procedures to follow in the allocation and 22 retirement of special purpose labels, as well as a method to extend 23 the special purpose label space. Finally, this memo renames the IANA 24 registry for these labels to "Special Purpose MPLS Label Values", and 25 creates a new one called the "Extended Special Purpose MPLS Label 26 Values" registry. 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). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on November 28, 2013. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Conventions used . . . . . . . . . . . . . . . . . . . . 3 64 2. Questions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3.1. Extended Special Purpose MPLS Label Values . . . . . . . 4 67 3.2. Process for Retiring Special Purpose Labels . . . . . . . 5 68 4. Updated RFCs . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 7.2. Informational References . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 The specification of the Label Stack Encoding for Multi-Protocol 79 Label Switching (MPLS) [RFC3032] defined four special purpose label 80 values (0 to 3), and set aside values 4 through 15 for future use. 81 These labels have special significance in both the control and the 82 data plane. Since then, three further values have been allocated 83 (values 7, 13, and 14 in [RFC6790], [RFC5586] and [RFC3429], 84 respectively), leaving nine unassigned values from the original space 85 of sixteen. 87 While the allocation of three out of the remaining twelve special 88 purpose label values in the space of about 12 years is not in itself 89 a cause for concern, the scarcity of special purpose labels is. 90 Furthermore, many of the special purpose labels require special 91 processing by forwarding hardware, changes to which are often 92 expensive, and sometimes impossible. Thus, documenting a newly 93 allocated special purpose label value is important. 95 This memo outlines some of the issues in allocating and retiring 96 special purpose label values, and defines mechanisms to address 97 these. This memo also extends the space of special purpose labels. 99 1.1. Conventions used 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2. Questions 107 In re-appraising MPLS special purpose labels, the following questions 108 come to mind: 110 1. What allocation policies should be applied by IANA for the 111 allocation of special purpose labels? Should Early Allocation 112 [RFC4020] be allowed? Should there be labels for Experimental 113 Use or Private Use [RFC5226]? 115 2. What documentation is required for special purpose labels 116 allocated henceforth? 118 3. Should a special purpose label ever be retired? What criteria 119 are relevant here? Can a retired special purpose label ever be 120 re-allocated for a different purpose? What procedures and time 121 frames are appropriate? 123 4. The special purpose label value of 3 (the "Implicit Null Label", 124 [RFC3032]) is only used in signaling, never in the data plane. 125 Could it (and should it) be used in the data plane? If so, how 126 and for what purpose? 128 5. What is a feasible mechanism to extend the space of special 129 purpose labels, should this become necessary? 131 3. Answers 133 This section provides answers to the questions posed in the previous 134 section. 136 1. 138 a. Allocation of special purpose MPLS labels is via "Standards 139 Action". 141 b. The IANA registry will be renamed "Special Purpose MPLS 142 Labels". 144 c. Early allocation may be allowed on a case-by-case basis. 146 d. The current space of 16 special purpose labels is too small 147 for setting aside value for experimental or private use. 148 However, the extended special purpose labels registry created 149 by this document has enough space, and this document defines 150 a range for experimental use. 152 2. A Standards Track RFC must accompany a request for allocation of 153 Standards Action special purpose labels, as per [RFC5226]. 155 3. The retirement of a special purpose MPLS label value must follow 156 a strict and well-documented process. This is necessary since we 157 must avoid orphaning the use of this label value in existing 158 deployments. This process is detailed in Section 3.2. 160 4. For now, the use of the "implicit null label" (label 3) in the 161 data plane will not be allowed. If this decision is revisited 162 later, an accompanying Standards Track RFC that details the use 163 of the label, a discussion of possible sources of confusion 164 between signaling and data plane, and mitigation thereof. 166 5. A special purpose label (the "extension" label, label 15) is to 167 be set aside for the purpose of extending the space of special 168 purpose labels. Further details are described in Section 3.1. 170 A further question to be settled in this regard is whether a 171 "regular" special purpose label retains its meaning if it follows the 172 extension label; see Section 3.1. 174 3.1. Extended Special Purpose MPLS Label Values 176 An extension label MUST be followed by another label L (and thus MUST 177 have the bottom-of-stack bit clear). L MUST be interpreted as an 178 "extended special purpose label" and interpreted as defined in a new 179 registry created by this document (see Section 5). Whether or not L 180 has the bottom-of-stack bit set depends on whether other labels 181 follow L. The extension label only assigns special meaning to L. A 182 label after L (if any) is parsed as usual, and thus may be a regular 183 label, a special purpose label or (if prefixed by another extension 184 label) an extended special purpose label. 186 IANA is asked to set aside label value 15 as the extension label. 188 Values 0-6 and 8-15 of the extended special purpose label registry 189 are set aside as reserved; these MUST NOT appear in the data plane. 190 Label 7 (when received) retains its meaning as ELI whether a regular 191 or an extended special purpose label; however, an implementation 192 SHOULD NOT insert a label of 7 as an extended special purpose label, 193 preferring instead to send 7 as a regular special purpose label. 195 3.2. Process for Retiring Special Purpose Labels 197 While the following process is defined for the sake of completeness, 198 note that retiring special purpose labels is difficult. It is 199 recommended that this process be used sparingly. 201 a. A label value that has been assigned from the "Special Purpose 202 MPLS Label Values" may be deprecated by IETF consensus with 203 review by the MPLS working group (or designated experts if the 204 working group or a successor does not exist). An RFC with at 205 least Informational status is required. 207 The RFC will direct the IANA to mark the label value as 208 "deprecated" in the registry, but will not release it at this 209 stage. 211 Deprecating means that no further specifications using the 212 deprecated value will be documented. 214 At the same time this is an indication to vendors not to include 215 deprecated value in new implementations and to operators to avoid 216 including it in new deployments. 218 b. 12 months after the RFC deprecating the label value is published, 219 an IETF-wide survey may be conducted to determine if the 220 deprecated label value is still in use. If the survey indicates 221 that the deprecated label value is in use, the survey may be 222 repeated after a further 6 months. 224 c. 24 months after the RFC that deprecated the label value was 225 published and if the survey indicates that deprecated label value 226 is not in use, publication may be requested of an IETF Standards 227 Track Internet-Draft that retires the deprecated the label value. 228 This document will request IANA to release the label value for 229 for future use and assignment. 231 4. Updated RFCs 233 The following RFCs contain references to the term "reserved labels": 234 [RFC3032] ("MPLS Label Stack Encoding"), [RFC3038] ("VCID 235 Notification for LDP"), [RFC3209] ("Extensions to RSVP for LSP 236 Tunnels"), [RFC3811] ("MPLS TC MIB"), [RFC4182] ("Removing a 237 Restriction on the use of MPLS"), [RFC4928] ("Avoiding ECMP Treatment 238 in MPLS Networks"), [RFC5331], [RFC5586] ("G-ACh and GAL"), [RFC5921] 239 ("MPLS Transport Profile Framework"), [RFC5960] ("MPLS-TP Data Plane 240 Architecture"), [RFC6790] ("MPLS Entropy Labels"), [RFC6391] ("FAT- 241 PW"), and [RFC6478] ("Pseudowire Status for Static Pseudowires"). 242 All such references should be read as "special purpose labels". 244 5. IANA Considerations 246 This document requests IANA to make the following changes and 247 additions to its registration of MPLS Labels. 249 1. Change the name of the "Multiprotocol Label Switching 250 Architecture (MPLS) Label Values" registry to the "Special 251 Purpose MPLS Label Values". 253 2. Change the allocations policy for the "Special Purpose MPLS Label 254 Values" registry to Standards Action. 256 3. Note: any new allocation from the Special Purpose MPLS Label 257 Values registry MUST be also say whether the same value needs to 258 be reserved in the Extended Special Purpose MPLS Label Values 259 registry. 261 4. Assign label 15 from the "Special Purpose MPLS Label Values" 262 registry, naming it the "extension label", and citing this 263 document as the reference. 265 5. Create a new registry called the "Extended Special Purpose MPLS 266 Label Values" registry. The ranges and allocation policies for 267 this registry are as follows (using terminology from [RFC5226]). 268 Early allocation following the policy defined in [RFC4020] is 269 allowed only for those values assigned by Standards Action. 271 +------------------+------------------------------------------------+ 272 | Range | Allocation Policy | 273 +------------------+------------------------------------------------+ 274 | 0 - 6, 8 - 15 | Reserved. Not to be allocated. MUST NOT | 275 | | appear in the data plane. | 276 | | | 277 | 7 | Allocated; meaning is ELI [RFC6790] | 278 | | | 279 | 16 - TBD1 | Standards Action | 280 | | | 281 | TBD1+1 - TBD2 | Reserved | 282 | | | 283 | TBD2+1 - 1048559 | First Come, First Served | 284 | | | 285 | 1048560 - | Experimental | 286 | 1048575 | | 287 +------------------+------------------------------------------------+ 289 Table 1 291 6. Security Considerations 293 This document does not make a large change to the operation of the 294 MPLS data plane and security considerations are largely unchanged 295 from those specified in the MPLS architecture [RFC3031] and in the 296 MPLS and GMPLS Security Framework [RFC5920]. 298 However, it should be noted that increasing the label stack can cause 299 packet fragmentation and may also make packets unprocessable by some 300 implementations. This document provides a protocol-legal way to 301 arbitrarily increase the label stack and so might provide a way to 302 attack some nodes in a network without violating the protocol rules. 304 7. References 306 7.1. Normative References 308 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 309 Requirement Levels", BCP 14, RFC 2119, March 1997. 311 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 312 Label Switching Architecture", RFC 3031, January 2001. 314 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 315 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 316 Encoding", RFC 3032, January 2001. 318 [RFC3038] Nagami, K., Katsube, Y., Demizu, N., Esaki, H., and P. 319 Doolan, "VCID Notification over ATM link for LDP", RFC 320 3038, January 2001. 322 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 323 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 324 Tunnels", RFC 3209, December 2001. 326 [RFC3811] Nadeau, T. and J. Cucchiara, "Definitions of Textual 327 Conventions (TCs) for Multiprotocol Label Switching (MPLS) 328 Management", RFC 3811, June 2004. 330 [RFC4020] Kompella, K. and A. Zinin, "Early IANA Allocation of 331 Standards Track Code Points", BCP 100, RFC 4020, February 332 2005. 334 [RFC4182] Rosen, E., "Removing a Restriction on the use of MPLS 335 Explicit NULL", RFC 4182, September 2005. 337 [RFC4928] Swallow, G., Bryant, S., and L. Andersson, "Avoiding Equal 338 Cost Multipath Treatment in MPLS Networks", BCP 128, RFC 339 4928, June 2007. 341 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 342 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 343 May 2008. 345 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 346 Label Assignment and Context-Specific Label Space", RFC 347 5331, August 2008. 349 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 350 Networks", RFC 5920, July 2010. 352 [RFC5921] Bocci, M., Bryant, S., Frost, D., Levrau, L., and L. 353 Berger, "A Framework for MPLS in Transport Networks", RFC 354 5921, July 2010. 356 [RFC5960] Frost, D., Bryant, S., and M. Bocci, "MPLS Transport 357 Profile Data Plane Architecture", RFC 5960, August 2010. 359 [RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 360 J., and S. Amante, "Flow-Aware Transport of Pseudowires 361 over an MPLS Packet Switched Network", RFC 6391, November 362 2011. 364 [RFC6478] Martini, L., Swallow, G., Heron, G., and M. Bocci, 365 "Pseudowire Status for Static Pseudowires", RFC 6478, May 366 2012. 368 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 369 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 370 RFC 6790, November 2012. 372 7.2. Informational References 374 [RFC3429] Ohta, H., "Assignment of the 'OAM Alert Label' for 375 Multiprotocol Label Switching Architecture (MPLS) 376 Operation and Maintenance (OAM) Functions", RFC 3429, 377 November 2002. 379 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 380 Associated Channel", RFC 5586, June 2009. 382 Authors' Addresses 383 Kireeti Kompella 384 Juniper Networks 385 1194 N. Mathilda Ave 386 Sunnyvale, CA 94089 387 US 389 Email: kireeti.kompella@gmail.com 391 Loa Andersson 392 Huawei 394 Email: loa@mail01.huawei.com 396 Adrian Farrel 397 Juniper Networks 399 Email: adrian@olddog.co.uk