MPLS Working Group L. Andersson Internet-Draft Bronze Dragon Consulting Updates: 8029, 8611 (if approved) M. Chen Intended status: Standards Track Huawei Techologies Expires:February 18,March 28, 2021 C. Pignataro Cisco Systems T. Saad Juniper NetworksAugust 17,September 24, 2020 Updating the IANA MPLS LSP Ping Parametersdraft-ietf-mpls-lsp-ping-registries-update-03draft-ietf-mpls-lsp-ping-registries-update-04 Abstract This document updates RFC 8029 and RFC 8611 that both define IANA registries for MPLS LSP Ping. It also updates the description of the procedures for the responses sent when an unknown or erroneous code point is found. The updates are to clarify and align this name space with recent developments. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire onFebruary 18,March 28, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .23 1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology Used in this Document . . . . . . . . . . . . 4 2. Updating the Message Types, Reply Mode and Return Codes Registries . . . . . . . . . . . . . . . . . . . . . . . . .34 3. Updating the TLV andsub-TLV registriesSub-TLV Registries . . . . . . . . . . .45 3.1. GeneralprinciplesPrinciples for the LSP Ping TLV andsub-TLVSub-TLV registries . . . . . . . . . . . . . . . . . . . . . . .45 3.1.1. Unrecognized Experimental Use TLVs andsub-TLVsSub-TLVs . . .56 3.2. Common Registration Procedures for TLVs and sub-TLVs . . 6 3.3. Changes to the LSP Ping Registries . . . . . . . . . . .5 3.2.1.7 3.3.1. Common Changes to the TLV andsub-TLVSub-TLV Registries . .57 4. Updates to Related RFCs . . . . . . . . . . . . . . . . . . .68 4.1. Updates to RFC 8029 . . . . . . . . . . . . . . . . . . .68 4.2. Updates to RFC 8611 . . . . . . . . . . . . . . . . . . .79 5. Security Considerations . . . . . . . . . . . . . . . . . . .810 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . .810 6.1. Updatesofto the Message Type, Reply Mode and Return Codes Registries . . . . . . . . . . . . . . . . . . . . . . .911 6.1.1. Updates to the Mesage Type registry . . . . . . . . . 11 6.1.2. Updates to the Reply Modes registry . . . . . . . . . 12 6.1.3. Updates to the Return Codes registry . . . . . . . . 13 6.2.Common Registration Procedures for TLVsUpdates to the TLV andsub-TLVssub-TLV registries . .9 6.3. IANA Assignments. . . . . . 16 6.2.1. Updates to the TLVs registry . . . . . . . . . . . . 16 6.2.2. Updates to the registry for SubTLVs for TLVs 1, 16 andsub-TLVs21 . . . . . . . . .10. . . . . . . . . . . . . . 18 6.2.3. Updates to the registry for SubTLVs for TLV 6 . . . . 20 6.2.4. Updates to the registry for SubTLVs for TLV 11 . . . 22 6.2.5. Updates to the registry for SubTLVs for TLV 20 . . . 24 6.2.6. Updates to the registry for SubTLVs for TLV 23 . . . 26 6.2.7. Updates to the registry for SubTLVs for TLV 27 . . . 28 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .1130 8. References . . . . . . . . . . . . . . . . . . . . . . . . .1230 8.1. Normative References . . . . . . . . . . . . . . . . . .1230 8.2. Informative References . . . . . . . . . . . . . . . . .1332 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . .1433 1. Introduction When RFC 8029 [RFC8029] was published it contained updates to the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" IANA name space [IANA-LSP-PING]. RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC 8029. This document further clarifies the entries in those registries and makes the definitions more precise. This document updates RFC 8029 [[RFC8029] and RFC 8611 [RFC8611] by updating two groups of registries as follows: First the registries for Message Types [IANA-MT], Reply Modes [IANA-RM] and Return Codes [IANA-RC] are updated. The changes to these registries are minor. Second, this document updates the TLV and sub-TLV registries. o TLVs[IANA-TLV-reg][IANA-TLV-reg]. o Sub-TLVs for TLVs 1, 16 and 21[IANA-Sub-1-16-21][IANA-Sub-1-16-21]. o Sub-TLVs for TLV Type 6[IANA-Sub-6][IANA-Sub-6]. o Sub-TLVs for TLV 11[IANA-Sub-11][IANA-Sub-11]. o Sub-TLVs for TLV 20[IANA-Sub-20][IANA-Sub-20]. o Sub-TLVs for TLV 23[IANA-Sub-23][IANA-Sub-23]. o Sub-TLVs for TLV 27[IANA-Sub-27][IANA-Sub-27]. The registry for sub-TLVs for TLV 9 [IANA-Sub-9] is not updated. Third, some code points (TLVs and sub-TLVs) are "mandatory" or "optional". Contrary to how other RFCs use these words, indicating that it is mandatory or optional to include the code points in a message, RFC 8029use theuses these words to indicate that an action might or might not be necessary. This documentdrops the words "mandatoryupdates RFC 8029 to drop the words "mandatory" and"optional""optional", and the text is changed to focus on what should be done. 1.1. Requirement Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Terminology Used in this Document This docuemtment uses some terms that relates to IANA registries in this way: IANA Name Space, a name space is a top level registry. An exasmple could be "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" [IANA-LSP-PING]. A name space is most often a contaimer for regiistries that hold code points that share some affinity. IANA Registry, an IANA registry holds code points, and lists the registration procedures and allocation of code points these code points. One example would be the "TLVs" registry [IANA-TLV-reg]. IANA Sub-registry, a sub-registry is used when a code point allocated in a registry need code points scoped by that or a set of code points. An example of a sunregistry thast holds code points for more than one TLV is "Sub-TLVs for TLV Types 1, 16, and 21" [IANA-Sub-1-16-21] 2. Updating the Message Types, Reply Mode and Return Codes Registries The following changes are made to the Message Types, Reply Modes and Return Codes [IANA-MT] registries. oinIn the listing of assiged code points the term "Vendor Private Use" is changed to "Private Use". otheThe registration procedure "Specification Required" is changed to "RFC Required" and the note "Experimental RFC needed" isremovedremoved. oaA small set of code points (4 code points) for Experimental Use is added by reducing the range for "RFC Required" range. otheThe registration procedures "Private Use" and "Experimental Use" are added to the table of registrationproceduresprocedures. o A note "Not to be assigned" is added for the registration procedures "Private Use" and "ExperimentalUse"Use". o In the lists that capture the assignment status, the fields that are reserved, i.e. 0 (zero), Private Use and Experimental Use are clearly marked as such. *InNote that in the Return Codes[IANA-RC]registry [IANA-RC] registry the code point "0" has already been assigned. This assignment is not changed and in this registry the code point "0" continues to be assigned as "No Return Code". The new Registration Procedures, the registry layouts and the new assignments for these registrieswill beare found in Section 6.1. 3. Updating the TLV andsub-TLV registriesSub-TLV Registries 3.1. GeneralprinciplesPrinciples for the LSP Ping TLV andsub-TLVSub-TLV registries The following principlesare valid for allapply to the processing of any TLV from any of the LSP Ping TLV andsub- TLVsub-TLV IANAregistriesregistries. oallAll TLVs and sub-TLVs with a type in the range 0-32767 require a response if they are notrecognizedrecognized. oallAll TLVs and sub-TLVs in the range 32768-65535 may be silentlydroppeddropped, stepped over or an error message sennt if they are notrecognizedrecognized. The range of each TLV and sub-TLV registry is divided into two blocks, one with a range from 0 to 32767 for TLVs and sub-TLVs that require a response if not recognized. The other blockinhas the range from 32768 to 65535 for TLVs and sub-TLVs that may be silently dropped,possiblysteppedover,over or an error message sent, if not recognized. Each of the blocks has code point spaces with the following registration procedures: o StandardsActionAction. o RFCRequiredRequired. o ExperimentalUseUse. o First come, first served(FCFS)(FCFS). The exact defintions of these procedures are found in[RFC8126][RFC8126]. 3.1.1. Unrecognized Experimental Use TLVs andsub-TLVsSub-TLVs Unrecognized TLVs and sub-TLVs in the Experimetal Use, and FCFS ranges are handled as any other unrecognized TLV or sub-TLV. o If the unrecognized TLV or sub-TLV is from the Experimental Use range (37140-37143) or from the FCFS range (31744-32767) a the Return Code of 2 ("One or more of the TLVs was not understood") will be sent in the echo response. o If the unrecognized TLV or sub-TLV is from the Experimental Use range(64508-64511)(64508-64511). or from thePrivate UseFCFS range (64512-65535) the TLVsSHOULDmay be silentlyignored and possibly beignored, steppedover.over or an error message sent. The IETF does not prescribe how recognized or unrecognized Experimental Use and Private Use TLVs and sub-TLVs are handled in experimental or private networks, that is up to the agency running the experiment or the private network. The statement above describes how standards compliant implementations will treat the unrecognized TLVs and sub- TLVs from these ranges. 3.2.Changes to the LSP Ping RegistriesCommon Registration Procedures for TLVs and sub-TLVs This sectionlists the changes to each MPLS LSP Ping TLV and sub-TLV Registry. Section 6.1, Section 6.2 and Section 6.3 outline howdescribes the newversions of the IANA registries should look, together with theregistration procedures foreach registry. 3.2.1. Common Changes to the TLV and sub-TLV Registries The following changes are made tothe TLV and sub-TLV registries.o the registration procedures+-------------+-------------------+---------------------------------+ | Range | Registration | Note | | | Procedures | | +-------------+-------------------+---------------------------------+ | 0-16383 | Standards Action | This range is for TLVs and sub- | | | | TLVs that require an error | | | | message if not recognized. | | 16384-31739 | RFC Required | This range is for TLVs an sub- | | | | TLVs that require an error | | | | message if not recognized. | | 37140-37143 | Experimental Use | Reserved, not to be assigned | | 31744-32767 | FCFS | This range is for TLVs anf sub- | | | | TLVs that require an error | | | | message if not recognized. | | 32768-49161 | Standards Action | This range is for TLVs and sub- | | | | TLVs that can be silently | | | | dropped if not recognized. | | 49162-64507 | RFC Required | This range is for TLVs and sub- | | | | TLVs that can be silently | | | | dropped if not recognized. | | 64508-64511 | Experimental Use | Reserved, not to be assigned | | 64512-65535 | FCFS | This range is for TLVs and sub- | | | | TLVs that can be silently | | | | dropped if not recognized. | +-------------+-------------------+---------------------------------+ TLV and sub-TLV Registration Procedures 3.3. Changes to the LSP Ping Registries This section lists the changes to each MPLS LSP Ping TLV and sub-TLV Registry, see section 6.2.1 to 6.2.7 describe how the new versions of the IANA registries should look, together with the registration procedures for each registry. The new Registration Procedures description and the new assignments for these registries are used to model the changed MPLS LSP Ping registries, see Section 6 . 3.3.1. Common Changes to the TLV and Sub-TLV Registries The following changes are made to the TLV and sub-TLV registries. o The registration procedures "First Come Frst Served (FCFS)" and "Experimental Use" are added to the table of registration procedures. o Two small sets of code points (4 code points each) for Experiemental Use, are created. The first set are for the range that requires a response if the TLV or sub-TLV is not recognised; the second set are for the range there the TLV or sub-TLV that may be silently dropped if not recognized. The code points for experimental use are actually taken from the two ranges now called "RFC Required". o The registration procedure "Specification Required" is changed to "RFC Required" and the note "Experimental RFC needed" is removed. o In the listing of assignments the term "Vendor Private Use" is changed to "First Come First Served (FCFS)". o In the listing of assignments the range for "Experimental Use" is added. o A note saying "Not to be assigned" is added for the registration procedures "Experimental Use". o In the list that captures assignment status, the fields that are reserved, i.e. 0 (zero) and Experimental Use are clearly marked. 4. Updates to Related RFCs Some referenced RFCs use the concept "mandatory TLVs" and "mandatory sub-TLVs" to indicate that, if a TLV or sub-TLV of the range 0-16383 or 16384-31743 in a message is not understood, an error message needs to be sent in response. The same RFCs use "optional TLVs" and "optional sub-TLVs" to mean TLVs or sub-TLVs that can be silently ignored if not recognized. Since other RFCs use "mandatory TLVs" and "mandatory sub-TLVs" to indicate TLVs and sub-TLVs that must be present in a message, we want to discontinue the use of "mandatory" to indicate TLVs and sub-TLVs that requires an error message in response if not understood. The changes to the RFCs below align with this practice. 4.1. Updates to RFC 8029 Mandatory and optional are used to indicate whether a response is needed if a TLV or sub-TLV is not understood on pages 14 and 15 in Section 3 of RFC 8029. The text in those two paragraphs are now updated to the following: TLV and sub-TLV Types less than 32768 (i.e., with the high-order bit equal to 0) are TLVs and sub-TLVs that MUST either be supported by an implementation or result in the Return Code of 2 ("One or more of the TLVs was not understood") being sent in the echo response. An implementation that does not understand or support a received TLV or sub-TLV with Type greater than or equal to 32768 (i.e., with the high-order bit equal to 1) SHOULD ignore and step over the TLV or sub-TLV, however an implementation MAY send an echo response with Return Code 2 ("One or more of the TLVs was not understood") as it would have done if the high order bit had been clear. In Section 3.8 of RFC 8029 "mandatory" is used in the same way. The first two paragraphs of this section are now updated to read as follows: The following TLV is a TLV that MAY be included in an echo reply to inform the sender of an echo request that includes TLVs or sub- TLVs Types less than 32768 (i.e., with the high-order bit equal to 0) are either not supported by the implementation or parsed and found to be in error. The Value field contains the TLVs, including sub-TLVs, that were not understood, encoded as sub-TLVs. 4.2. Updates to RFC 8611 Section 13.4.1 of "Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces [RFC8611]" defines "Sub-TLVs for TLV Type 6" [IANA-Sub-6]. The "Sub-TLVs for TLV Type 6" registry is now updated to align with changes defined in this document. Section 13.4.1 of RFC 8611 is now updated as follows: Section 13.4.1 Sub-TLVs for TLV Type 6 IANA has created a new sub-registry "Sub-TLVs for TLV Type 6" [IANA-Sub-6] under the "TLVs" registry [IANA-TLV-reg] of the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" name space [lsp-ping-NameSpace]. The "Sub-TLVs for TLV Type 6" sub-registry is now updated to align with changes defined in this document. +-------------+-------------------+---------------------------------+ | Range | Registration | Note | | | Procedures | | +-------------+-------------------+---------------------------------+ | 0-16383 | Standards Action | This range is for sub-TLVs that | | | | require an error message if not | | | | recognized. | | 16384-31739 | RFC Required | This range is for sub-TLVs that | | | | require an error message if not | | | | recognized. | | 31740-31743 | Experimental Use | Reserved not to be assigned | | 31744-32767 | FCFS | This range is for sub-TLVs that | | | | require an error message if not | | | | recognized. | | 32768-49161 | Standards Action | This range is for sub-TLVs that | | | | can be silently dropped if not | | | | recognized. | | 49162-64507 | RFC Required | This range is for sub-TLVs that | | | | can be silently dropped if not | | | | recognized. | | 64508-64511 | Experimental Use | Reserved not to be assigned | | 64512-65535 | FCFS | This range is for sub-TLVs that | | | | can be silently dropped if not | | | | recognized. | +-------------+-------------------+---------------------------------+ Table 1: Sub-TLVs for TLV Type 6 Registration Procedures 5. Security Considerations This document updates IANA registries. It also updates terminology used to define, and clarifies the terminology related to, the code points in the registries. The document does not change how the code- points in the registries are used. This should not create any new threats. However, the updated terminology and the clarifications improve security because it makes it more likely that implementations will be consistent and harder to attack. 6. IANA Considerations IANA is requested to update the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" name space [IANA-LSP-PING] as described in this document. See Section 1.2 "Terminology Used in this Document" to see how "name space", "registry" and "sub-registry" are used in this document. In other parts of this document the communality of the changes to the LSP Ping registries has been the focus. For the IANA considerations each changed registry has been described in its own right. The following registries and sub-registries are changed: "Message Types", [IANA-MT], "Reply Modes", [IANA-RM] "Return Codes" [IANA-RC] "TLVs" [IANA-TLV-reg] "Sub-TLVs for TLV Types 1, 16, and 21" [IANA-Sub-1-16-21] "Sub-TLVs for TLV Type 6" [IANA-Sub-6] "Sub-TLVs for TLV Type 11" [IANA-Sub-11] "Sub-TLVs for TLV Type 20" [IANA-Sub-20] "Sub-TLVs for TLV Type 23" [IANA-Sub-23] "Sub-TLVs for TLV Type 27" [IANA-Sub-27] 6.1. Updates to the Message Type, Reply Mode and Return Codes Registries This section details the updated registration procedures and allocations for "Message Type", "Reply Mode" and "Return Codes" registries. 6.1.1. Updates to the Mesage Type registry This is the changes to the "Message Type" registry specified in this document: o Code Point 0 (zero) is marked Resereved. o The registration procedure "Specification Required" is changed to "RFC Required" and the comment "Experimental RFC needed" is removed. o Four code point has been taken from what was earlier "Specification Required" to form a set of code points for "Experimental Use." The registration procedures after the changes for the "Message Type" registry are shown in the table below: +---------+--------------------+------------------------------------+ | Range | Registration | Note | | | Procedures | | +---------+--------------------+------------------------------------+ | 0-191 | Standards Action | | | 192-247 | RFC Required | | | 248-251 | Experimental Use | Reserved, not to be assigned | | 252-255 | Private Use | Reserved, not to be assigned | +---------+--------------------+------------------------------------+ Table 2: Message Type registration procedures The updated assignments for the "Message Types" registry will look like this: +---------+---------------------------------+-----------------------+ | Value | Meaning | Reference | +---------+---------------------------------+-----------------------+ | 0 | Reserved | This document | | 1 | MPLS Echo Request | [RFC8029] | | 2 | MPLS Echo Reply | [RFC8029] | | 3 | MPLS Proxy Ping Request | [RFC7555] | | 4 | MPLS Proxy Ping Reply | [RFC7555] | | 5 | MPLS Relayed Echo Reply | [RFC7743] | | 6-247 | Unassigned | | | 248-251 | Reserved for Experimental Use | This document | | 252-255 | Reserved for Private Use | [RFC8029] | +---------+---------------------------------+-----------------------+ Table 3: Assignments for the Message Types registry 6.1.2. Updates to the Reply Modes registry This is the changes to the "Reply Modes" registry specified in this document: o Code Point 0 (zero) is marked Resereved. o The registration procedure "Specification Required" is changed to "RFC Required" and the comment "Experimental RFC needed" is removed. o Four code point has been taken from what was earlier "Specification Required" to form a set of code points for "Experimental Use". The registration procedures after the changes for the "Reply Modes" registry are show in the table below: +---------+--------------------+------------------------------------+ | Range | Registration | Note | | | Procedures | | +---------+--------------------+------------------------------------+ | 0-191 | Standards Action | | | 192-247 | RFC Required | | | 248-251 | Experimental Use | Reserved, not to be assigned | | 252-255 | Private Use | Reserved, not to be assigned | +---------+--------------------+------------------------------------+ Table 4: Reply Modes registration procedures The updated assignments for the "Reply Modes" registry will look like this: +---------+---------------------------------+-----------------------+ | Value | Meaning | Reference | +---------+---------------------------------+-----------------------+ | 0 | Reserved | This document | | 1 | Do not reply | [RFC8029] | | 2 | Reply via an IPv4/IPv6 UDP | [RFC8029] | | | packet | | | 3 | Reply via an IPv4/IPv6 UDP | [RFC8029] | | | packet with Router Alert | | | 4 | Reply via application-level | [RFC8029] | | | control channel | | | 5 | Reply via Specified Path | [RFC7110] | | 6-247 | Unassigned | | | 248-251 | Reserved for Experimental Use | This document | | 252-255 | Reserved for Private Use | [RFC8029] | +---------+---------------------------------+-----------------------+ Table 5: Assignments for the Reply Modes registry 6.1.3. Updates to the Return Codes registry This is the changes to the "Return Codes" registry specified in this document: o The registration procedure "Specification Required" is changed to "RFC Required" and the comment "Experimental RFC needed" is removed. o Four code point has been taken from what was earlier "Specification Required" to form a set of code points for "Experimental Use". The registration procedures after the changes for the "Return Codes" registry are show in the table below: +---------+--------------------+------------------------------------+ | Range | Registration | Note | | | Procedures | | +---------+--------------------+------------------------------------+ | 0-191 | Standards Action | | | 192-247 | RFC Required | | | 248-251 | Experimental Use | Reserved, not to be assigned | | 252-255 | Private Use | Reserved, not to be assigned | +---------+--------------------+------------------------------------+ Table 6: Return Codes registration procedures The updated assignments for the "Return Codes" registry will look like this: +---------+----------------------------------+----------------------+ | Value | Meaning | Reference | +---------+----------------------------------+----------------------+ | 0 | No Return Code | This document | | 1 | Malformed echo request received | [RFC8029] | | 2 | One or more of the TLVs was not | [RFC8029] | | | understood | | | 3 | Replying router is an egress for | [RFC8029] | | | the FEC at stack-depth (RSC) | | | 4 | Replying router has no mapping | [RFC8029] | | | for the FEC at stack-depth (RSC) | | | 5 | Downstream Mapping Mismatch (See | [RFC8029] | | | [1]) | | | 6 | Upstream Interface Index Unknown | [RFC8029] | | | (See [1]) | | | 7 | Reserved | [RFC8029] | | 8 | Label switched at stack-depth | [RFC8029] | | | (RSC) | | | 9 | Label switched but no MPLS | [RFC8029] | | | forwarding at stack-depth (RSC) | | | 10 | Mapping for this FEC is not the | [RFC8029] | | | given label at stack-depth (RSC) | | | 11 | No label entry at stack-depth | [RFC8029] | | | (RSC) | | | 12 | Protocol not associated with | [RFC8029] | | | interface at FEC stack-depth | | | | (RSC) | | | 13 | Premature termination of ping | [RFC8029] | | | due to label stack shrinking to | | | | a single label | | | 14 | See DDMAP TLV for meaning of | [RFC8029] | | | Return Code and Return Subcode | | | | (See [2]) | | | 15 | Label switched with FEC change | [RFC8029] | | 16 | Proxy Ping not authorized | [RFC7555] | | 17 | Proxy Ping parameters need to be | [RFC7555] | | | modified | | | 18 | MPLS Echo Request could not be | [RFC7555] | | | sent | | | 19 | Replying router has FEC mapping | [RFC7555] | | | for topmost FEC | | | 20 | One or more TLVs not returned | [RFC7743] | | | due to MTU size | | | 21 | OAM Problem/Unsupported BFD | [RFC7759] | | | Version | | | 22 | OAM Problem/Unsupported BFD | [RFC7759] | | | Encapsulation format | | | 23 | OAM Problem/Unsupported BFD | [RFC7759] | | | Authentication Type | | | 24 | OAM Problem/Mismatch of BFD | [RFC7759] | | | Authentication Key ID | | | 25 | OAM Problem/Unsupported | [RFC7759] | | | Timestamp Format | | | 26 | OAM Problem/Unsupported Delay | [RFC7759] | | | Mode | | | 27 | OAM Problem/Unsupported Loss | [RFC7759] | | | Mode | | | 28 | AM Problem/Delay variation | [RFC7759] | | | unsupported | | | 29 | OAM Problem/Dyadic mode | [RFC7759] | | | unsupported | | | 30 | OAM Problem/Loopback mode | [RFC7759] | | | unsupported | | | 31 | OAM Problem/Combined mode | [RFC7759] | | | unsupported | | | 32 | OAM Problem/Fault management | [RFC7759] | | | signaling unsupported | | | 33 | OAM Problem/Unable to create | [RFC7759] | | | fault management association | | | 34 | OAM Problem/PM Configuration | [RFC7759] | | | Error | | | 35 | Mapping for this FEC is not | [RFC8287] sec 7.4 | | | associated with the incoming | | | | interface | | | 36-247 | Unassigned | [RFC7759] | | 248-251 | Reserved for Experimental Use | This document | | 252-255 | Reserved for Private Use | [RFC8029] | +---------+----------------------------------+----------------------+ Table 7: Assignments for the Return Codes registry 6.2. Updates to the TLV and sub-TLV registries The updates to the TLV and the sub-TLV registries are mostly the same, however the Sub-TLVs for TLV Type 9 [IANA-Sub-9] has not been updated. Note that when a field in an assigment table sayds "EQ", it means that the field should not be changed as compared to the corresponding field in the "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters" name space [IANA-LSP-PING] 6.2.1. Updates to the TLVs registry This section describes the new registration procedures and the assignments for the "TLVs" registry [IANA-TLV-reg] based on the new registration procedures. The registration procedures has been changed the following way for the "TLVs" registry. o The "Specification Required" registration procedure has been changed to "RFC Required", the comment "Experimental RFC Required" has been removed. o The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come, First Served" code points. o Two small sets, 4 code points each, has been created for Experimental Use. o Code points that are reserved are clearly marked as such. o The assignments have been updated to match the new registration procedures. o The notes related to the registration procedures have been changed to reflect when a response is required or not if a TLV is not recognized. The registration procedures for the "TLVs" registry [IANA-TLV-reg] will now look like this: +-------------+-------------------+---------------------------------+ | Range | Registration | Note | | | Procedures | | +-------------+-------------------+---------------------------------+ | 0-16383 | Standards Action | This range is for TLVs that | | | | require an error message if not | | | | recognized. | | 16384-31739 | RFC Required | This range is for TLVs that | | | | require an error message if not | | | | recognized. | | 31740-31743 | Experimental Use | Reserved, not to be assigned | | 31744-32767 | FCFS | This range is for TLVs that | | | | require an error message if not | | | | recognized. | | 32768-49161 | Standards Action | This range is for TLVs that can | | | | be silently dropped if not | | | | recognized. | | 49162-64507 | RFC Required | This range is for TLVs that can | | | | be silently dropped if not | | | | recognized. | | 64508-64511 | Experimental Use | Reserved, not to be assigned | | 64512-65535 | FCFS | This range is for TLVs that can | | | | be silently dropped if not | | | | recognized. | +-------------+-------------------+---------------------------------+ Table 8: TLV Registration Procedures The TLV Assignments will now look like this. Note that when a field in this table does say "EQ", it means that if should be the same as the registry being updtated. +-------------+---------------+-----------------+-------------------+ | Type | TLV Name | Reference | Sub-TLV Registry | +-------------+---------------+-----------------+-------------------+ | 0 | Reserved | This document | | | 1-7 | EQ | EQ | EQ | | 8 | Unassigned | | | | 9-16 | EQ | EQ | EQ | | 17-19 | unassigned | | | | 20-27 | EQ | EQ | EQ | | 28-31739 | Unassigned | | | | 31740-31743 | Experimental | This Document | Reserved, not to | | | Use | | be assigned | | 31744-32767 | Unassigned | | | | 32768-32770 | EQ | EQ | EQ | | 32771-64507 | EQ | EQ | EQ | | 64508-64511 | Experimental | This document | Resereved, not to | | | Use | | be assigned | | 64512-65535 | Unassigned | | | +-------------+---------------+-----------------+-------------------+ Table 9: TLV Assignments 6.2.2. Updates to the registry for SubTLVs for TLVs 1, 16 and 21 This section describes the new registration procedures and the assignments for the "Sub-TLVs for TLV Types 1, 16, and 21" [IANA-Sub-1-16-21] sub-registry based on the new registration procedures. o The "Specification Required" registration procedure has been changed to "RFC Required", the comment "Experimental RFC Required" has been removed. o The code points registration procedure "Vendor Private Use" has been removed and replaced with "FirstCome Frst Served (FCFS)"Come, First Served" code points. o Two small sets, 4 code points each, has been created for Experimental Use. o Code points that are reserved are clearly marked as such. o The assignments have been updated to match the new registration procedures. o The notes related to the registration procedures have been changed to reflect when a response is required if a sub-TLV is not recognized or not. The registration procedures for the "Sub-TLVs for TLV Types 1, 16, and 21" [IANA-Sub-1-16-21] sub- registry will now look like this: +-------------+-------------------+---------------------------------+ | Range | Registration | Note | | | Procedures | | +-------------+-------------------+---------------------------------+ | 0-16383 | Standards Action | This range is for TLVs that | | | | require an error message if not | | | | recognized. | | 16384-31739 | RFC Required | This range is for TLVs that | | | | require an error message if not | | | | recognized. | | 37140-37144 | Experimental Use | Reserved, not to be assigned | | 31748-32767 | FCFS | This range is for TLVs that | | | | require an error message if not | | | | recognized. | | 32768-49161 | Standards Action | This range is for TLVs that can | | | | be silently dropped if not | | | | recognized. | | 49162-64507 | RFC Required | This range is for TLVs that can | | | | be silently dropped if not | | | | recognized. | | 64508-64511 | Experimental Use | Reserved, not to be assigned | | 64512-65535 | FCFS | This range is for TLVs that can | | | | be silently dropped if not | | | | recognized. | +-------------+-------------------+---------------------------------+ Table 10: Registration Procedures for Sub-TLVs for TLVs 1, 16 and"Experimental Use" are added21 +-------------+---------------+-----------------+-------------------+ | Type | TLV Name | Reference | Comment | +-------------+---------------+-----------------+-------------------+ | 0 | Reserved | This document | | | 1-4 | EQ | EQ | EQ | | 5 | Unassigned | | | | 6-8 | EQ | EQ | EQ | | 9 | EQ | EQ | DEPRECATED | | 9-20 | EQ | EQ | EQ | | 21 | unassigned | | | | 22-37 | EQ | EQ | EQ | | 38-31739 | Unassigned | | | | 31740-31743 | Experimental | This Document | Reserved, not to | | | Use | | be assigned | | 31744-64507 | Unassigned | | | | 64508-64511 | Experimental | This document | Resereved, not to | | | Use | | be assigned | | 64512-65535 | Unassigned | | | +-------------+---------------+-----------------+-------------------+ Table 11: Sub-TLV for TLV 1, 16 and 21 Assignments 6.2.3. Updates to thetable ofregistry for SubTLVs for TLV 6 This section describes the new registration procedures and the assignments for the "Sub-TLVs for TLV Type 6" [IANA-Sub-6] sub- registry based on the new registration procedures. o The "Specification Required" registration procedure has been changed to "RFC Required", the comment "Experimental RFC Required" has been removed. otwo small sets ofThe code points(4registration procedure "Vendor Private Use" has been removed and replaced with "First Come, First Served" code points. o Two small sets, 4 code pointseach)each, has been created forExperiemental UseExperimental Use. o Code points that arecreated. The first setreserved are clearly marked as such. o The assignments have been updated to match the new registration procedures. o The notes related to the registration procedures have been changed to reflect when a response is required if a sub-TLV is not recognized or not. The registration procedures for the "Sub-TLVs for TLV Type 6" [IANA-Sub-6] sub-registry will now look like this: +-------------+-------------------+---------------------------------+ | Range | Registration | Note | | | Procedures | | +-------------+-------------------+---------------------------------+ | 0-16383 | Standards Action | This range is for Sub-TLVs that | | | | require an error message if not | | | | recognized. | | 16384-31739 | RFC Required | This range is for Sub-TLVs that | | | | require an error message if not | | | | recognized. | | 37140-37144 | Experimental Use | Reserved, not to be assigned | | 31748-32767 | FCFS | This range is for Sub-TLVs that | | | | require an error message if not | | | | recognized. | | 32768-49161 | Standards Action | This range is for Sub-TLVs that | | | | can be silently dropped if not | | | | recognized. | | 49162-64507 | RFC Required | This range is for Sub-TLVs that | | | | can be silently dropped if not | | | | recognized. | | 64508-64511 | Experimental Use | Reserved, not to be assigned | | 64512-65535 | FCFS | This rangethat requires a response if the TLV or sub-TLVisnot recognised; the sedond set areforthe range there the TLV or sub-TLVSub-TLVs thatMAY| | | | can be silently dropped if not | | | | recognized.The code points| +-------------+-------------------+---------------------------------+ Table 12: Registration Procedures forexperimental use are actually taken fromSub-TLVs for TLVs 6 +-------------+---------------+-----------------+-------------------+ | Type | TLV Name | Reference | Comment | +-------------+---------------+-----------------+-------------------+ | 0 | Reserved | This document | | | 1-2 | EQ | EQ | EQ | | 3-31739 | Unassigned | | | | 31740-31743 | Experimental | This Document | Reserved, not to | | | Use | | be assigned | | 31744-64507 | Unassigned | | | | 64508-64511 | Experimental | This document | Resereved, not to | | | Use | | be assigned | | 64512-65535 | Unassigned | | | +-------------+---------------+-----------------+-------------------+ Table 13: Sub-TLVs for TLV 6 Assignments 6.2.4. Updates to thetwo ranges now called "RFC Required". oregistry for SubTLVs for TLV 11 This section describes the new registrationprocedureprocedures and the assignments for the "Sub-TLVs for TLV Type 11" [IANA-Sub-11] sub- registry based on the new registration procedures. o The "Specification Required"isregistration procedure has been changed to "RFCRequired" andRequired", thenotecomment "Experimental RFCneeded" is removedRequired" has been removed. oIn the listing of assignments the termThe code points registration procedure "Vendor Private Use"is changed tohas been removed and replaced with "FirstComeCome, FirstServed (FCFS)" o In the listing of assignments the range for "Experimental Use" is addedServed" code points. oA note saying "Not to be assigned" is added for the registration procedures "Experimental Use"Two small sets, 4 code points each, has been created for Experimental Use. oIn the list that capture assignment status, the fieldsCode points that arereserved, i.e. 0 (zero) and Experimental Usereserved are clearlymarked.marked as such. o Thenew Registration Procedures description andassignments have been updated to match the newassignments for these registries are shown in Section 6.2 and Section 6.3. 4. Updatesregistration procedures. o The notes related toRelated RFCs Some referenced RFCs are usingtheconcept "mandatory TLVs" and "mandatory sub-TLVs"registration procedures have been changed toindicate that,reflect when a response is required if aTLV orsub-TLVofis not recognized or not. The registration procedures for therange"Sub-TLVs for TLV Type 11" [IANA-Sub-11] sub-registry will now look like this: +-------------+-------------------+---------------------------------+ | Range | Registration | Note | | | Procedures | | +-------------+-------------------+---------------------------------+ | 0-16383or 16384-31743 in a message| Standards Action | This range is for Sub-TLVs that | | | | require an error message if notunderstood,| | | | recognized. | | 16384-31739 | RFC Required | This range is for Sub-TLVs that | | | | require an error messageneedsif not | | | | recognized. | | 37140-37144 | Experimental Use | Reserved, not to besent in response. The same RFCs use "optional TLVs" and "optional sub-TLVs" to mean TLVs or sub-TLVsassigned | | 31748-32767 | FCFS | This range is for Sub-TLVs that | | | | require an error message if not | | | | recognized. | | 32768-49161 | Standards Action | This range is for Sub-TLVs that | | | | can be silently dropped if not | | | | recognized. | | 49162-64507 | RFC Required | This range is for Sub-TLVs that | | | | can be silentlyignoreddropped if not | | | | recognized.Since other RFCs use "mandatory TLVs" and "mandatory sub-TLVs"| | 64508-64511 | Experimental Use | Reserved, not toindicate TLVs and sub-TLVs that mustbepresent in a message, we want to discontinue the use of "mandatory" to indicate TLVs and sub-TLVsassigned | | 64512-65535 | FCFS | This range is for Sub-TLVs thatrequires an error message in response| | | | can be silently dropped if notunderstood. The changes to the RFCs below are intended to align with this practice. 4.1. Updates| | | | recognized. | +-------------+-------------------+---------------------------------+ Table 14: Registration Procedures for Sub-TLVs for TLVs 11 +-------------+---------------+-----------------+-------------------+ | Type | TLV Name | Reference | Comment | +-------------+---------------+-----------------+-------------------+ | 0 | Reserved | This document | | | 1-4 | EQ | EQ | EQ | | 5-31739 | Unassigned | | | | 31740-31743 | Experimental | This Document | Reserved, not toRFC 8029 Mandatory and optional is used| | | Use | | be assigned | | 31744-64507 | Unassigned | | | | 64508-64511 | Experimental | This document | Resereved, not toindicate whether are response ir needed or if at| | | Use | | be assigned | | 64512-65535 | Unassigned | | | +-------------+---------------+-----------------+-------------------+ Table 15: Sub-TLVs for TLVor sub-TLV is not understoond page 14 and 15 in Section 3 of RFC 8029. The text in those two paragraphs are now updated11 Assignments 6.2.5. Updates to thefollowing:registry for SubTLVs for TLVand sub-TLV Types less than 32768 (i.e., with the high-order bit equal to 0) are TLVs and sub-TLVs that MUST either be supported by an implementation or result in20 This section describes theReturn Code of 2 ("One or more ofnew registration procedures and theTLVs was not understood") being sent inassignments for theecho response. An implementation that does not understand or support a received"Sub-TLVs for TLVor sub-TLV withTypegreater than or equal to 32768 (i.e., with20" [IANA-Sub-20] sub- registry based on thehigh-order bit equalnew registration procedures. o The "Specification Required" registration procedure has been changed to1) SHOULD ignore and step over"RFC Required", theTLV or sub-TLV, however an implementation MAY send an echo responsecomment "Experimental RFC Required" has been removed. o The code points registration procedure "Vendor Private Use" has been removed and replaced withReturn"First Come, First Served" code points. o Two small sets, 4 code points each, has been created for Experimental Use. o Code2 ("One or more of the TLVs was not understood")points that are reserved are clearly marked asit wouldsuch. o The assignments havedone if the high order bit hadbeenclear. In Section 3.8 of RFC 8029 "mandatory" is used in the same way. The first two paragraphs of this section are nowupdated toread as follows: The following TLV is a TLV that MAY be included in an echo reply to inform the sender of an echo request that includes TLVs or sub- TLVs Types greater than or equal to 32768 (i.e., with the high- order bit equal to 1) are either not supported bymatch theimplementation or parsed and found to be in error.new registration procedures. o TheValue field containsnotes related to theTLVs, including sub-TLVs, that were not understood, encoded as sub-TLVs. 4.2. Updatesregistration procedures have been changed toRFC 8611 The "Sub-TLVs for TLV Type 6" registryreflect when a response isnow updated to align with changes defined in this document.required if a sub-TLV is not recognized or not. The registration procedures for the "Sub-TLVs for TLV Type6" registry20" [IANA-Sub-20] sub-registry will nowbe as follows:look like this: +-------------+-------------------+---------------------------------+ | Range | Registration | Note | | | Procedures | | +-------------+-------------------+---------------------------------+ | 0-16383 | Standards Action | This range is forsub-TLVsSub-TLVs that | | | | require an error message if not | | | | recognized. | | 16384-31739 | RFC Required | This range is forsub-TLVs that | | | | require an error message if not | | | | recognized. | | 31740-31743 | Experimental Use | Reserved not to be assigned | | 31744-32767 | FCFS | This range is for sub-TLVsSub-TLVs that | | | | require an error message if not | | | | recognized. | |32768-49161 | Standards Action | This range is for sub-TLVs that | | | | can be silently dropped if not | | | | recognized. | | 49162-64507 | RFC Required | This range is for sub-TLVs that | | | | can be silently dropped if not | | | | recognized. | | 64508-6451137140-37144 | Experimental Use| Reserved not to be assigned | | 64512-65535 | FCFS | This range is for sub-TLVs that | | | | can be silently dropped if not | | | | recognized. | +-------------+-------------------+---------------------------------+ Sub-TLVs for TLV Type 6 Registration Procedures 5. Security Considerations This document updates IANA registries. It also updates terminology used to define, and clarifies the terminology related to the code points in the registries. The document does not change how the code- points in the registries are used. This should not create any new threats. However, the updated terminology and the clarifications improve security because it makes it more likely that implementations will be consistent and harder to attack. 6. IANA Considerations IANA is requested| Reserved, not toupdate the LSP Ping name space as described in this document. 6.1. Updates of Message Type, Reply Mode and Return Codes Registriesbe assigned | | 31748-32767 | FCFS | Thissection details the updated registration procedures and allocationsrange is forMessage Type, Reply Mode and Return Codes registries. +---------+--------------------+------------------------------------+Sub-TLVs that |Range|Registration|Note| require an error message if not | |Procedures| |+---------+--------------------+------------------------------------+recognized. |0-191| 32768-49161 | Standards Action | This range is for Sub-TLVs that | | |192-247| can be silently dropped if not | | | | recognized. | | 49162-64507 | RFC Required | This range is for Sub-TLVs that | | |248-251| can be silently dropped if not | | | | recognized. | | 64508-64511 | Experimental Use |NotReserved, not to be assigned | |252-25564512-65535 |Private UseFCFS |Not toThis range is for Sub-TLVs that | | | | can beassignedsilently dropped if not |+---------+--------------------+------------------------------------+ New common registration procedures +---------+---------------------------------+-----------------------+|Value|Meaning| recognized. | +-------------+-------------------+---------------------------------+ Table 16: Registration Procedures for Sub-TLVs for TLVs 20 +-------------+---------------+-----------------+-------------------+ | Type | TLV Name | Reference |+---------+---------------------------------+-----------------------+Comment | +-------------+---------------+-----------------+-------------------+ | 0 | Reserved | This document | |1-247|No changes to the existing1-5 | EQ | EQ | EQ |assignments| 6-31739 | Unassigned |248-251|Reserved for| | 31740-31743 | ExperimentalUse| ThisdocumentDocument | Reserved, not to | |252-255|Reserved for PrivateUse |[RFC8029]|+---------+---------------------------------+-----------------------+ Common Assignments for the Message Types, Reply Mode and Return Code registries Note that for the Return Code registry an assignment for code point zero has been previously msde, it isbe assigned | | 31744-64507 | Unassigned | | | | 64508-64511 | Experimental | This document | Resereved, notchanged but remains: +-------+----------------------------------+------------------------+to |Value|Meaning|ReferenceUse |+-------+----------------------------------+------------------------+|0be assigned |No return code|[RFC8029]64512-65535 | Unassigned | |+-------+----------------------------------+------------------------+ Assignment| +-------------+---------------+-----------------+-------------------+ Table 17: Sub-TLVs forcode point 0 inTLV 20 Assignments 6.2.6. Updates to theReturn Coderegistry6.2. Common Registration ProceduresforTLVs and sub-TLVsSubTLVs for TLV 23 This section describes the new registration procedures and the assignments for the "Sub-TLVs for TLVand sub-TLV registries. TheType 23" [IANA-Sub-23] sub- registry based on the new registration procedures. o The "Specification Required" registration procedure has been changed to "RFC Required", the comment "Experimental RFC Required" has been removed. o The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come, First Served" code points. o Two small sets, 4 code points each, has been created for Experimental Use. o Code points that are reserved are clearly marked as such. o The assignments have been updated to match the new registration procedures. o The notes related to the registration procedures have been changed to reflect when a response is required if a sub-TLV9 ([IANA-Sub-9]is notchanged.recognized or not. The registration procedures for the "Sub-TLVs for TLV Type 23" [IANA-Sub-23] sub-registry will now look like this: +-------------+-------------------+---------------------------------+ | Range | Registration | Note | | | Procedures | | +-------------+-------------------+---------------------------------+ | 0-16383 | Standards Action | This range is forTLVs anf sub-Sub-TLVs that | | | |TLVs thatrequire an error message if not | | | |message if notrecognized. | | 16384-31739 | RFC Required | This range is forTLVs anf sub-Sub-TLVs that | | | |TLVs thatrequire an error message if not | | | |message if notrecognized. | | 37140-37144 | Experimental Use |Rserved,Reserved, not to be assigned | | 31748-32767 | FCFS | This range is forTLVs anf sub-Sub-TLVs that | | | |TLVs thatrequire an error message if not | | | |message if notrecognized. | | 32768-49161 | Standards Action | This range is forTLVs and sub-Sub-TLVs that | | | |TLVs thatcan be silently dropped if not | | | |dropped if notrecognized. | | 49162-64507 | RFC Required | This range is for Sub-TLVs that | | | | can be silently dropped if not | | | | recognized. | | 64508-64511 | Experimental Use | Reserved, not to be assigned | | 64512-65535 | FCFS | This range is for Sub-TLVs that | | | | can be silently dropped if not | | | | recognized. | +-------------+-------------------+---------------------------------+ Table 18: Registration Procedures for Sub-TLVs for TLVsand sub-23 +-------------+---------------+-----------------+-------------------+ | Type | TLV Name | Reference | Comment | +-------------+---------------+-----------------+-------------------+ | 0 | Reserved | [RFC7555] | | | 1 | EQ | EQ |TLVs that can be silentlyEQ | | 2-31739 | Unassigned |dropped if not recognized.| |64508-64511| 31740-31743 | ExperimentalUse|Rserved,This Document | Reserved, not to | | | Use | | be assigned | |64512-6553531744-64507 | Unassigned |FCFS| | | 64508-64511 | Experimental | Thisrange is for TLVs and sub-document | Resereved, not to | | |TLVs that canUse | | besilentlyassigned | | 64512-65535 | Unassigned | |dropped if not recognized.|+-------------+-------------------+---------------------------------++-------------+---------------+-----------------+-------------------+ Table 19: Sub-TLVs for TLVand sub-TLV Registration Procedures 6.3. IANA23 Assignments 6.2.7. Updates to the registry forTLVs and sub-TLVs The two tables in thisSubTLVs for TLV 27 This section describes theupdated IANAnew registration procedures and the assignments for the "Sub-TLVs for TLVand sub-TLV registries. TheType 27" [IANA-Sub-27] sub- registry based on the new registration procedures. o The "Specification Required" registration procedure has been changed to "RFC Required", the comment "Experimental RFC Required" has been removed. o The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come, First Served" code points. o Two small sets, 4 code points each, has been created for Experimental Use. o Code points that are reserved are clearly marked as such. o The assignments have been updated to match the new registration procedures. o The notes related to the registration procedures have been changed to reflect when a response is required if a sub-TLV9 ([IANA-Sub-9]is notchanged. Updatedrecognized or not. The registration procedures for the "Sub-TLVs for TLVassignments are as follows: +--------------+------------------+------------------+--------------+ |Type 27" [IANA-Sub-27] sub-registry will now look like this: +-------------+-------------------+---------------------------------+ |TLV name | ReferenceRange |sub-TLVRegistration | Note | | | Procedures |registry|+--------------+------------------+------------------+--------------++-------------+-------------------+---------------------------------+ |00-16383 |ReservedStandards Action | Thisdocumentrange is for Sub-TLVs that | | | | require an error message if not | | |1-31739|[any]recognized. | | 16384-31739 | RFC Required | This range is for Sub-TLVs that |No changes to|[any]| | require an error message if not | | |the current| recognized. | | 37140-37144 | Experimental Use |registryReserved, not to be assigned | | 31748-32767 |37140-37143FCFS |ReservedThis range is for Sub-TLVs that |This document|NA| | require an error message if not |Experimental Use| | | recognized. |31744-32767|FCFS32768-49161 |This documentStandards Action |NAThis range is for Sub-TLVs that | |32768-64507|[any]|No changes tocan be silently dropped if not |[any]| | | recognized. |the current| 49162-64507 | RFC Required | This range is for Sub-TLVs that | |registry.| | can be silently dropped if not |64508-64511|Reserved for|This document|NArecognized. | | 64508-64511 | Experimental Use | Reserved, not to be assigned | || 645152-6553564512-65535 | FCFS | Thisdocumentrange is for Sub-TLVs that | | | | can be silently dropped if not | | |NA|+--------------+------------------+------------------+--------------+recognized. | +-------------+-------------------+---------------------------------+ Table 20: Registration Procedures for Sub-TLVs for TLVAssignments Updated Sub-TLV assignments are as follows: +-------------+-------------------------------+---------------------+27 +-------------+---------------+-----------------+-------------------+ | Type | TLVnameName | Reference |+-------------+-------------------------------+---------------------+Comment | +-------------+---------------+-----------------+-------------------+ | 0 | Reserved |This document[RFC7555] | |1-31739|[any]1 |No changes to theEQ | EQ | EQ | |current registry2-31739 | Unassigned |37140-37143|Reserved for| | 31740-31743 | ExperimentalUse| Thisdocument |Document |31744-32767Reserved, not to |FCFS|This document| Use |32768-64507|[any]be assigned |No changes to the| 31744-64507 | Unassigned | |current registry.| | 64508-64511 |Reserved forExperimentalUse| This document | Resereved, not to | | | Use | | be assigned | | 64512-65535 |FSFCUnassigned |This document|+-------------+-------------------------------+---------------------+ Sub-TLV| +-------------+---------------+-----------------+-------------------+ Table 21: Sub-TLVs for TLV 27 Assignments 7. Acknowledgements The authors wish to thank Adrian Farrel, who both made very useful comments and agreed to serve as the document shepherd. The authors also wish to thank Micelle Cotton who very patiently worked with us to determine how our registries could and should be updated. The authors thanks DonaldEatlakeEastlake for a careful and detailed review. 8. References 8.1. Normative References [IANA-LSP-PING] "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", <https://www.iana.org/assignments/mpls-lsp-ping- parameters/mpls-lsp-ping-parameters.xhtml/>. [IANA-MT] "Message Types", <https://www.iana.org/assignments/mpls- lsp-ping-parameters/mpls-lsp-ping- parameters.xhtml#message-types>. [IANA-RC] "Return Codes", <https://www.iana.org/assignments/mpls- lsp-ping-parameters/#return-codes>. [IANA-RM] "Reply Modes", <https://www.iana.org/assignments/mpls-lsp- ping-parameters/#reply-modes>. [IANA-Sub-1-16-21] "Sub-TLVs for TLV Types 1, 16, and 21", <https://www.iana.org/assignments/https://www.iana.org/ assignments/mpls-lsp-ping-parameters/mpls-lsp-ping- parameters.xhtml#sub-tlv-1-16-21>. [IANA-Sub-11] "Sub-TLVs for TLV Type 11", <https://www.iana.org/assignments/mpls-lsp-ping- parameters/mpls-lsp-ping-parameters/mpls-lsp-ping- parameters.xhtml#sub-tlv-11>. [IANA-Sub-20] "Sub-TLVs for TLV Type 20", <https://www.iana.org/assignments/mpls-lsp-ping- parameters/mpls-lsp-ping-parameters/mpls-lsp-ping- parameters.xhtml#sub-tlv-20>. [IANA-Sub-23] "Sub-TLVs for TLV Type 23", <https://www.iana.org/assignments/mpls-lsp-ping- parameters/mpls-lsp-ping-parameters/mpls-lsp-ping- parameters.xhtml#sub-tlv-23>. [IANA-Sub-27] "Sub-TLVs for TLV Type 27", <https://www.iana.org/assignments/mpls-lsp-ping- parameters/mpls-lsp-ping-parameters/mpls-lsp-ping- parameters.xhtml#sub-tlv-27>. [IANA-Sub-6] "Sub-TLVs for TLV Type 6", <https://www.iana.org/assignments/mpls-lsp-ping- parameters/mpls-lsp-ping-parameters/mpls-lsp-ping- parameters.xhtml#sub-tlv-6>. [IANA-TLV-reg] "TLVs", <https://www.iana.org/assignments/mpls-lsp-ping- parameters/mpls-lsp-ping-parameters.xhtml#tlvs>. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., Aldrin, S., and M. Chen, "Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures", RFC 8029, DOI 10.17487/RFC8029, March 2017, <https://www.rfc-editor.org/info/rfc8029>. [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8287] Kumar, N., Ed., Pignataro, C., Ed., Swallow, G., Akiya, N., Kini, S., and M. Chen, "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes", RFC 8287, DOI 10.17487/RFC8287, December 2017, <https://www.rfc-editor.org/info/rfc8287>. [RFC8611] Akiya, N., Swallow, G., Litkowski, S., Decraene, B., Drake, J., and M. Chen, "Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces", RFC 8611, DOI 10.17487/RFC8611, June 2019, <https://www.rfc-editor.org/info/rfc8611>. 8.2. Informative References [IANA-Sub-9] "Sub-TLVs for TLV Type 9", <https://www.iana.org/assignments/mpls-lsp-ping- parameters/mpls-lsp-ping-parameters/mpls-lsp-ping- parameters.xhtml#sub-tlv-9>. [lsp-ping-NameSpace] "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters", <https://www.iana.org/assignments/mpls-lsp-ping- parameters/mpls-lsp-ping-parameters.xhtml>. [RFC7110] Chen, M., Cao, W., Ning, S., Jounay, F., and S. Delord, "Return Path Specified Label Switched Path (LSP) Ping", RFC 7110, DOI 10.17487/RFC7110, January 2014, <https://www.rfc-editor.org/info/rfc7110>. [RFC7555] Swallow, G., Lim, V., and S. Aldrin, "Proxy MPLS Echo Request", RFC 7555, DOI 10.17487/RFC7555, June 2015, <https://www.rfc-editor.org/info/rfc7555>. [RFC7743] Luo, J., Ed., Jin, L., Ed., Nadeau, T., Ed., and G. Swallow, Ed., "Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping", RFC 7743, DOI 10.17487/RFC7743, January 2016, <https://www.rfc-editor.org/info/rfc7743>. [RFC7759] Bellagamba, E., Mirsky, G., Andersson, L., Skoldstrom, P., Ward, D., and J. Drake, "Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping", RFC 7759, DOI 10.17487/RFC7759, February 2016, <https://www.rfc-editor.org/info/rfc7759>. [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>. Authors' Addresses Loa Andersson Bronze Dragon Consulting Email: loa@pi.nu Mach Chen Huawei Techologies Email: mach.chen@huawei.com Carlos Pignataro Cisco Systems Email: cpignata@cisco.com Tarek Saad Juniper Networks Email: tsaad@juniper.net