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").

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 https://www.rfc-editor.org/info/rfc9041.

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 (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.

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 [RFC 8029] than in other RFCs. For example, [RFC 8029] 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. [RFC 8029] contains updates to the "[Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters]" IANA namespace [IANA-LSP-PING]. [RFC 8611] created LSP Ping IANA registries that match [RFC 8126]. This document further clarifies the entries in those registries and makes the definitions more precise. This document updates [RFC 8029] and [RFC 8611] by updating two groups of registries as follows: First, the "Message Types" [IANA-MT], "Reply Modes" [IANA-RM], and "Return Codes" [IANA-RC] registries are updated. The changes to these registries are minor. Second, this document updates the TLV and sub-TLV registries listed below:

• "[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]

It should be noted that [RFC 8029] was published before [RFC 8126] and uses outdated terminology for some registration procedures, e.g., "Vendor Private Use". [RFC 8611] was published after [RFC 8126] 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 "[Sub-TLVs for TLV Type 9]" subregistry is not updated. Third, according to [RFC 8029], 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, [RFC 8029] uses these words to indicate that an action might or might not be mandatory. This document updates [RFC 8029] to drop the words "mandatory" and "optional", and the text is changed to focus on what should be done.

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 [RFC 2119] [RFC 8174] when, and only when, they appear in all capitals, as shown here.

This section lists terms that are used when discussing the hierarchy of IANA registries (Section 1.2.1), and abbreviations used in IANA registries are updated in this document (Section 1.2.2).

Terms related to IANA registries are used as follows in this document:

Namespace

A namespace is a top-level registry. An example could be "[Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters]" [IANA-LSP-PING]. 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 "[TLVs]" registry [IANA-TLV-reg].

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 "[Sub-TLVs for TLV Types 1, 16, and 21]" [IANA-Sub-1-16-21].

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 "[Return Codes]" registry [IANA-RC].

BFD:

Bidirectional Forwarding Detection

DDMAP:

Downstream Detailed Mapping

FEC:

Forwarding Equivalence Class

OAM:

Operation, Administration, and Maintenance

PM:

Performance Monitoring

RSC:

Return Subcode

The following changes have been made to the "[Message Types]" [IANA-MT], "[Reply Modes]" [IANA-RM], and "[Return Codes]" [IANA-RC] 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 "[Return Codes]" registry [IANA-RC], 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 Section 6.1.

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 [RFC 8126].

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.

This section describes the new registration procedures for the TLV and sub-TLV registries. Table 1: TLV and Sub-TLV Registration Procedures

This section lists the changes to each MPLS LSP Ping TLV and sub-TLV registry. Sections [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 procedure descriptions and the new assignments for these registries are used to model the changed MPLS LSP Ping registries; see Section 6.

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 tothe table of registration procedures.
• Two small sets of code points (four code points each) for Experimental Use have beencreated. The first set is for the range that requires a response if the TLV orsub-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" [RFC 8029].
• The registration procedure "Specification Required" has been changed to "RFCRequired", 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.

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.

"Mandatory" and "optional" are used to indicate whether a response is needed if a TLV or sub-TLV is not understood in Section 3 of "[Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures]" [RFC 8611]. The text in those two paragraphs is now updated to the following:

---

---

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:

---

---

Section 13.4.1 of "[Label Switched Path (LSP) Ping and Traceroute Multipath Support for Link Aggregation Group (LAG) Interfaces]" [RFC 8611] defines "[Sub-TLVs for TLV Type 6]" [IANA-Sub-6]. The "[Sub-TLVs for TLV Type 6]" registry has been updated to align with changes defined in this document. Section 13.4.1 of RFC 8611 is now updated as follows:

---

---

IANA has created a new subregistry, "[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]" namespace [lsp-ping-Namespace]. The "[Sub-TLVs for TLV Type 6]" subregistry is now updated to align with changes defined in this document. Table 2: Sub-TLVs for TLV Type 6 Registration Procedures

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 has updated the "[Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters]" namespace [IANA-LSP-PING] as described in this document. See Section 1.2.1 of "[Terminology Used in This Document]" 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:

• "[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]

This document has been listed as an additional reference for each of the registries described in Sections [6.1] and [6.2].

This section details the updated registration procedures and allocations for the "[Message Types]", "[Reply Modes]", and "[Return Codes]" registries.

These are the changes to the "[Message Types]" 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 "[Message Types]" registry are shown in the table below: Table 3: Message Types Registration Procedures The updated assignments for the "[Message Types]" registry appear as follows: Table 4: Assignments for the Message Types Registry

These are the changes to the "[Reply Modes]" 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 "[Reply Modes]" registry are shown in the table below: Table 5: Reply Modes Registration Procedures The updated assignments for the "[Reply Modes]" registry are as follows: Table 6: Assignments for the Reply Modes Registry

These are the changes to the "[Return Codes]" 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 "[Return Codes]" registry are shown in the table below: Table 7: Return Codes Registration Procedures The updated assignments for the "[Return Codes]" registry are as follows: Table 8: Assignments for the Return Codes Registry

Note 1:

Notes [1] and [2] for code points 5, 6, and 14 point to footnotes in the "[Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters]" namespace. The footnotes are not changed by this document.

Note 2:

<RSC> stands for "Return Subcode" and is explained in Section 3.1 of RFC 8029.

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] 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 "[Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters]" namespace [IANA-LSP-PING].

This section describes the new registration procedures and the assignments for the "[TLVs]" registry [IANA-TLV-reg] that are based on them. The registration procedures have been changed, as follows, for the "[TLVs]" 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 "[Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters]" namespace [IANA-LSP-PING].
• [RFC 8611] was published after [RFC 8126] 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 "[TLVs]" registry [IANA-TLV-reg] after the changes listed above are shown in the table below: Table 9: TLVs Registration Procedures 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 "[Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters]" namespace [IANA-LSP-PING]. Table 10: TLV Assignments

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] 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 "[Sub-TLVs for TLV Types 1, 16, and 21]" [IANA-Sub-1-16-21] subregistry appear as follows after the changes listed above: Table 11: Registration Procedures for Sub-TLVs for TLV Types 1, 16, and 21 Table 12: Sub-TLV for TLVs 1, 16, and 21 Assignments

