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