rfc-8786

Updated Rules for Processing Stateful PCE Request Parameters Flags

A. Farrel

date2020-05 streamIETF areartg wgpce statusPROPOSED STANDARD pages6 canonicalhttps://www.rfc-editor.org/rfc/rfc8786 doi10.17487/RFC8786

Extensions to the Path Computation Element Communication Protocol (PCEP) to support stateful Path Computation Elements (PCEs) are defined in RFC 8231. One of the extensions is the Stateful PCE Request Parameters (SRP) object. That object includes a Flags field that is a set of 32 bit flags, and RFC 8281 defines an IANA registry for tracking assigned flags. However, RFC 8231 does not explain how an implementation should set unassigned flags in transmitted messages, nor how an implementation should process unassigned, unknown, or unsupported flags in received messages. This document updates RFC 8231 by defining the correct behaviors.

updates

rfc-8231 — Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE

Extracted elements (10)

design-rationale §4

Rather than obsoleting the existing Flags field to address the compatibility risk from old implementations that may set unassigned flags arbitrarily, the document concludes the risk is sufficiently small because most implementations will have already set unused flags to zero by convention.

mpls, routing

interoperability-note §4

SRP objects from implementations following this document set all unknown flags to zero, causing no issues to older RFC 8231 implementations. Conversely, a compliant implementation ignores unknown flag bits and is unaffected by older implementations regardless of how they set flags. However, an old RFC 8231 implementation that sets unassigned flags arbitrarily may conflict with new specifications that assign meaning to those flags.

mpls, routing

normative-requirement §3.1 RECOMMENDED

Future specifications that define additional flags for PCEP objects are expected to describe the interaction between new flags and any existing flags, including how to handle cases when both new and pre-existing flags are set.

mpls, routing, registry

normative-requirement §3.2 MUST

Implementations that do not understand any particular flag in the SRP object MUST ignore the flag.

mpls, routing

normative-requirement §3.1 MUST

The P and I flags of PCEP objects defined in RFC 8231 MUST be set to 0 on transmission and SHOULD be ignored on receipt since they are exclusively related to path computation requests.

mpls, routing

normative-requirement §3.2 MUST

Unassigned flags in the SRP object Flags field MUST be set to zero on transmission and MUST be ignored on receipt.

mpls, routing

protocol-element §3.2

The Stateful PCE Request Parameters (SRP) object includes a Flags field that is a set of 32 bits. RFC 8231 originally described it as 'None defined yet'; this document updates the description to require unassigned flags be zeroed on transmission and ignored on receipt.

mpls, routing

registry §7

IANA maintains the 'SRP Object Flag Field' subregistry under 'Path Computation Element Protocol (PCEP) Numbers'. This document is added as a reference for that subregistry alongside RFC 8281.

registry, mpls, routing

security-consideration §6

By requiring implementations to ignore unset bits and leave undefined bits unset, this document reduces the attack surface: implementations cannot be attacked by randomly tweaking undefined flag bits, and the network is future-proofed against new definitions of previously undefined bits.

security, mpls, routing

wire-format §3.2

The SRP object Flags field is 32 bits wide. Unassigned bits must be set to zero on transmission and must be ignored on receipt.

mpls, routing