Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry Bronze Dragon Consulting
loa@pi.nu
Huawei Technologies
mach.chen@huawei.com
Cisco Systems
cpignata@cisco.com
Juniper Networks
tsaad@juniper.net
MPLS Working Group This document updates RFCs 8029 and 8611, both of which define IANA registries for MPLS Label Switched Path (LSP) Ping. In particular, the registration procedure "Private Use" (previously known as "Vendor Private Use") has been changed to "First Come First Served" for the TLV and sub-TLV registries. 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 namespace with recent developments, e.g., aligning terminology with RFC 8126 instead of the now obsoleted RFC 5226 (both titled "Guidelines for Writing an IANA Considerations Section in RFCs").
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2021 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 () 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
  • .  Introduction
    • .  Requirements Language
    • .  Terminology
      • .  Terminology Used in This Document
      • .  Abbreviations
  • .  Updating the Message Types, Reply Modes, and Return Codes Registries
  • .  Updating the TLV and Sub-TLV Registries
    • .  General Principles for the LSP Ping TLV and Sub-TLV Registries
      • .  Unrecognized Experimental Use TLVs and Sub-TLVs
    • .  Common Registration Procedures for TLVs and Sub-TLVs
    • .  Changes to the LSP Ping Registries
      • .  Changes Common to the TLV and Sub-TLV Registries
  • .  Updates to Related RFCs
    • .  Updates to RFC 8029
    • .  Updates to RFC 8611
  • .  Security Considerations
  • .  IANA Considerations
    • .  Updates by IANA to the Message Types, Reply Modes, and Return Codes Registries
      • .  Updates to the Message Types Registry
      • .  Updates to the Reply Modes Registry
      • .  Updates to the Return Codes Registry
    • .  Updates to the TLV and Sub-TLV Registries
      • .  Updates to the TLVs Registry
      • .  Updates to the Registry for Sub-TLVs for TLV Types 1, 16, and 21
      • .  Updates to the Registry for Sub-TLVs for TLV Type 6
      • .  Updates to the Registry for Sub-TLVs for TLV Type 11
      • .  Updates to the Registry for Sub-TLVs for TLV Type 20
      • .  Updates to the Registry for Sub-TLVs for TLV Type 23
      • .  Updates to the Registry for Sub-TLVs for TLV Type 27
  • .  References
    • .  Normative References
    • .  Informative References
  • Acknowledgements
  • Authors' Addresses
Introduction There were a number of reasons to start the work that has led to this document, e.g.,
  • When the LSP Ping registry was created, it was incorrectly assumed that code points allocated by Experimental RFCs would be "experimental" code points; a code point made available in a public IANA registry is not limited by the type of RFC that made the allocation: it is available for use in any type of document.
  • The number of "experimental" code points was also too large as compared to what is normally allocated for "Experimental Use".
  • The words "mandatory" and "optional" are used differently in than in other RFCs. For example, talks about mandatory TLVs to indicate that it is mandatory to take a certain action if the TLV is found in a message but is not recognized. Other RFCs use "mandatory TLV" to indicate a TLV that must be present in a message.
Over time, there have been attempts to administratively update some of the registries, but it was soon decided that an RFC was needed. Other, often minor, potential updates were found, e.g., reserving the value 0 (zero) in registries where that is possible. contains updates to the "" IANA namespace . created LSP Ping IANA registries that match . This document further clarifies the entries in those registries and makes the definitions more precise. This document updates and by updating two groups of registries as follows: First, the "Message Types" , "Reply Modes" , and "Return Codes" registries are updated. The changes to these registries are minor. Second, this document updates the TLV and sub-TLV registries listed below:
  • "",
  • "",
  • "",
  • "",
  • "",
  • "",
  • "",