This section describes the new registration procedures and the assignments for the "[Sub-TLVs for TLV Type 6]" [IANA-Sub-6] subregistry that are based on them.

• [RFC 8611] was published after [RFC 8126] 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 "[Sub-TLVs for TLV Type 6]" [IANA-Sub-6] subregistry after the changes listed above are shown in the table below: Table 13: Registration Procedures for Sub-TLVs for TLV Type 6 Table 14: Sub-TLVs for TLV Type 6 Assignments

This section describes the new registration procedures and the assignments for the "[Sub-TLVs for TLV Type 11]" [IANA-Sub-11] 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 "[Sub-TLVs for TLV Type 11]" [IANA-Sub-11] subregistry after the changes listed above are shown in the table below: Table 15: Registration Procedures for Sub-TLVs for TLV Type 11 Table 16: Sub-TLVs for TLV Type 11 Assignments

This section describes the new registration procedures and the assignments for the "[Sub-TLVs for TLV Type 20]" [IANA-Sub-20] 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 "[Sub-TLVs for TLV Type 20]" [IANA-Sub-20] subregistry after the changes listed above are shown in the table below: Table 17: Registration Procedures for Sub-TLVs for TLV Type 20 Table 18: Sub-TLVs for TLV Type 20 Assignments

This section describes the new registration procedures and the assignments for the "[Sub-TLVs for TLV Type 23]" [IANA-Sub-23] 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 "[Sub-TLVs for TLV Type 23]" [IANA-Sub-23] subregistry after the changes listed above are shown in the table below: Table 19: Registration Procedures for Sub-TLVs for TLV Type 23 Table 20: Sub-TLVs for TLV Type 23 Assignments

This section describes the new registration procedures and the assignments for the "[Sub-TLVs for TLV Type 27]" [IANA-Sub-27] 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 "[Sub-TLVs for TLV Type 27]" [IANA-Sub-27] subregistry after the changes listed above are shown in the table below: Table 21: Registration Procedures for Sub-TLVs for TLV Type 27 Table 22: Sub-TLVs for TLV Type 27 Assignments

[IANA-LSP-PING]

IANA, "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters>.

[IANA-MT]

IANA, "Message Types",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters/>.

[IANA-RC]

IANA, "Return Codes",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters/>.

[IANA-RM]

IANA, "Reply Modes",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters/>.

[IANA-Sub-1-16-21]

IANA, "Sub-TLVs for TLV Types 1, 16, and 21",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters/>.

[IANA-Sub-11]

IANA, "Sub-TLVs for TLV Type 11",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters/>.

[IANA-Sub-20]

IANA, "Sub-TLVs for TLV Type 20",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters/>.

[IANA-Sub-23]

IANA, "Sub-TLVs for TLV Type 23",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters/>.

[IANA-Sub-27]

IANA, "Sub-TLVs for TLV Type 27",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters/>.

[IANA-Sub-6]

IANA, "Sub-TLVs for TLV Type 6",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters/>.

[IANA-TLV-reg]

IANA, "TLVs",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters/>.

[RFC2119]

S. Bradner, "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]

K. Kompella, G. Swallow, C. Pignataro, N. Kumar, S. Aldrin, 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>.

[RFC8126]

M. Cotton, B. Leiba, 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>.

[RFC8174]

B. Leiba, "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>.

[RFC8611]

N. Akiya, G. Swallow, S. Litkowski, B. Decraene, J. Drake, 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>.

[IANA-Sub-9]

IANA, "Sub-TLVs for TLV Type 9",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters/>.

[lsp-ping-Namespace]

IANA, "Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs) Ping Parameters",
<https://www.iana.org/assignments/mpls-lsp-ping-parameters/>.

[RFC7110]

M. Chen, W. Cao, S. Ning, F. Jounay, 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]

G. Swallow, V. Lim, and S. Aldrin, "Proxy MPLS Echo Request", RFC 7555, DOI 10.17487/RFC7555, June 2015,
<https://www.rfc-editor.org/info/rfc7555>.

[RFC7743]

J. Luo, L. Jin, T. Nadeau, and G. Swallow, "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]

E. Bellagamba, G. Mirsky, L. Andersson, P. Skoldstrom, D. Ward, 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>.

[RFC8287]

N. Kumar, C. Pignataro, G. Swallow, N. Akiya, S. Kini, 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>.

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 Michelle Cotton and Amanda Baber, who very patiently worked with us to determine how our registries could and should be updated. The authors thank Donald Eastlake 3rd and Tom Petch for their careful and detailed review.

Loa Andersson

Mach(Guoyi) Chen

Carlos Pignataro

Tarek Saad