RFC 9603 - PCEP Extensions for SRv6¶
| Field | Value |
|---|---|
| Title | Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment Routing |
| Authors | C. Li (Ed.), P. Kaladharan, S. Sivabalan, M. Koldychev, Y. Zhu |
| Date | July 2024 |
| Status | Proposed Standard |
| Link | datatracker.ietf.org/doc/rfc9603 |
Summary¶
RFC 8664 taught PCEP to carry SR-MPLS paths. RFC 9603 does the same for SRv6, so a PCE can compute SRv6 paths and a stateful PCE can initiate, update, and receive reports for SRv6 SR Policy candidate paths on a headend (PCC).
The extension is small and reuses the existing PCEP messages unchanged. It adds a new Path Setup Type (PST = 3), an SRv6-PCE-CAPABILITY sub-TLV exchanged in the OPEN message, and new SRv6-ERO / SRv6-RRO subobjects that carry 128-bit SIDs, optionally with the node/adjacency they belong to (the NAI), the endpoint behavior, and the SID structure.
Key Sections¶
| Section | Topic | Description |
|---|---|---|
| 3 | Overview | How SRv6 fits on top of RFC 8664 procedures |
| 4.1 | OPEN Object | PST=3 and SRv6-PCE-CAPABILITY sub-TLV (with optional SRv6 MSDs) |
| 4.2 | RP/SRP Object | PATH-SETUP-TYPE TLV with PST=3 is mandatory for SRv6 messages |
| 4.3 | SRv6-ERO | SID, NAI, endpoint behavior, SID structure |
| 4.4 | SRv6-RRO | Reports the SID list actually applied by the PCC |
| 5 | Procedures | Capability exchange, ERO/RRO validation and error codes |
What It Adds¶
| Element | Codepoint | Purpose |
|---|---|---|
| Path Setup Type | PST = 3 | "Path is set up using SRv6" |
| SRv6-PCE-CAPABILITY sub-TLV | Type 27 | Signals SRv6 support; PCC may add SRv6 MSD pairs and the N flag (can resolve NAI to SID) |
| SRv6-ERO subobject | Type 40 | One SRv6 segment of the computed path |
| SRv6-RRO subobject | Type 40 | One SRv6 segment of the path actually used |
SRv6-ERO Subobject¶
| Field / Flag | Meaning |
|---|---|
| L | Loose hop — PCC may expand or replace SIDs |
| NT | NAI type: 0 = none, 2 = IPv6 node ID, 4 = IPv6 adjacency, 6 = link-local adjacency |
| S | SID absent — PCC resolves it from the NAI |
| F | NAI absent |
| T | SID Structure present (LB, LN, Function, Argument lengths) |
| V | Verify the SID before use (RFC 9256 Section 5.1) |
| Endpoint Behavior | 16-bit RFC 8986 behavior code (0xFFFF if unknown) |
An SRv6-ERO must carry a SID, an NAI, or both, and an ERO cannot mix SRv6-ERO with other subobject types.
MSD Handling¶
A PCC may advertise its SRv6 Maximum SID Depths in the capability sub-TLV, but the PCE must consider the MSDs of every node on the path, not just the headend. If MSDs are available from IGP or BGP-LS, those take precedence, and the RFC recommends leaving them out of PCEP in that case. A PCC that receives a path exceeding its MSD returns a PCErr (Error-Type 10, value 40).
Common Pitfalls
- Every SRv6 PCEP message must carry PST=3 in the RP or SRP object; sending an SRv6-ERO without it, or without having exchanged the capability, triggers a PCErr (Type 19, value 19).
- Advertising PST=3 without the SRv6-PCE-CAPABILITY sub-TLV closes the session.
- Changing the PCC's advertised MSD requires tearing down and re-establishing the PCEP session.
- The SID Structure is optional but useful: it lets the PCE validate SIDs against the operator's allocation plan.
- RFC 9603 covers point-to-point SR Policies. Point-to-multipoint trees (RFC 9960) use a separate draft.
Related Drafts & Updates¶
| Document | Relationship | Description |
|---|---|---|
| RFC 8664 | Extended by this RFC | PCEP extensions for SR-MPLS |
| draft-ietf-pce-segment-routing-ipv6 | Draft lineage | Draft that became RFC 9603 |
| draft-ietf-pce-segment-routing-policy-cp | Companion | PCEP extensions for SR Policy candidate paths |
| draft-ietf-pce-sr-p2mp-policy | Companion | PCEP extensions for SR P2MP Policy |
Related¶
- SR Policy - Candidate paths, PCE-computed paths and Binding SIDs
- RFC 9256 - SR Policy Architecture
- RFC 9514 - BGP-LS Extensions for SRv6 (topology and MSD feed to the PCE)
- RFC 9857 - BGP-LS Advertisement of SR Policies