It should be noted that was published before and uses outdated terminology for some registration procedures, e.g., "Vendor Private Use". was published after and uses its recommended terminology, e.g., "Private Use". However, now both "Vendor Private Use" and "Private Use" have been removed and replaced with "First Come First Served" (FCFS) code points. One reason to change from code points allocated by Vendor Private Use or Private Use is that such code points are allowed in production networks. Theoretically, it is possible that two vendors might use the same code point value with different meanings. If such a code is ever deployed in the same network, this could cause protocol issues that would be hard to debug. With FCFS code points, this will not happen. Vendors that have existing code using Vendor Private Use or Private Use code points should register those code points as FCFS code points as soon as this document is published as an RFC. The "" subregistry is not updated. Third, according to , some code points (TLVs and sub-TLVs) are called "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, uses these words to indicate that an action might or might not be mandatory. This document updates to drop the words "mandatory" and "optional", and the text is changed to focus on what should be done.
Requirements 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 when, and only when, they appear in all capitals, as shown here.
Terminology This section lists terms that are used when discussing the hierarchy of IANA registries (), and abbreviations used in IANA registries are updated in this document ().
Terminology Used in This Document Terms related to IANA registries are used as follows in this document:
Namespace
A namespace is a top-level registry. An example could be "" . A namespace is most often a container for registries that hold code points that share some affinity.
Registry
An IANA registry holds code points and lists the registration procedures and allocation for these code points. One example would be the "" registry .
Subregistry
A subregistry is used when a code point, or a set of code points allocated in a single registry, needs "sub-code-points" scoped by the code point or the set of code points. An example of a subregistry that holds code points for more than one TLV is "" .
Abbreviations This section lists abbreviations used in the unchanged part of the registries updated by this document. These abbreviations were originally expanded in the document defining the registries. They are listed here following the requirement to expand any abbreviation that is not well known. All these abbreviations are from the "" registry .
BFD:
Bidirectional Forwarding Detection
DDMAP:
Downstream Detailed Mapping
FEC:
Forwarding Equivalence Class
OAM:
Operation, Administration, and Maintenance
PM:
Performance Monitoring
RSC:
Return Subcode
Updating the Message Types, Reply Modes, and Return Codes Registries The following changes have been made to the "" , "" , and "" registries.
  • In the listing of assigned code points, the term "Vendor Private Use" is changed to "Private Use" for the 252-255 range. The registration procedures have been updated to reflect this.
  • The registration procedure "Specification Required" is changed to "RFC Required" and the note "Experimental RFC needed" is removed for the 192-247 range.
  • A small set of four code points (248-251) for Experimental Use is added by reducing the "RFC Required" range. The registration procedures have been updated to reflect this.
  • A note "Reserved, not to be assigned" has been added for the registration procedures of the "Private Use" and "Experimental Use" ranges.
  • 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.
    • Note that in the "" 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 registries are found in .
Updating the TLV and Sub-TLV Registries
General Principles for the LSP Ping TLV and Sub-TLV Registries The following principles apply to the processing of any TLV from any of the LSP Ping TLV and sub-TLV IANA registries.
  • All TLVs and sub-TLVs with a type in the range 0-32767 require a response if they are not recognized.
  • All TLVs and sub-TLVs in the range 32768-65535 can be silently dropped if they are not recognized. Alternatively, the receiver may step over the unrecognized TLV or send an error message.
Each of the blocks has code point spaces with the following registration procedures:
  • Standards Action
  • RFC Required
  • Experimental Use
  • First Come First Served (FCFS)
