ietf-corpus

rfc-9041

Updating the MPLS Label Switched Paths (LSPs) Ping Parameters IANA Registry

L. Andersson, M. Chen, C. Pignataro, T. Saad
date2021-07 streamIETF areartg wgmpls statusPROPOSED STANDARD pages31 canonicalhttps://www.rfc-editor.org/rfc/rfc9041 doi10.17487/RFC9041
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").

updates

Extracted elements (16)

design-rationale §1

The original LSP Ping registry incorrectly assumed that code points allocated by Experimental RFCs would be limited to experimental use; however, a code point in a public IANA registry is available for any document type. This, combined with an oversized experimental range, motivated the restructuring of registration procedures.

mpls, registry

design-rationale §4

The terms 'mandatory TLV' and 'optional TLV' were dropped from RFC 8029 language because those words conflict with widespread IETF usage: RFC 8029 used them to indicate required error-response behavior, whereas other RFCs use them to indicate whether a TLV must be present in a message. The updated text describes the required action directly.

mpls

design-rationale §1

The 'Vendor Private Use' and 'Private Use' registration procedures were replaced with 'First Come First Served' because private-use code points are permitted in production networks, creating a risk that two vendors assign the same value with different meanings. If such code points were deployed in the same network, the resulting protocol conflicts would be difficult to debug.

mpls, registry

interoperability-note §6.2

The 'Sub-TLVs for TLV Type 9' subregistry is explicitly excluded from the updates in this document; its registration procedures remain unchanged.

mpls, registry

interoperability-note §1

Vendors that have existing implementations using Vendor Private Use or Private Use code points should register those code points under the First Come First Served procedure as soon as RFC 9041 is published, to avoid conflicts with other vendors' assignments.

mpls

normative-requirement §4.1 SHOULD

An implementation that does not understand a TLV or sub-TLV with type >= 32768 (high-order bit 1) SHOULD ignore and step over it; however, an implementation MAY send an echo response with Return Code 2 as it would have for a lower-range TLV.

mpls

normative-requirement §3.1.1 MAY

If an unrecognized TLV or sub-TLV comes from the upper Experimental Use range (64508-64511) or the upper FCFS range (64512-65535), the receiver may silently drop it, step over it, or send an error message; no mandatory response is required.

mpls

normative-requirement §4.1 MUST

TLV and sub-TLV types less than 32768 (high-order bit 0) 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.

mpls

protocol-element §3.1

The high-order bit of a TLV or sub-TLV type value is the key behavioral discriminator: types 0-32767 (bit = 0) require a Return Code 2 response if unrecognized; types 32768-65535 (bit = 1) may be silently dropped if unrecognized.

mpls

protocol-element §3.2

The TLV and sub-TLV code point space is divided into four registration-procedure blocks per half: Standards Action, RFC Required, Experimental Use (4 code points each, reserved/not to be assigned), and First Come First Served. This structure applies uniformly to the TLVs registry and all updated sub-TLV subregistries.

mpls, registry

registry §6.2

Six sub-TLV subregistries (for TLV Types 1/16/21, 6, 11, 20, 23, and 27) are each updated with the same eight-range structure as the TLVs registry, replacing 'Vendor Private Use' or 'Private Use' with FCFS and adding Experimental Use ranges. The 'Sub-TLVs for TLV Type 9' subregistry is explicitly not updated.

mpls, registry

registry §6.1.1

The 'Message Types' registry under the MPLS LSP Ping Parameters namespace is updated: code point 0 reserved, 'Specification Required' changed to 'RFC Required', four code points (248-251) carved out for Experimental Use, and 252-255 relabeled 'Private Use' (not to be assigned).

mpls, registry

registry §6.1.2

The 'Reply Modes' registry is updated in parallel with Message Types: code point 0 reserved, 'Specification Required' changed to 'RFC Required', 248-251 set aside for Experimental Use, and 252-255 marked Private Use (reserved, not to be assigned).

mpls, registry

registry §6.1.3

The 'Return Codes' registry is updated: 'Specification Required' changed to 'RFC Required', four Experimental Use code points (248-251) added, and the full 36-value assignment table (codes 0-35 plus reserved ranges) is restated. Code point 0 retains its existing assignment as 'No Return Code'.

mpls, registry

registry §6.2.1

The 'TLVs' registry is restructured into eight ranges: Standards Action (0-16383 and 32768-49161), RFC Required (16384-31739 and 49162-64507), Experimental Use (31740-31743 and 64508-64511, not to be assigned), and FCFS (31744-32767 and 64512-65535). The lower four ranges require an error response if unrecognized; the upper four may be silently dropped.

mpls, registry

security-consideration §5

This document updates only IANA registries and their terminology; it does not change how code points are used in the protocol and therefore does not introduce new threats. The clarified terminology improves security by making consistent implementations more likely and reducing ambiguity that could be exploited.

mpls, security