rfc-9357

Label Switched Path (LSP) Object Flag Extension for Stateful PCE

Q. Xiong
date2023-02 streamIETF areartg wgpce statusPROPOSED STANDARD pages9 canonicalhttps://www.rfc-editor.org/rfc/rfc9357 doi10.17487/RFC9357
RFC 8231 describes a set of extensions to the Path Computation Element Communication Protocol (PCEP) to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. One of the extensions is the LSP object, which includes a Flag field with a length of 12 bits. However, all bits of the Flag field have already been assigned. This document defines a new LSP-EXTENDED-FLAG TLV for the LSP object for an extended Flag field.

updated by

Extracted elements (14)

design-rationale §A

A variable-length TLV (in multiples of 32 bits) was chosen over a fixed 32-bit length to allow future extensibility so that flags would never be exhausted and another new TLV would not need to be defined. This follows the same approach used for the PCE-CAP-FLAGS sub-TLV in RFC 5088 and RFC 5089.

mpls, routing

design-rationale §1

The LSP-EXTENDED-FLAG TLV was introduced because all 12 bits of the original LSP object Flag field defined in RFC 8231 have already been assigned, necessitating an extensible mechanism for additional LSP flags.

mpls, routing

interoperability-note §5

An implementation that does not understand or support the LSP-EXTENDED-FLAG TLV MUST ignore the TLV, as per RFC 5440. Future documents defining bits in the TLV are expected to define error handling for cases where the TLV is missing when it MUST be present.

mpls, routing

normative-requirement §3.2 MUST

Flags that an implementation does not support MUST be set to zero on transmission; implementations that do not understand a particular flag MUST ignore it.

mpls, routing

normative-requirement §3.2 MUST

If a PCEP speaker receives an LSP-EXTENDED-FLAG TLV of a length less than the one supported by the implementation, it MUST act as if the bits beyond the length were not set.

mpls, routing

normative-requirement §3.2 MUST

PCEP peers MUST handle varying lengths of the LSP-EXTENDED-FLAG TLV.

mpls, routing

normative-requirement §3.1 MUST

The Length field of the LSP-EXTENDED-FLAG TLV MUST be in multiples of 4 and greater than 0.

mpls, routing

normative-requirement §3.1 SHOULD

The LSP Extended Flags field SHOULD use the minimal amount of space needed to encode the flag bits.

mpls, routing

normative-requirement §3.1 MUST

Unassigned bits in the LSP Extended Flags field MUST be set to zero on transmission and MUST be ignored on receipt.

mpls, routing

protocol-element §3.1

The LSP-EXTENDED-FLAG TLV (Type=64) is a new TLV for the LSP object that provides an extended Flag field as an array of 32-bit flag units. It follows the standard PCEP TLV format with a 16-bit Type, 16-bit Length, and variable-length LSP Extended Flags field.

mpls, routing

registry §6.1.1

IANA allocated TLV Type Indicator value 64 for LSP-EXTENDED-FLAG within the 'PCEP TLV Type Indicators' registry of the 'Path Computation Element Protocol (PCEP) Numbers' registry.

registry, mpls, routing

registry §6.1.2

IANA created the 'LSP-EXTENDED-FLAG TLV Flag Field' registry within the PCEP Numbers registry to manage the LSP Extended Flags field. New values are assigned by Standards Action. No values are currently defined; Bits 0-31 are initially marked Unassigned.

registry, mpls, routing

security-consideration §8

This document does not change the security considerations set out in RFC 8231 for PCEP with a stateful PCE. RFC 8231 recommends stateful PCEP extensions be authenticated and encrypted using TLS (RFC 8253), per RFC 9325 best practices, which would protect the extended flags.

security, mpls, routing, tls

wire-format §3.1

The LSP-EXTENDED-FLAG TLV has Type=64 (16 bits), a Length field (16 bits) indicating the value portion in bytes, and an LSP Extended Flags field containing an array of 32-bit flag units numbered from the most significant bit as bit zero.

mpls, routing