The exact definitions of these procedures are found in .
Unrecognized Experimental Use TLVs and Sub-TLVs Unrecognized TLVs and sub-TLVs in the Experimental Use and FCFS ranges are handled as any other unrecognized TLV or sub-TLV.
  • If the unrecognized TLV or sub-TLV is from the Experimental Use range (31740-31743) or from the FCFS range (31744-32767), a Return Code of 2 ("One or more of the TLVs was not understood") must be sent in the echo response.
  • If a TLV or sub-TLV from the Experimental Use range (64508-64511) or from the FCFS range (64512-65535) is unrecognized, then the receiver can silently drop the TLV. Alternatively, the receiver may step over the unrecognized TLV or send an error message.
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 experimental or the private network. The statement above describes how standards-compliant implementations must treat the unrecognized TLVs and sub-TLVs from these ranges.
Common Registration Procedures for TLVs and Sub-TLVs This section describes the new registration procedures for the TLV and sub-TLV registries. TLV and Sub-TLV Registration Procedures
Range Registration Procedures Note
0-16383 Standards Action This range is for TLVs and sub-TLVs that require an error message if not recognized. This document,
16384-31739 RFC Required This range is for TLVs and sub-TLVs that require an error message if not recognized. This document,
31740-31743 Reserved for Experimental Use Not to be assigned. This range is for TLVs and sub-TLVs that require an error message if not recognized. This document,
31744-32767 FCFS This range is for TLVs and sub-TLVs that require an error message if not recognized. This document,
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 Reserved for Experimental Use Not to be assigned. This range is for TLVs and sub-TLVs that can be silently dropped if not recognized.
64512-65535 FCFS This range is for TLVs and sub-TLVs that can be silently dropped if not recognized.
Changes to the LSP Ping Registries This section lists the changes to each MPLS LSP Ping TLV and sub-TLV registry. Sections to describe how the new versions of the IANA registries should look, together with the registration procedures for each registry. The new registration procedure descriptions and the new assignments for these registries are used to model the changed MPLS LSP Ping registries; see .
Changes Common to the TLV and Sub-TLV Registries The following changes are made to the TLV and sub-TLV registries.
  • The registration procedures "First Come First Served" (FCFS) and "Experimental Use" have been added to the table of registration procedures.
  • Two small sets of code points (four code points each) for Experimental Use have been created. The first set is for the range that requires a response if the TLV or sub-TLV is not recognized; the second set is for the range where the TLV or sub-TLV may be silently dropped if not recognized. The code points for Experimental Use have been taken from the ranges previously called "Specification Required" and "RFC Required" .
  • The registration procedure "Specification Required" has been changed to "RFC Required", and the note "Experimental RFC needed" has been removed.
  • In the listing of assignments, the term "Vendor Private Use" has been changed to "First Come First Served" (FCFS).
  • In the listing of assignments, the range for "Experimental Use" has been added.
  • A note saying "Not to be assigned" has been added for the registration procedure "Experimental Use".
  • In the list that captures assignment status, the fields that are reserved, i.e., 0 (zero) and Experimental Use, have been clearly marked.
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-32767 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 require an error message in response if not understood. The changes to the RFCs below align with this practice.
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 in Section of "" . The text in those two paragraphs is 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 a 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 a 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 a Return Code of 2 ("One or more of the TLVs was not understood") as it would have done if the high-order bit had been clear.
In , "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 TLV or sub-TLV Types less than 32768 (i.e., with the high-order bit equal to 0) that are either not supported by the implementation or parsed and found to be in error. The Value field uses sub-TLVs to encode the received TLVs and sub-TLVs that were not understood.
Updates to RFC 8611 Section of "" defines "" . The "" registry has been updated to align with changes defined in this document. is now updated as follows:
Section 13.4.1 Sub-TLVs for TLV Type 6
IANA has created a new subregistry, "", under the "" registry of the "" namespace . The "" subregistry is now updated to align with changes defined in this document. Sub-TLVs for TLV Type 6 Registration Procedures
Range Registration Procedures Note
0-16383 Standards Action This range is for sub-TLVs that require an error message if not recognized. This document,
16384-31739 RFC Required This range is for sub-TLVs that require an error message if not recognized. This document,
31740-31743 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document,
31744-32767 FCFS This range is for sub-TLVs that require an error message if not recognized. This document,
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 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 FCFS This range is for sub-TLVs that can be silently dropped if not recognized.
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.
IANA Considerations IANA has updated the "" namespace as described in this document. See of "" to see how "namespace", "registry", and "subregistry" are used in this document. In other parts of this document, the commonality 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 subregistries have been changed:
  • "",
  • "",
  • "",
  • "",
  • "",
  • "",
  • "",
  • "",
  • "",
  • "",
