rfc-8664

Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing

S. Sivabalan, C. Filsfils, J. Tantsura, W. Henderickx, J. Hardwick
date2019-12 streamIETF areartg wgpce statusPROPOSED STANDARD pages29 canonicalhttps://www.rfc-editor.org/rfc/rfc8664 doi10.17487/RFC8664 errataview
Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. This document updates RFC 8408.

updated by

updates

Extracted elements (30)

design-rationale §3

SR-TE paths are carried in the existing ERO object via new SR-ERO subobjects rather than defining new PCEP message types. This preserves compatibility with existing PCEP message flows (PCRep, PCInitiate, PCUpd, PCRpt) while adding SR-specific semantics through a new subobject type.

routing, mpls

design-rationale §5.1

The N-Flag and X-Flag in the SR-PCE-CAPABILITY sub-TLV are meaningful only in PCC-to-PCE direction. A PCE MUST set N=0, X=1, and MSD=0 in its outbound Open message to a PCC; the PCC MUST ignore any MSD received from a PCE. This asymmetry reflects that MSD is a PCC data-plane constraint, not a PCE constraint.

routing, mpls

interoperability-note §A

Early implementations sent the SR-CAPABILITY-TLV as a top-level TLV in the OPEN object instead of as a sub-TLV of PATH-SETUP-TYPE-CAPABILITY. Implementations wishing to interoperate SHOULD also send the top-level TLV and interpret receiving it as PATH-SETUP-TYPE-CAPABILITY with PST list (0, 1). If both appear, the top-level SR-CAPABILITY-TLV MUST be ignored.

routing, mpls

normative-requirement §5.2.1 MUST NOT

A PCC MUST NOT accept MPLS label value 3 (Implicit NULL) in an SR-ERO subobject with M=1. If it decides not to accept a label provided by the PCE, it MUST send PCErr Error-Type=10, Error-value=2 ('Bad label value').

routing, mpls

normative-requirement §5.2.1 MUST

A PCC MUST validate SR-ERO subobject consistency: for each NT value (0–6), specific constraints apply to the F bit, S bit, and Length field. Inconsistency MUST trigger PCErr Error-Type=10, Error-value=11 ('Malformed object') and the entire ERO is considered invalid.

routing, mpls

normative-requirement §4.3 MUST

An ERO carrying an SR-TE path MUST carry only SR-ERO subobjects. At least one of SID or NAI MUST be present in each SR-ERO subobject. The S and F bits MUST NOT both be set to 1.

routing, mpls

normative-requirement §5.2.1 MUST

If a PCC detects that the subobjects of an ERO are a mixture of SR-ERO subobjects and other subobject types, it MUST send PCErr Error-Type=10, Error-value=5. If SR-ERO subobjects mix SID representations (MPLS label, index, or absent), it MUST send PCErr Error-value=20.

routing, mpls

normative-requirement §5.1 MUST

If a PCC sets X-Flag to zero, it MUST set the MSD to a number greater than zero. If a PCE receives an SR-PCE-CAPABILITY sub-TLV with X-Flag=0 and MSD=0, it MUST send PCErr Error-Type=10, Error-value=21 ('Maximum SID depth must be non-zero') and MUST close the PCEP session.

routing, mpls

normative-requirement §5.1 MUST

If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with PST=1 but without the SR-PCE-CAPABILITY sub-TLV, it MUST send a PCErr with Error-Type=10, Error-value=12 ('Missing PCE-SR-CAPABILITY sub-TLV') and MUST close the PCEP session.

routing, mpls

normative-requirement §5.2.1 MUST NOT

If an ERO specifies a new SR-TE path for an existing LSP and the PCC encounters invalid SR-ERO subobjects or an error during ERO processing, the PCC MUST NOT update the LSP.

routing, mpls

normative-requirement §5.1 MUST

If the PCE learns the per-node MSD of a PCC from a routing protocol, it MUST ignore the per-node MSD in the SR-PCE-CAPABILITY sub-TLV and use the routing-protocol-derived value instead. If a per-interface MSD is learned, it MUST be used in preference to the sub-TLV MSD for paths using that interface.

routing, mpls

normative-requirement §6.1 MUST

Implementations MUST allow the operator to enable and disable the Segment Routing path setup type on a PCEP-speaking device. PCE implementations MUST allow the operator to specify that an LSP should be instantiated using SR or RSVP-TE as the proposed path setup type.

routing, mpls

normative-requirement §5.1 MUST NOT

Once an SR-capable PCEP session is established with a non-zero MSD value, the PCE MUST NOT send SR-TE paths with a number of SIDs exceeding that MSD value. If a PCC receives such a path, it MUST send PCErr Error-Type=10, Error-value=3 ('Unsupported number of SR-ERO subobjects').

routing, mpls

normative-requirement §5.2.2.1 MUST

Specific PCErr codes are defined for SR-ERO conversion failures: Error-value=14 (Unknown SID), =15 (NAI cannot be resolved), =16 (SRGB not found), =17 (SID index exceeds SRGB), =18 (SRLB not found), =19 (SID index exceeds SRLB), all under Error-Type=10.

