idnits 2.17.00 (12 Aug 2021) /tmp/idnits54428/draft-ietf-mpls-spl-terminology-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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 21, 2021) is 478 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'SPL-NAME-SPACE' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group L. Andersson 3 Internet-Draft Bronze Dragon Consulting 4 Updates: 3032, 7274 (if approved) K. Kompella 5 Intended status: Standards Track Juniper Networks 6 Expires: July 25, 2021 A. Farrel 7 Old Dog Consulting 8 January 21, 2021 10 Special Purpose Label terminology 11 draft-ietf-mpls-spl-terminology-06 13 Abstract 15 This document discusses and recommends a terminology that may be used 16 when MPLS Special Purpose Labels (SPL) are specified and documented. 18 This document applies that terminology change to the relevant IANA 19 registry and also clarifies the use of the Entropy Label Indicator 20 (7) when immediately preceded by the Extension Label (15). 22 This document updates RFC 7274 and RFC 3032. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on July 25, 2021. 41 Copyright Notice 43 Copyright (c) 2021 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2.1. GMPLS Special Purpose Labels . . . . . . . . . . . . . . 3 62 3. Terminology and Abbreviations . . . . . . . . . . . . . . . . 3 63 4. Clarification on Handling of the Entropy Label Indicator . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 68 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 70 9.2. Informative References . . . . . . . . . . . . . . . . . 7 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 73 1. Introduction 75 RFC 7274 [RFC7274] made some changes to the terminology used for MPLS 76 Special Purpose Labels, but did not define consistent terminology. 78 One thing that RFC 7274 did was to deprecate use of the term 79 "reserved labels" when describing a range of labels allocated from a 80 registry maintained by IANA. The term "Reserved" in such a registry 81 means "set aside, not to be used", but that range of labels was 82 available for allocation according to the policies set out in that 83 registry. The name "Special Purpose Labels" was introduced in RFC 84 7274 in place of the previous term, and the abbreviation SPL was 85 recommended. 87 At the time of writing the first version of this document, the IETF 88 was in the process of allocating the very first SPLs from the 89 Extended SPL (eSPL) range [RFC8595]. This document discusses and 90 recommends terminology and abbreviations to be used when talking 91 about and documenting Special Purpose Labels. 93 This document updates RFC 3032 [RFC3032] and RFC 7274 [RFC7274] in 94 that it changes the terminology for both Base SPLs and Extended SPLs. 96 This document applies that terminology change to the relevant IANA 97 registry and also clarifies the use of the Entropy Label Indicator 98 (7) when immediately preceded by the Extension Label (15). 100 1.1. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in BCP 105 14 [RFC2119] [RFC8174] when, and only when, they appear in all 106 capitals, as shown here. 108 2. Background 110 Two sets of SPLs are defined for use in MPLS: 112 The range of 0-15, Base Special Purpose Labels (bSPLs), is 113 specified in RFC 3032 [RFC3032]. 115 The range 0-1048575 of eSPLs is specified in RFC 7274 [RFC7274]. 117 * the values 0-15 have been reserved never to be allocated 119 * the values 16-239 are available for allocation 121 * the values 240-255 are for experimental use 123 * the values 256-1048575 are currently not available for 124 allocation. A standard track RFC will be needed to allocate 125 any labels from this range. 127 2.1. GMPLS Special Purpose Labels 129 Note that IANA maintains a registry called "Special Purpose 130 Generalized Label Values". Labels in that registry have special 131 meaning when present in certain signalling objects, are 32 bits long, 132 and are not to be confused with MPLS forwarding plane labels. This 133 document does not make any changes to the GMPLS registry or to how 134 labels from that registry are described. 136 3. Terminology and Abbreviations 138 IANA maintains a name space for 'Special-Purpose Multiprotocol Label 139 Switching (MPLS) Label Values' code points [SPL-NAME-SPACE]. Within 140 this name space there are two registries. One is called the 141 'Special-Purpose MPLS Label Values' registry [bSPL]. The other is 142 called 'Extended Special-Purpose MPLS Label Values' registry [eSPL]. 144 The difference in the name of the name space and the first registry 145 is only that the MPLS abbreviation is expanded. This document 146 changes the name of the first registry to 'Base Special-Purpose MPLS 147 Label Values', but leaves the name of the latter registry unchanged 148 as 'Extended Special-Purpose MPLS Label Values'. 150 The following conventions will be used in specifications and when 151 talking about SPLs. 153 o Collectively, the two (unrelated) ranges (0-15 and 16-1048575) are 154 known as Special Purpose Labels (SPL). 156 o Special purpose labels from the range 0-15 are called Base Special 157 Purpose Labels (bSPL). 159 o Special purpose labels from the range 16-1048575 are called 160 Extended Special Purpose Labels (eSPL). (Note that the reserved 161 values 0-15 from the 'Extended Special-Purpose MPLS Label Values' 162 registry do not need a name as they are not available for 163 allocation and MUST NOT be used.) 165 o The combination of the Extension Label (XL) (value 15 which is a 166 bSPL, and which is also called the xSPL) and an eSPL is called a 167 Composite Special Purpose Label (cSPL). 169 This results in a label stacks such as the illustrative examples 170 shown in Figure 1 and Figure 2. 172 0 31 173 | MPLS Label Stack entry | 174 +--------+--------+--------+--------+ 175 | MPLS Label Stack entry | 176 +--------+--------+--------+--------+ 177 bSPL | Base SPL | 178 +--------+--------+--------+--------+ 179 | MPLS Label Stack entry (cont.) | 181 Figure 1: Example of Label Stack 183 0 31 184 | MPLS Label Stack entry | 185 +--------+--------+--------+--------+ 186 | MPLS Label Stack entry | 187 +--------+--------+--------+--------+ 188 xSPL | Extension Label (XL) | <--+ 189 +--------+--------+--------+--------+ |--- cSPL 190 eSPL | Extended SPL | <--+ 191 +--------+--------+--------+--------+ 192 | MPLS Label Stack entry (cont.) | 194 Figure 2: Example of Label Stack 196 4. Clarification on Handling of the Entropy Label Indicator 198 Section 3.1 of [RFC7274] contains two paragraphs that describe the 199 handling of the Entropy Label Indicator (label 7). These paragraphs 200 have introduced some confusion about whether the Entropy Label 201 Indicator can be present when immediately preceded by the Extension 202 Label. This document updates [RFC7274] by replacing those paragraphs 203 as follows. 205 OLD 207 Values 0-15 of the "Extended Special-Purpose MPLS Label Values" 208 registry are set aside as reserved. Furthermore, values 0-6 and 209 8-15 MUST NOT appear in the data plane following an XL; an LSR 210 processing a packet with an XL at the top of the label stack 211 followed by a label with value 0-6 or 8-15 MUST drop the packet. 213 Label 7 (when received) retains its meaning as Entropy Label 214 Indicator (ELI) whether a regular special-purpose label or an 215 ESPL; this is because of backwards compatibility with existing 216 implemented and deployed code and hardware that looks for the ELI 217 without verifying if the previous label is XL or not. However, 218 when an LSR inserts an entropy label, it MUST insert the ELI as a 219 regular special-purpose label, not as an ESPL. 221 NEW 223 Values 0-15 of the "Extended Special-Purpose MPLS Label Values" 224 registry are set aside as reserved. Furthermore, an 225 implementation MUST NOT place a label with value 0-15 in the label 226 stack immediately following an XL; an LSR processing a packet with 227 an XL at the top of the label stack immediately followed by a 228 label with value 0-15 MUST drop the packet. 230 When inspecting a label stack to find an Entropy Label Indicator 231 (ELI - label 7) a pre-existing implementation may fail to inspect 232 the previous label, and so not notice that it is an XL. Such 233 systems can continue to process the entropy information and 234 forward the packet when the previous label is an XL without 235 causing harm. However, the packet will be dropped when the XL 236 reaches the top of the stack at another LSR. 238 END 240 5. Security Considerations 242 The document describes the terminology to be used when describing and 243 specifying the use of SPLs. It does not effect the forwarding in the 244 MPLS data plane, nor does it have any effect on how LSPs are 245 established by an MPLS control plane or by a centralized controller. 247 This document does not aim to describe existing implementations of 248 SPLs or potential vulnerabilities of SPLs. 250 6. IANA Considerations 252 IANA is requested to change the name of the registry that today is 253 called "Special-Purpose MPLS Label Values" is changed to "Base 254 Special- Purpose MPLS Label Values". 256 7. Acknowledgements 258 We like to thank the Routing Directorate reviwer Eric Gray for a 259 detailed, careful and insightful review, and Tom Petch for pointing 260 out several issues of clarity. 262 8. Contributors 264 The following people contributed text to this document: 266 Stewart Bryant 267 Futurewei Technologies Inc. 269 Email: stewart.bryant@gmail.com 271 9. References 272 9.1. Normative References 274 [bSPL] "Special-Purpose MPLS Label Values", 275 . 278 [eSPL] "Extended Special-Purpose MPLS Label Values", 279 . 282 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 283 Requirement Levels", BCP 14, RFC 2119, 284 DOI 10.17487/RFC2119, March 1997, 285 . 287 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 288 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 289 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 290 . 292 [RFC7274] Kompella, K., Andersson, L., and A. Farrel, "Allocating 293 and Retiring Special-Purpose MPLS Labels", RFC 7274, 294 DOI 10.17487/RFC7274, June 2014, 295 . 297 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 298 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 299 May 2017, . 301 [SPL-NAME-SPACE] 302 "Special-Purpose Multiprotocol Label Switching (MPLS) 303 Label Values", . 306 9.2. Informative References 308 [RFC8595] Farrel, A., Bryant, S., and J. Drake, "An MPLS-Based 309 Forwarding Plane for Service Function Chaining", RFC 8595, 310 DOI 10.17487/RFC8595, June 2019, 311 . 313 Authors' Addresses 315 Loa Andersson 316 Bronze Dragon Consulting 318 Email: loa@pi.nu 319 Kireeti Kompella 320 Juniper Networks 322 Email: kireeti@juniper.net 324 Adrian Farrel 325 Old Dog Consulting 327 Email: adrian@olddog.co.uk