This document has been listed as an additional reference for each of the registries described in Sections and .
Updates by IANA to the Message Types, Reply Modes, and Return Codes Registries This section details the updated registration procedures and allocations for the "", "", and "" registries.
Updates to the Message Types Registry These are the changes to the "" registry specified in this document:
  • Code Point 0 (zero) has been marked Reserved.
  • The registration procedure "Specification Required" has been changed to "RFC Required", and the comment "Experimental RFC needed" has been removed.
  • Four code points have been taken from what was previously "Specification Required" to form a set of code points for "Experimental Use".
The registration procedures after the changes listed above for the "" registry are shown in the table below: Message Types Registration Procedures
Range Registration Procedures Note
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
The updated assignments for the "" registry appear as follows: Assignments for the Message Types Registry
Value Meaning Reference
0 Reserved This document
1 MPLS Echo Request
2 MPLS Echo Reply
3 MPLS Proxy Ping Request
4 MPLS Proxy Ping Reply
5 MPLS Relayed Echo Reply
6-247 Unassigned
248-251 Reserved for Experimental Use This document
252-255 Reserved for Private Use
Updates to the Reply Modes Registry These are the changes to the "" registry specified in this document:
  • Code Point 0 (zero) has been marked Reserved.
  • The registration procedure "Specification Required" has been changed to "RFC Required", and the comment "Experimental RFC needed" has been removed.
  • Four code points have been taken from what was previously "Specification Required" to form a set of code points for "Experimental Use".
The registration procedures after the changes for the "" registry are shown in the table below: Reply Modes Registration Procedures
Range Registration Procedures Note
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
The updated assignments for the "" registry are as follows: Assignments for the Reply Modes Registry
Value Meaning Reference
0 Reserved This document
1 Do not reply
2 Reply via an IPv4/IPv6 UDP packet
3 Reply via an IPv4/IPv6 UDP packet with Router Alert
4 Reply via application-level control channel
5 Reply via Specified Path
6-247 Unassigned
248-251 Reserved for Experimental Use This document
252-255 Reserved for Private Use
Updates to the Return Codes Registry These are the changes to the "" registry specified in this document:
  • The registration procedure "Specification Required" has been changed to "RFC Required", and the comment "Experimental RFC needed" has been removed.
  • Four code points have been taken from what was previously "Specification Required" to form a set of code points for "Experimental Use".
The registration procedures after the changes for the "" registry are shown in the table below: Return Codes Registration Procedures
Range Registration Procedures Note
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
The updated assignments for the "" registry are as follows: Assignments for the Return Codes Registry
Value Meaning Reference
0 No Return Code
1 Malformed echo request received
2 One or more of the TLVs was not understood
3 Replying router is an egress for the FEC at stack-depth <RSC>
4 Replying router has no mapping for the FEC at stack-depth <RSC>
5 Downstream Mapping Mismatch (See [1])
6 Upstream Interface Index Unknown (See [1])
7 Reserved
8 Label switched at stack-depth <RSC>
9 Label switched but no MPLS forwarding at stack-depth <RSC>
10 Mapping for this FEC is not the given label at stack-depth <RSC>
11 No label entry at stack-depth <RSC>
12 Protocol not associated with interface at FEC stack-depth <RSC>
13 Premature termination of ping due to label stack shrinking to a single label
14 See DDMAP TLV for meaning of Return Code and Return Subcode (See [2])
15 Label switched with FEC change
16 Proxy Ping not authorized
17 Proxy Ping parameters need to be modified
18 MPLS Echo Request could not be sent
19 Replying router has FEC mapping for topmost FEC
20 One or more TLVs not returned due to MTU size
21 OAM Problem/Unsupported BFD Version
22 OAM Problem/Unsupported BFD Encapsulation format
23 OAM Problem/Unsupported BFD Authentication Type
24 OAM Problem/Mismatch of BFD Authentication Key ID
25 OAM Problem/Unsupported Timestamp Format
26 OAM Problem/Unsupported Delay Mode
27 OAM Problem/Unsupported Loss Mode
28 OAM Problem/Delay variation unsupported
29 OAM Problem/Dyadic mode unsupported
30 OAM Problem/Loopback mode unsupported
31 OAM Problem/Combined mode unsupported
32 OAM Problem/Fault management signaling unsupported
33 OAM Problem/Unable to create fault management association
34 OAM Problem/PM Configuration Error
35 Mapping for this FEC is not associated with the incoming interface
36-247 Unassigned
248-251 Reserved for Experimental Use This document
252-255 Reserved for Private Use
Note 1:
Notes [1] and [2] for code points 5, 6, and 14 point to footnotes in the "" namespace. The footnotes are not changed by this document.
Note 2:
<RSC> stands for "Return Subcode" and is explained in .
Updates to the TLV and Sub-TLV Registries The updates to the TLV and the sub-TLV registries are mostly the same; however, the "" registry has not been updated. Note that when a field in an assignment table says "EQ", it means that there is no change from the existing field in the "" namespace .
Updates to the TLVs Registry This section describes the new registration procedures and the assignments for the "" registry that are based on them. The registration procedures have been changed, as follows, for the "" registry.
  • The "Specification Required" registration procedure has been changed to "RFC Required". The comment "Experimental RFC Required" has been removed. Note that when a field in an assignment table says "EQ", it means that there is no change from the existing field in the "" namespace .
  • was published after and uses the new terminology, e.g., "Private Use". The code points registration procedure "Private Use" has been replaced by the "First Come First Served" code point registration procedure.
  • Two small sets, four code points each, have been created for Experimental Use.
  • Code points that are reserved are clearly marked as such.
  • The assignments have been updated to match the new registration procedures.
  • The notes related to the registration procedures have been changed to reflect whether or not a response is required if a TLV is not recognized.