routing, mpls

protocol-element §4.5

A new METRIC object type T=11 (Maximum SID Depth) allows a PCC to request the PCE to minimize the SID depth of a computed path. If the B-bit is set, the PCE MUST NOT return a path whose SID depth exceeds the metric value.

routing, mpls

protocol-element §4.1.2

A new Path Setup Type (PST=1) is defined for Segment Routing. PCEP speakers indicate SR support by including PST=1 in the PATH-SETUP-TYPE-CAPABILITY TLV of the OPEN object, and MUST also include the SR-PCE-CAPABILITY sub-TLV when doing so.

routing, mpls

protocol-element §4.3.2

Six NAI types are defined for the SR-ERO/SR-RRO subobject: NT=1 (IPv4 node ID, 4 octets), NT=2 (IPv6 node ID, 16 octets), NT=3 (IPv4 adjacency, 8 octets), NT=4 (IPv6 global adjacency, 32 octets), NT=5 (unnumbered adjacency with IPv4 node IDs, 16 octets), NT=6 (IPv6 link-local adjacency, 40 octets).

routing, mpls

protocol-element §5.2.2

The PCC converts SR-ERO to an MPLS label stack plus next hop: SID index values are converted per RFC 8660; NAI-only subobjects are resolved via the SR-DB; MPLS label subobjects are used directly. The first subobject maps to the topmost label (last-in-first-out stack ordering).

routing, mpls

protocol-element §4.3.1

The SR-ERO subobject M-Flag indicates the SID contains an MPLS label stack entry per RFC 3032; if M=0, the SID is an index into an MPLS label space (SRGB or SRLB). The C-Flag (valid only when M=1) indicates the PCE specifies TC, S, and TTL fields of the label stack entry.

routing, mpls

registry §8.6

IANA created the 'PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators' sub-registry within PCEP Numbers, assigned by Standards Action. Initializes value 0 (Reserved) and value 26 (SR-PCE-CAPABILITY). This document updates RFC 8408 by mandating that sub-TLVs appear in this registry.

registry, routing

registry §8.2

IANA created the 'PCEP SR-ERO NAI Types' sub-registry within 'Path Computation Element Protocol (PCEP) Numbers', allocated by IETF Review. Defines values 0–6 for NAI absence and various node/adjacency identifier types, with values 7–15 unassigned.

registry, routing

registry §8.9

IANA created the 'SR Capability Flag Field' sub-registry within PCEP Numbers (Standards Action). Defines bit 6 (N, NAI resolution supported) and bit 7 (X, unlimited MSD) of the SR-PCE-CAPABILITY TLV flags. Also allocated METRIC T=11 (Segment-ID Depth) and PST=1 (SR path setup type).

registry, routing

registry §8.3

IANA created the 'SR-ERO Flag Field' sub-registry within PCEP Numbers, assigned by Standards Action. Defines bits 8 (F, NAI absent), 9 (S, SID absent), 10 (C, TC/S/TTL specified), and 11 (M, MPLS label).

registry, routing

security-consideration §7

The MSD field in the SR-PCE-CAPABILITY sub-TLV of the Open message discloses the MPLS label imposition capability of edge devices. Without strong encryption on the PCEP session, an attacker can use this field to enumerate network edge device capabilities.

security, routing, mpls

security-consideration §7

Without integrity protection (per RFC 5440, RFC 8231, RFC 8281), an attacker could instantiate an SR path bypassing the verification checks that RSVP-TE signaling would perform. SR-enabled PCEP requires the same security mechanisms as the base PCEP specifications.

security, routing, mpls

wire-format §4.3.2

The IPv4 adjacency NAI (NT=3) is encoded as two consecutive 4-octet IPv4 addresses: Local IPv4 address followed by Remote IPv4 address, for a total of 8 octets.

routing, mpls

wire-format §4.3.2

The IPv6 link-local adjacency NAI (NT=6) is encoded as a pair of (global IPv6 address, interface ID) tuples: 16-octet local IPv6 address, 4-octet local interface ID, 16-octet remote IPv6 address, 4-octet remote interface ID, totaling 40 octets.

routing, mpls

wire-format §4.3.1

The SR-ERO subobject (Type=36) encodes an SR path segment. Fields include: L-Flag (loose hop), NT (NAI type, 4 bits), Flags (F/S/C/M bits), optional 4-octet SID, and optional variable-length NAI. Length MUST be at least 8 and a multiple of 4.

routing, mpls

wire-format §4.1.2

The SR-PCE-CAPABILITY sub-TLV (Type=26, Length=4) carries a 32-bit value with Reserved (16 bits), Flags (8 bits including N and X bits), and MSD (8 bits). The N-Flag indicates NAI-to-SID resolution capability; the X-Flag indicates unlimited MSD.

routing, mpls

wire-format §4.4

The SR-RRO subobject (Type=36) has the same format as the SR-ERO subobject but without the L-Flag. A PCC MUST order SR-RRO subobjects so the first identifies the first segment visited and the last identifies the final segment (endpoint).

routing, mpls