rfc-8356

Experimental Codepoint Allocation for the Path Computation Element Communication Protocol (PCEP)

D. Dhody, D. King, A. Farrel

date2018-03 streamIETF areartg wgpce statusPROPOSED STANDARD pages7 canonicalhttps://www.rfc-editor.org/rfc/rfc8356 doi10.17487/RFC8356

IANA assigns values to the Path Computation Element Communication Protocol (PCEP) parameters (messages, objects, TLVs). IANA established a top-level registry to contain all PCEP codepoints and sub-registries. This top-level registry contains sub-registries for PCEP message, object, and TLV types. The allocation policy for each of these sub-registries is IETF Review. This document updates RFC 5440 by changing the allocation policies for these three registries to mark some of the codepoints as assigned for Experimental Use.

updates

rfc-5440 — Path Computation Element (PCE) Communication Protocol (PCEP)

Extracted elements (13)

design-rationale §1

Experimental codepoint ranges were added to PCEP registries to allow testing of new protocol functions without colliding with existing or future allocations, motivated by rapid advancements in PCE technology requiring a safe space to experiment even in closed environments.

registry, process

design-rationale §A

Experimental codepoint ranges were allocated only in the message, object, and TLV sub-registries — not all PCEP sub-registries — because experiments needing a new codepoint in another sub-registry can implement the same function using a new experimental object or TLV instead.

registry, process

interoperability-note §5

An unknown experimental PCEP TLV is ignored per RFC 5440 Section 7.1, requiring no error response from the receiving implementation.

interoperability-note §5

Handling of unknown experimental PCEP objects depends on the message type context; for example, a PCE handles unknown objects in PCReq per RFC 5440 rules, while RFC 8231 specifies rules for unknown objects in PCUpd messages.

normative-requirement §5 MUST

A PCEP implementation that receives an unrecognized experimental PCEP message MUST react by sending a PCErr message with Error-Type=2 (capability not supported) per RFC 5440 Section 6.9.

normative-requirement §1 MUST NOT

Experiments using experimental PCEP codepoints MUST NOT be used in general deployments, and due care must be taken to ensure that two experiments using the same codepoints are not run in the same environment.

registry

protocol-element §2

PCEP message types 252-255 are reserved for Experimental Use; message types 0-251 remain under IETF Review allocation policy.

registry

protocol-element §3

PCEP object identifiers 248-255 are reserved for Experimental Use; object identifiers 0-247 remain under IETF Review. Object-Types 0-15 are also marked for Experimental Use.

registry

protocol-element §4

PCEP TLV type codes 65504-65535 are reserved for Experimental Use; TLV type codes 0-65503 remain under IETF Review allocation policy.

registry

registry §6.1

The 'PCEP Messages' sub-registry within the PCEP Numbers registry is updated: values 0-251 use IETF Review, values 252-255 are marked Experimental Use.

registry

registry §6.2

The 'PCEP Objects' sub-registry within the PCEP Numbers registry is updated: values 0-247 use IETF Review, values 248-255 and Object-Types 0-15 are marked Experimental Use.

registry

registry §6.3

The 'PCEP TLV Type Indicators' sub-registry within the PCEP Numbers registry is updated: values 0-65503 use IETF Review, values 65504-65535 are marked Experimental Use.

registry

security-consideration §7

Implementations accepting experimental codepoints must carefully parse and process experimental messages, objects, and TLVs to avoid misinterpretation from accidental cross-experiment collisions, and must also consider the security aspects of each experimental extension.

security