The registration procedures for the "" registry after the changes listed above are shown in the table below: TLVs Registration Procedures
Range Registration Procedures Note
0-16383 Standards Action This range is for TLVs that require an error message if not recognized. This document,
16384-31739 RFC Required This range is for TLVs that require an error message if not recognized. This document,
31740-31743 Reserved for Experimental Use Not to be assigned. This range is for TLVs that require an error message if not recognized. This document,
31744-32767 FCFS This range is for TLVs that require an error message if not recognized. This document,
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 Reserved for Experimental Use Not to be assigned. This range is for TLVs that can be silently dropped if not recognized.
64512-65535 FCFS This range is for TLVs that can be silently dropped if not recognized.
The updated assignments for this registry appear as follows: Note that when a field in an assignment table says "EQ", it means that there was no change from the existing field in the "" namespace . TLV Assignments
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 Reserved for Experimental Use This document Not to be assigned. This range is for TLVs that require an error message if not recognized. This document,
31744-32767 Unassigned
32768-32770 EQ EQ EQ
32771-64507 EQ EQ EQ
64508-64511 Reserved for Experimental Use This document Not to be assigned. This range is for TLVs that can be silently dropped if not recognized.
64512-65535 Unassigned
Updates to the Registry for Sub-TLVs for TLV Types 1, 16, and 21 This section describes the new registration procedures and the assignments for the "" subregistry that are based on them.
  • The "Specification Required" registration procedure has been changed to "RFC Required", and the comment "Experimental RFC Required" has been removed.
  • The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come First Served" procedure.
  • Two small sets, four code points each, have been created for Experimental Use.
  • Code points that are reserved are clearly marked as such.
  • The assignments have been updated to match the new registration procedures.
  • The notes related to the registration procedures have been changed to reflect whether or not a response is required if a sub-TLV is not recognized.
