idnits 2.17.1
draft-ietf-mpls-lsp-ping-registries-update-02.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
-- The document date (April 16, 2020) is 1471 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. 'IANA-LSP-PING'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-MT'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-RC'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-RM'
-- Possible downref: Non-RFC (?) normative reference: ref.
'IANA-Sub-1-16-21'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-Sub-11'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-Sub-20'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-Sub-23'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-Sub-27'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-Sub-6'
-- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-TLV-reg'
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 12 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: 8029, 8611 (if approved) M. Chen
5 Intended status: Standards Track Huawei Techologies
6 Expires: October 18, 2020 C. Pignataro
7 Cisco Systems
8 T. Saad
9 Juniper Networks
10 April 16, 2020
12 Updating the IANA MPLS LSP Ping Parameters
13 draft-ietf-mpls-lsp-ping-registries-update-02
15 Abstract
17 This document updates RFC 8029 and RFC 8611 that both define IANA
18 registries for MPLS LSP Ping. It also updates the language that is
19 used to define the procedures for responses are sent when an unkwon
20 or errored code point is found. The updates are for clarification
21 and to align this name space with recent developments.
23 Status of This Memo
25 This Internet-Draft is submitted in full conformance with the
26 provisions of BCP 78 and BCP 79.
28 Internet-Drafts are working documents of the Internet Engineering
29 Task Force (IETF). Note that other groups may also distribute
30 working documents as Internet-Drafts. The list of current Internet-
31 Drafts is at https://datatracker.ietf.org/drafts/current/.
33 Internet-Drafts are draft documents valid for a maximum of six months
34 and may be updated, replaced, or obsoleted by other documents at any
35 time. It is inappropriate to use Internet-Drafts as reference
36 material or to cite them other than as "work in progress."
38 This Internet-Draft will expire on October 18, 2020.
40 Copyright Notice
42 Copyright (c) 2020 IETF Trust and the persons identified as the
43 document authors. All rights reserved.
45 This document is subject to BCP 78 and the IETF Trust's Legal
46 Provisions Relating to IETF Documents
47 (https://trustee.ietf.org/license-info) in effect on the date of
48 publication of this document. Please review these documents
49 carefully, as they describe your rights and restrictions with respect
50 to this document. Code Components extracted from this document must
51 include Simplified BSD License text as described in Section 4.e of
52 the Trust Legal Provisions and are provided without warranty as
53 described in the Simplified BSD License.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
58 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
59 2. Updating the Message Types, Reply Mode and Return Codes
60 Registries . . . . . . . . . . . . . . . . . . . . . . . . . 3
61 3. Updating the TLV and sub-TLV registries . . . . . . . . . . . 4
62 3.1. General principles the LSP Ping TLV and sub-TLV
63 registries . . . . . . . . . . . . . . . . . . . . . . . 4
64 3.1.1. Unrecognized Experimental and Private TLVs and sub-
65 TLVs . . . . . . . . . . . . . . . . . . . . . . . . 5
66 3.2. Changes to the LSP Ping Registries . . . . . . . . . . . 5
67 3.2.1. Common Changes to the TLV and sub-TLV Registries . . 5
68 4. Text Chages/Updates to Related RFCs . . . . . . . . . . . . . 6
69 4.1. Text Changes to RFC 8029 . . . . . . . . . . . . . . . . 6
70 4.2. Text Changes to RFC 8611 . . . . . . . . . . . . . . . . 7
71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
73 6.1. Updates of Message Type, Reply Mode and Return Codes
74 Registries . . . . . . . . . . . . . . . . . . . . . . . 8
75 6.2. Common Registration Procedures for TLVs and sub-TLVs . . 9
76 6.3. IANA Assignments for TLVs and sub-TLVs . . . . . . . . . 9
77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
79 8.1. Normative References . . . . . . . . . . . . . . . . . . 11
80 8.2. Informative References . . . . . . . . . . . . . . . . . 12
81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
83 1. Introduction
85 When RFC 8029 [RFC8029] was published it contained updates to the
86 "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs)
87 Ping Parameters" IANA name space [IANA-LSP-PING].
89 RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC
90 8029. This document further clarifies the entries in those
91 registries and makes the definitions more precise.
93 This document updates RFC 8029 [[RFC8029] and RFC 8611 [RFC8611] by
94 updating two groups of registries as follows:
96 First the registries for Message Types [IANA-MT], Reply Modes
97 [IANA-RM] and Return Codes [IANA-RC] are updated. The changes to
98 these registries are minor.
100 Second, this document updates the TLV and sub-TLV registries.
102 o TLVs [IANA-TLV-reg]
104 o Sub-TLVs for TLVs 1, 16 and 21 [IANA-Sub-1-16-21]
106 o Sub-TLVs for TLV 6 [IANA-Sub-6]
108 o Sub-TLVs for TLV 11 [IANA-Sub-11]
110 o Sub-TLVs for TLV 20 [IANA-Sub-20]
112 o Sub-TLVs for TLV 23 [IANA-Sub-23]
114 o Sub-TLVs for TLV 27 [IANA-Sub-27]
116 The registry for sub-TLVs for TLV 9 [IANA-Sub-9] is not updated.
118 Third, some code points (TLVs and sub-TLVs) are "mandatory" and
119 "optional". Contrary to how other RFCs use these words, indicating
120 that it is mandatory or optional to include the code points in a
121 message, RFC 8029 use the words to indicate that an acction might or
122 might nt be nesesary. The words "mandatory and "optional" are
123 dropped and the text is changed to focus on what should be doen.
125 1.1. Requirement Language
127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
129 "OPTIONAL" in this document are to be interpreted as described in BCP
130 14 [RFC2119] [RFC8174] when, and only when, they appear in all
131 capitals, as shown here.
133 2. Updating the Message Types, Reply Mode and Return Codes Registries
135 The following changes are made to the Message Types, Reply Modes and
136 Return Codes [IANA-MT] registries.
138 o In the listing of assignments the term "Vendor Private Use" is
139 changed to "Private Use"
141 o a small set of code points (4 code points) for Experimental Use is
142 added by reducing the range for "Private Use".
144 o the registration procedure "Specification Required" is changed to
145 "RFC Required" and the note "Experimental RFC needed" is removed
147 o the registration procedures "Private Use" and "Experimental Use"
148 are added to the table of registration procedures
150 o A note "Not to be assigned" is added for the registration
151 procedures "Private Use" and "Experimental Use"
153 o In the list that capture the assignment status, the fields that
154 are reserved, i.e. 0, Private Use and Experimental Use are
155 clearly marked.
157 * In the Return Codes [IANA-RC] registry the code point "0"
158 already been assigned. This assignment is not changed and this
159 registry will not have the "0" value "Reserved".
161 The new Registration Procedures layout and the new assignments for
162 these registries will be found in Section 6.1.
164 3. Updating the TLV and sub-TLV registries
166 3.1. General principles the LSP Ping TLV and sub-TLV registries
168 The following principles are valid for all the LSP Ping TLV and sub-
169 TLV IANA registries
171 o all TLVs and sub-TLVs with a typ in the the range 0-32767 require
172 a response if they are not recognized
174 o all TLVs and sub-TLVs in the range 32768-65535 may be silently
175 dropped if the are not recognized
177 The range of each TLV and sub-TLV registry is divided into wto
178 blocks, one with a range from 0 to 32767 for TLVs and sub-TLVs that
179 require a response if not recognized. Another block in the range
180 from 32768 to 65535, this block is for TLVs and sub-TLVs that may be
181 silently dropped if not recognized.
183 Each of the blocks has code point spaces with the following
184 registration procedures:
186 o Standards Action
188 o RFC Required
190 o Experimental Use
191 o Private Use
193 The exact defintion of registration procedures for IANA registries
194 are found in [RFC8126]
196 3.1.1. Unrecognized Experimental and Private TLVs and sub-TLVs
198 Unrecognized TLVs and sub-TLVs for Expereimetal USe and Privagte Use
199 are handled as any other unrecognised TLV or sub-TLV.
201 o If the unrecognized TLV or sub-TLV is from the Experimental Use
202 range (37144-37147) or from the Private Use range (31748-32767) a
203 the Return Code of 2 ("One or more of the TLVs was not
204 understood") will be sent in the echo response.
206 o If the unrecognized TLV or sub-TLV is from the Experimental Use
207 range (64512-64515) or from the Private Use range (64515-65535)
208 the TLVs SHOULD be silently ignored.
210 IETF does not prescribe how recognized or unrecognized Experimental
211 Use and Private Use TLVs and sub-TLVs are handled in experimental or
212 private networks, that is up to the agency running the experiment or
213 the private network. The statement above relates to how standard
214 compliant implementations will treat the unrecognized TLVs and sub-
215 TLVs from these ranges.
217 3.2. Changes to the LSP Ping Registries
219 This section lists the changes to each MPLS LSP Ping Registry.
220 Section 6.1, Section 6.2 and Section 6.3 set out how the new versions
221 of the IANA registries should look, together with the registration
222 procedures.
224 3.2.1. Common Changes to the TLV and sub-TLV Registries
226 The following changes are made to the TLV and sub-TLV registries.
228 o the registration procedures "Private Use" and "Experimental Use"
229 are added to the table of registration procedures
231 o two small sets of code points (2 times 4 code points) for
232 experimental use is added, actually they are take from the range
233 for "Private Use".
235 o the registration procedure "Specification Required" is changed to
236 "RFC Required" and the note "Experimental RFC needed" is removed
238 o In the listing of assignements the term "Vendor Private Use" is
239 changed to "Private Use"
241 o In the listing of assignments the range for "Experimental Use" is
242 added
244 o A note "Not to be assigned" is added for the registration
245 procedures "Experimental Use" and "Private Use"
247 o In the list that capture assignment status, the fields that are
248 reserved, i.e. 0, Experimental Use and Private Use are clearly
249 marked.
251 The new Registration Procedures description and the new assignments
252 for these registries will be found in Section 6.2 and Section 6.3.
254 4. Text Chages/Updates to Related RFCs
256 Some referenced RFCs are using the concept "mandatory TLVs" and
257 "mandatory sub-TLVs" to indicate that if a TLV or sub-TLV of the
258 range 0-16383 or 16384-31743 is present in a message but not
259 understood, error message need to be sent in response.
261 Since other RFCs are using "mandatory TLVs" and "mandatory sub-TLVs"
262 to indicate TLVs and sub-TLVs that must be present in a message, we
263 want to discontinue the use of "mandatory" to indicate TLVs and sub-
264 TLVs that requires an error message in response if not understood.
265 The changes to the RFCs below are intended to align with this
266 practice.
268 4.1. Text Changes to RFC 8029
270 Mandatory and optional is used in this way on page 14 and 15 in
271 Section 3 of RFC 8029.
273 The text in those two paragraphs are now changed to:
275 TLV and sub-TLV Types less than 32768 (i.e., with the high-order
276 bit equal to 0) are TLVs and sub-TLVs that MUST either be
277 supported by an implementation or result in the Return Code of 2
278 ("One or more of the TLVs was not understood") being sent in the
279 echo response.
281 An implementation that does not understand or support a received
282 TLV or sub-TLV with Type greater than or equal to 32768 (i.e.,
283 with the high-order bit equal to 1) SHOULD ignore and step over
284 the TLV or sub-TLV, however an implementation MAY send an echo
285 response with Return Code 2 ("One or more of the TLVs was not
286 understood") as it would have doen if the high order bit had been
287 clear.
289 In Section 3.8 of RFC 8029 "mandatory" is used in the same way. The
290 first two paragaraphs of this section ar now changed to read:
292 The following TLV is a TLV that MAY be included in an echo reply
293 to inform the sender of an echo request icluding TLVs or sub-TLVs
294 Types greater than or equal to 32768 (i.e., with the high-order
295 bit equal to 1) are iether nor supported by the implementation or
296 parsed and found to be in error.
298 The Value field contains the TLVs, including sub-TLVs, that were
299 not understood, encoded as sub-TLVs.
301 4.2. Text Changes to RFC 8611
303 The "Sub-TLVs for TLV Type 6" registry is now updated to align with
304 changes defined in this document.
306 The registration procedures for the "Sub-TLVs for TLV Type 6"
307 registry will now be like this:
309 +-------------+-------------------+---------------------------------+
310 | Range | Registration | Note |
311 | | Procedures | |
312 +-------------+-------------------+---------------------------------+
313 | 0-16383 | Standards Action | This range is for sub-TLVs that |
314 | | | require an error message if not |
315 | | | recognized. |
316 | 16384-31743 | RFC Required | This range is for sub-TLVs that |
317 | | | require an error message if not |
318 | | | recognized. |
319 | 31744-32767 | Private Use | Not to be assigned |
320 | 32768-49161 | Standards Action | This range is for sub-TLVs that |
321 | | | can be silently dropped if not |
322 | | | recognized. |
323 | 49162-64511 | RFC Required | This range is for sub-TLVs that |
324 | | | can be silently dropped if not |
325 | | | recognized. |
326 | 64512-65535 | Private Use | Not to be assigned |
327 +-------------+-------------------+---------------------------------+
329 Sub-TLVs for TLV Type 6 Registration Procedures
331 5. Security Considerations
333 This document updates IANA registries, some terminology used to
334 define, and clarifies the terminology related to the code points in
335 the registries. The document does not change how the code-points in
336 the registries are used. This should not create any new threats.
338 However, the updated terminology and the clarifications improve
339 security because it makes it more likely that implementations will be
340 consistent and harder to attack.
342 6. IANA Considerations
344 IANA is requested to update the LSP Ping name space as described in
345 this document.
347 6.1. Updates of Message Type, Reply Mode and Return Codes Registries
349 This section details the updated registration procedures and
350 allocations for: Message Type, Reply Mode and Return Codes
351 registries.
353 +---------+--------------------+------------------------------------+
354 | Range | Registration | Note |
355 | | Procedures | |
356 +---------+--------------------+------------------------------------+
357 | 0-191 | Standards Action | |
358 | 192-247 | RFC Required | |
359 | 248-251 | Experimental Use | Not to be assigned |
360 | 252-255 | Private Use | Not to be assigned |
361 +---------+--------------------+------------------------------------+
363 New common registration procedures
365 +---------+---------------------------------+-----------------------+
366 | Value | Meaning | Reference |
367 +---------+---------------------------------+-----------------------+
368 | 0 | Reserved | This document |
369 | 1-247 | No changes to the existing | |
370 | | assignments | |
371 | 248-251 | Reserved for Experimental Use | This document |
372 | 252-255 | Reserved for Private Use | [RFC8029] |
373 +---------+---------------------------------+-----------------------+
375 Common Assignments for the Message Types, Reply Mode and Return Code
376 registries
378 Note that for the Return Code registry the assignment for code point
379 zero has been previously assigned, it is not changed but will remain:
381 +-------+----------------------------------+------------------------+
382 | Value | Meaning | Reference |
383 +-------+----------------------------------+------------------------+
384 | 0 | No return code | [RFC8029] |
385 +-------+----------------------------------+------------------------+
387 Assignment for code point 0 in the Return Code registry
389 6.2. Common Registration Procedures for TLVs and sub-TLVs
391 This section describes the new registration procedures for the TLV
392 and sub-TLV registries. The registry for sub-TLV 9 ([IANA-Sub-9] is
393 not changed.
395 +-------------+-------------------+---------------------------------+
396 | Range | Registration | Note |
397 | | Procedures | |
398 +-------------+-------------------+---------------------------------+
399 | 0-16383 | Standards Action | This range is for TLVs that |
400 | | | require an error message if not |
401 | | | recognized. |
402 | 16384-31743 | RFC Required | This range is for TLVs that |
403 | | | require an error message if not |
404 | | | recognized. |
405 | 37144-37147 | Experimental Use | Not to be assigned |
406 | 31748-32767 | Private Use | Not to be assigned |
407 | 32768-49161 | Standards Action | This range is for TLVs that can |
408 | | | be silently dropped if not |
409 | | | recognized. |
410 | 49162-64511 | RFC Required | This range is for TLVs that can |
411 | | | be silently dropped if not |
412 | | | recognized. |
413 | 64512-64515 | Experimental Use | Not to be assigned |
414 | 64515-65535 | Private Use | Not to be assigned |
415 +-------------+-------------------+---------------------------------+
417 TLV and sub-TLV Registration Procedures
419 6.3. IANA Assignments for TLVs and sub-TLVs
421 The two tables in this section describes the updated IANA assignments
422 for the TLV and sub-TLV registries. The registry for sub-TLV 9
423 ([IANA-Sub-9] is not changed.
425 +-------------+-------------------+------------------+--------------+
426 | Type | TLV name | Reference | sub-TLV |
427 | | | | registry |
428 +-------------+-------------------+------------------+--------------+
429 | 0 | Reserved | This document | |
430 | 1-31743 | [any] | No changes to | [any] |
431 | | | the current | |
432 | | | registry | |
433 | 37144-37147 | Reserved for | This document | NA |
434 | | Experimental Use | | |
435 | 31748-32767 | Reserved for | This document | NA |
436 | | Private Use | | |
437 | 32768-64511 | [any] | No changes to | [any] |
438 | | | the current | |
439 | | | registry. | |
440 | 64512-64515 | Reserved for | This document | NA |
441 | | Experimental Use | | |
442 | 64515-65535 | Reserved for | This document | NA |
443 | | Private Use | | |
444 +-------------+-------------------+------------------+--------------+
446 TLV Assignments
448 Updated Sub-TLV assignments
450 +-------------+-------------------------------+---------------------+
451 | Type | TLV name | Reference |
452 +-------------+-------------------------------+---------------------+
453 | 0 | Reserved | This document |
454 | 1-31743 | [any] | No changes to the |
455 | | | current registry |
456 | 37144-37147 | Reserved for Experimental Use | This document |
457 | 31748-32767 | Reserved for Private Use | This document |
458 | 32768-64511 | [any] | No changes to the |
459 | | | current registry. |
460 | 64512-64515 | Reserved for Experimental Use | This document |
461 | 64515-65535 | Reserved for Private Use | This document |
462 +-------------+-------------------------------+---------------------+
464 Sub-TLV Assignments
466 7. Acknowledgements
468 The authors wish to thank Adrian Farrel, who both made very useful
469 comments and agreed to serve as the document shepherd.
471 The authors also wish to thank Micelle Cotton who very patiently
472 worked with us to determine how our registries could and should be
473 updated.
475 8. References
477 8.1. Normative References
479 [IANA-LSP-PING]
480 "Multiprotocol Label Switching (MPLS) Label Switched Paths
481 (LSPs) Ping Parameters",
482 .
485 [IANA-MT] "Message Types", .
489 [IANA-RC] "Return Codes", .
492 [IANA-RM] "Reply Modes", .
495 [IANA-Sub-1-16-21]
496 "Sub-TLVs for TLV Types 1, 16, and 21",
497 .
501 [IANA-Sub-11]
502 "Sub-TLVs for TLV Type 11",
503 .
507 [IANA-Sub-20]
508 "Sub-TLVs for TLV Type 20",
509 .
513 [IANA-Sub-23]
514 "Sub-TLVs for TLV Type 23",
515 .
519 [IANA-Sub-27]
520 "Sub-TLVs for TLV Type 27",
521 .
525 [IANA-Sub-6]
526 "Sub-TLVs for TLV Type 6",
527 .
531 [IANA-TLV-reg]
532 "TLVs", .
535 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
536 Requirement Levels", BCP 14, RFC 2119,
537 DOI 10.17487/RFC2119, March 1997,
538 .
540 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
541 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
542 Switched (MPLS) Data-Plane Failures", RFC 8029,
543 DOI 10.17487/RFC8029, March 2017,
544 .
546 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
547 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
548 May 2017, .
550 [RFC8611] Akiya, N., Swallow, G., Litkowski, S., Decraene, B.,
551 Drake, J., and M. Chen, "Label Switched Path (LSP) Ping
552 and Traceroute Multipath Support for Link Aggregation
553 Group (LAG) Interfaces", RFC 8611, DOI 10.17487/RFC8611,
554 June 2019, .
556 8.2. Informative References
558 [IANA-Sub-9]
559 "Sub-TLVs for TLV Type 9",
560 .
564 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
565 Writing an IANA Considerations Section in RFCs", BCP 26,
566 RFC 8126, DOI 10.17487/RFC8126, June 2017,
567 .
569 Authors' Addresses
571 Loa Andersson
572 Bronze Dragon Consulting
574 Email: loa@pi.nu
576 Mach Chen
577 Huawei Techologies
579 Email: mach.chen@huawei.com
581 Carlos Pignataro
582 Cisco Systems
584 Email: cpignata@cisco.com
586 Tarek Saad
587 Juniper Networks
589 Email: tsaad@juniper.net