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