The registration procedures for the "" subregistry appear as follows after the changes listed above: Registration Procedures for Sub-TLVs for TLV Types 1, 16, and 21
Range Registration Procedures Note
0-16383 Standards Action This range is for sub-TLVs that require an error message if not recognized. This document,
16384-31739 RFC Required This range is for sub-TLVs that require an error message if not recognized. This document,
31740-31743 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document,
31744-32767 FCFS This range is for sub-TLVs that require an error message if not recognized. This document,
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 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 FCFS This range is for sub-TLVs that can be silently dropped if not recognized.
Sub-TLV for TLVs 1, 16, and 21 Assignments
Sub-Type Sub-TLV Name Reference Comment
0 Reserved This document
1-4 EQ EQ EQ
5 Unassigned
6-8 EQ EQ EQ
9 EQ EQ DEPRECATED
10-20 EQ EQ EQ
21 Unassigned
22-37 EQ EQ EQ
38 PeerAdj SID Sub-TLV [draft-ietf-mpls-sr-epe-oam-03] TEMPORARY - registered 2021-05-11, expires 2022-05-11
39 PeerNode SID Sub-TLV [draft-ietf-mpls-sr-epe-oam-03] TEMPORARY - registered 2021-05-11, expires 2022-05-11
40 PeerSet SID Sub-TLV [draft-ietf-mpls-sr-epe-oam-03] TEMPORARY - registered 2021-05-11, expires 2022-05-11
41-31739 Unassigned
31740-31743 Reserved for Experimental Use This document Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document,
31744-64507 Unassigned
64508-64511 Reserved for Experimental Use This document Not to be assigned. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 Unassigned
Updates to the Registry for Sub-TLVs for TLV Type 6 This section describes the new registration procedures and the assignments for the "" subregistry that are based on them.
  • was published after and uses the new terminology, e.g., "Private Use". The code points registration procedure "Private Use" has been replaced by the "First Come First Served" code point registration procedure.
  • Two small sets, four code points each, have been created for Experimental Use.
  • Code points that are reserved are clearly marked as such.
  • The assignments have been updated to match the new registration procedures.
  • The notes related to the registration procedures have been changed to reflect whether or not a response is required if a sub-TLV is not recognized.
The registration procedures for the "" subregistry after the changes listed above are shown in the table below: Registration Procedures for Sub-TLVs for TLV Type 6
Range Registration Procedures Note
0-16383 Standards Action This range is for sub-TLVs that require an error message if not recognized. This document,
16384-31739 RFC Required This range is for sub-TLVs that require an error message if not recognized. This document,
31740-31743 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document,
31744-32767 FCFS This range is for sub-TLVs that require an error message if not recognized. This document,
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 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 FCFS This range is for sub-TLVs that can be silently dropped if not recognized.
Sub-TLVs for TLV Type 6 Assignments
Sub-Type Sub-TLV Name Reference Comment
0 Reserved This document,
1-2 EQ EQ EQ
3-31739 Unassigned
31740-31743 Reserved for Experimental Use This document Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document,
31744-64507 Unassigned
64508-64511 Reserved for Experimental Use This document Not to be assigned. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 Unassigned
Updates to the Registry for Sub-TLVs for TLV Type 11 This section describes the new registration procedures and the assignments for the "" subregistry that are based on them.
  • The "Specification Required" registration procedure has been changed to "RFC Required", and the comment "Experimental RFC Required" has been removed.
  • The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come First Served" code points.
  • Two small sets, four code points each, have been created for Experimental Use.
  • Code points that are reserved are clearly marked as such.
  • The assignments have been updated to match the new registration procedures.
  • The notes related to the registration procedures have been changed to reflect whether or not a response is required if a sub-TLV is not recognized.
The registration procedures for the "" subregistry after the changes listed above are shown in the table below: Registration Procedures for Sub-TLVs for TLV Type 11
Range Registration Procedures Note
0-16383 Standards Action This range is for sub-TLVs that require an error message if not recognized. This document,
16384-31739 RFC Required This range is for sub-TLVs that require an error message if not recognized. This document,
31740-31743 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document,
31744-32767 FCFS This range is for sub-TLVs that require an error message if not recognized. This document,
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 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 FCFS This range is for sub-TLVs that can be silently dropped if not recognized.
Sub-TLVs for TLV Type 11 Assignments
Sub-Type Sub-TLV Name Reference Comment
0 Reserved This document
1-4 EQ EQ EQ
5-31739 Unassigned
31740-31743 Reserved for Experimental Use This document Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document,
31744-64507 Unassigned
64508-64511 Reserved for Experimental Use This document Not to be assigned. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 Unassigned
Updates to the Registry for Sub-TLVs for TLV Type 20 This section describes the new registration procedures and the assignments for the "" subregistry that are based on them.
  • The "Specification Required" registration procedure has been changed to "RFC Required", and the comment "Experimental RFC Required" has been removed.
  • The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come First Served" code points.
  • Two small sets, four code points each, have been created for Experimental Use.
  • Code points that are reserved are clearly marked as such.
  • The assignments have been updated to match the new registration procedures.
  • The notes related to the registration procedures have been changed to reflect whether or not a response is required if a sub-TLV is not recognized.
The registration procedures for the "" subregistry after the changes listed above are shown in the table below: Registration Procedures for Sub-TLVs for TLV Type 20
Range Registration Procedures Note
0-16383 Standards Action This range is for sub-TLVs that require an error message if not recognized. This document, ]
16384-31739 RFC Required This range is for sub-TLVs that require an error message if not recognized. This document, ]
31740-31743 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document, ]
31744-32767 FCFS This range is for sub-TLVs that require an error message if not recognized. This document, ]
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 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 FCFS This range is for sub-TLVs that can be silently dropped if not recognized.
Sub-TLVs for TLV Type 20 Assignments
Sub-Type Sub-TLV Name Reference Comment
0 Reserved This document
1-5 EQ EQ EQ
6-31739 Unassigned
31740-31743 Reserved for Experimental Use This document Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document, ]
31744-64507 Unassigned
64508-64511 Reserved for Experimental Use This document Not to be assigned. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 Unassigned
Updates to the Registry for Sub-TLVs for TLV Type 23 This section describes the new registration procedures and the assignments for the "" subregistry that are based on them.
  • The "Specification Required" registration procedure has been changed to "RFC Required", and the comment "Experimental RFC Required" has been removed.
  • The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come First Served" code points.
  • Two small sets, four code points each, have been created for Experimental Use.
  • Code points that are reserved are clearly marked as such.
  • The assignments have been updated to match the new registration procedures.
  • The notes related to the registration procedures have been changed to reflect whether or not a response is required if a sub-TLV is not recognized.
The registration procedures for the "" subregistry after the changes listed above are shown in the table below: Registration Procedures for Sub-TLVs for TLV Type 23
Range Registration Procedures Note
0-16383 Standards Action This range is for sub-TLVs that require an error message if not recognized. This document, ]
16384-31739 RFC Required This range is for sub-TLVs that require an error message if not recognized. This document, ]
31740-31743 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document, ]
31744-32767 FCFS This range is for sub-TLVs that require an error message if not recognized. This document, ]
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 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 FCFS This range is for sub-TLVs that can be silently dropped if not recognized.
Sub-TLVs for TLV Type 23 Assignments
Sub-Type Sub-TLV Name Reference Comment
0 Reserved
1 EQ EQ EQ
2-31739 Unassigned
31740-31743 Reserved for Experimental Use This document Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document, ]
31744-64507 Unassigned
64508-64511 Reserved for Experimental Use This document Not to be assigned. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 Unassigned
Updates to the Registry for Sub-TLVs for TLV Type 27 This section describes the new registration procedures and the assignments for the "" subregistry that are based on them.
  • The "Specification Required" registration procedure has been changed to "RFC Required", and the comment "Experimental RFC Required" has been removed.
  • The code points registration procedure "Vendor Private Use" has been removed and replaced with "First Come First Served" code points.
  • Two small sets, four code points each, have been created for Experimental Use.
  • Code points that are reserved are clearly marked as such.
  • The assignments have been updated to match the new registration procedures.
  • The notes related to the registration procedures have been changed to reflect whether or not a response is required if a sub-TLV is not recognized.
The registration procedures for the "" subregistry after the changes listed above are shown in the table below: Registration Procedures for Sub-TLVs for TLV Type 27
Range Registration Procedures Note
0-16383 Standards Action This range is for sub-TLVs that require an error message if not recognized. This document, ]
16384-31739 RFC Required This range is for sub-TLVs that require an error message if not recognized. This document, ]
31740-31743 Reserved for Experimental Use Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document, ]
31744-32767 FCFS This range is for sub-TLVs that require an error message if not recognized. This document, ]
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. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 FCFS This range is for sub-TLVs that can be silently dropped if not recognized.
Sub-TLVs for TLV Type 27 Assignments
Sub-Type Sub-TLV Name Reference Comment
0 Reserved
1-99 Unassigned
100-104 EQ EQ EQ
105-199 Unassigned
200-202 EQ EQ EQ
203-299 Unassigned
300 EQ EQ EQ
301-399 Unassigned
400 EQ EQ EQ
401-31739 Unassigned
31740-31743 Reserved for Experimental Use This document Not to be assigned. This range is for sub-TLVs that require an error message if not recognized. This document, ]
31744-64507 Unassigned
64508-64511 Reserved for Experimental Use This document Not to be assigned. This range is for sub-TLVs that can be silently dropped if not recognized.
64512-65535 Unassigned
References Normative References Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters IANA Message Types IANA Return Codes IANA Reply Modes IANA Sub-TLVs for TLV Types 1, 16, and 21 IANA Sub-TLVs for TLV Type 11 IANA Sub-TLVs for TLV Type 20 IANA Sub-TLVs for TLV Type 23 IANA Sub-TLVs for TLV Type 27 IANA Sub-TLVs for TLV Type 6 IANA TLVs IANA Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults. This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122. Guidelines for Writing an IANA Considerations Section in RFCs Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable the determination of the capabilities supported by a Label Switching Router (LSR). This document updates RFC 8029. Informative References Sub-TLVs for TLV Type 9 IANA Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters IANA Return Path Specified Label Switched Path (LSP) Ping This document defines extensions to the data-plane failure-detection protocol for Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) known as "LSP ping". These extensions allow a selection of the LSP to be used for the echo reply return path. Enforcing a specific return path can be used to verify bidirectional connectivity and also increase LSP ping robustness. Proxy MPLS Echo Request This document defines a means of remotely initiating Multiprotocol Label Switched Protocol (MPLS) Pings on Label Switched Paths. An MPLS Proxy Ping Request is sent to any Label Switching Router along a Label Switched Path. The primary motivations for this facility are first to limit the number of messages and related processing when using LSP Ping in large Point-to-Multipoint LSPs, and second to enable tracing from leaf to leaf (or root). Relayed Echo Reply Mechanism for Label Switched Path (LSP) Ping In some inter-AS (Autonomous System) and inter-area deployment scenarios for RFC 4379 ("Label Switched Path (LSP) Ping and Traceroute"), a replying Label Switching Router (LSR) may not have the available route to an initiator, and the Echo Reply message sent to the initiator would be discarded, resulting in false negatives or a complete failure of operation of the LSP Ping and Traceroute. This document describes extensions to the LSP Ping mechanism to enable the replying LSR to have the capability to relay the Echo Response by a set of routable intermediate nodes to the initiator. This document updates RFC 4379. Configuration of Proactive Operations, Administration, and Maintenance (OAM) Functions for MPLS-Based Transport Networks Using Label Switched Path (LSP) Ping This specification describes the configuration of proactive MPLS-TP Operations, Administration, and Maintenance (OAM) functions for a given Label Switched Path (LSP) using a set of TLVs that are carried by the LSP Ping protocol. Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with MPLS Data Planes A Segment Routing (SR) architecture leverages source routing and tunneling paradigms and can be directly applied to the use of a Multiprotocol Label Switching (MPLS) data plane. A node steers a packet through a controlled set of instructions called "segments" by prepending the packet with an SR header. The segment assignment and forwarding semantic nature of SR raises additional considerations for connectivity verification and fault isolation for a Label Switched Path (LSP) within an SR architecture. This document illustrates the problem and defines extensions to perform LSP Ping and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifiers (SIDs) with an MPLS data plane.
Acknowledgements The authors wish to thank , who both made very useful comments and agreed to serve as the Document Shepherd. The authors also wish to thank and , who very patiently worked with us to determine how our registries could and should be updated. The authors thank and for their careful and detailed review.
Authors' Addresses Bronze Dragon Consulting
loa@pi.nu
Huawei Technologies
mach.chen@huawei.com
Cisco Systems
cpignata@cisco.com
Juniper Networks
tsaad@juniper.net