RFC 9933

Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP)

📅 published July 2026, from ietf

📜 RFC 9933: Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP) 🦋

okay bestie, this is the RFC doc you asked for, and it's giving networking royalty 👑✨. it's part 1 of 6, so more is coming. no sign-off yet 💅

Title block, the tea ☕:

Number: RFC 9933 🎀
Title: Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP)
Authors: S. Sidor (Cisco Systems, Inc.), Z. Rose (Cisco Systems, Inc.), S. Peng (ZTE Corporation), S. Peng (Huawei Technologies), A. Stone (Nokia) 💖
Category: Standards Track 🔥
Status: Internet Standards Track document, published by the IETF with consensus and IESG approval 🌈
Date: July 2026 📅
ISSN: 2070-1721
Updates: RFC 8664 and RFC 9603 🫶

Abstract ✨

okay so this doc is all about upgrading PCEP (the protocol where a PCC and a PCE chat about paths) so it can do Segment Routing (SR) with SR-Algorithms in Traffic Engineering (TE) 🦋. the SR-Algorithm tied to a SID basically says which path computation algorithm the IGPs are using 🧚.

so now PCEP peers can tell each other the SR-Algorithm for a SID by encoding it in ERO and RRO subobjects 💅. it also lets you add SR-Algorithm constraints when computing paths, and it adds brand-new metric types to the METRIC object 📈. and yes, it updates RFC 8664 and RFC 9603 so all of this actually fits together 🫶. literal main character energy 👑.

Status of This Memo 📋

this is an Internet Standards Track doc, which means it's the real deal 🔥. it's a product of the IETF and represents the consensus of the IETF community. it got public review and was approved for publication by the IESG 💖.

if you want the deets on Internet Standards, check out Section 2 of RFC 7841 🌸. for the current status, errata, or to send feedback, go to https://www.rfc-editor.org/info/rfc9933 ✨.

Copyright Notice 🌈

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. read those carefully, bestie, because they explain your rights and restrictions 🙈. any Code Components pulled out of this doc must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, per the Revised BSD License 💀.

Table of Contents 🗺️

1.  Introduction
  1.1.  Requirements Language
2.  Terminology
3.  Motivation
4.  Object Formats
  4.1.  OPEN Object
    4.1.1.  SR PCE Capability Sub-TLV
    4.1.2.  SRv6 PCE Capability Sub-TLV
  4.2.  SR-ERO Subobject
    4.2.1.  Subobject Extension Block
    4.2.2.  Guidance for Future Extensions
  4.3.  SRv6-ERO Subobject
  4.4.  SR-Algorithm TLV
  4.5.  Extensions to METRIC Object
    4.5.1.  Path Min Delay Metric
    4.5.2.  Path Bandwidth Metric
    4.5.3.  User-Defined Metric
5.  Operation
  5.1.  ERO and RRO Subobjects
    5.1.1.  SR-ERO
    5.1.2.  SRv6-ERO
  5.2.  SR-Algorithm Constraint
    5.2.1.  Path Computation for SR-Algorithms 0-127
    5.2.2.  Path Computation for Flexible Algorithms
  5.3.  Metric Types
6.  Manageability Considerations
  6.1.  Control of Function and Policy
  6.2.  Information and Data Models
  6.3.  Liveness Detection and Monitoring
  6.4.  Verify Correct Operations
  6.5.  Requirements on Other Protocols and Functional Components
  6.6.  Impact on Network Operations
7.  Operational Considerations
8.  Security Considerations
9.  IANA Considerations
  9.1.  SR Capability Flag
  9.2.  SRv6 PCE Capability Flag
  9.3.  SR-ERO Flag
  9.4.  SRv6-ERO Flag
  9.5.  PCEP TLV Types
  9.6.  Metric Types
  9.7.  PCEP-Error Object
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🎀

okay so [RFC5440] describes PCEP, the protocol for chatting between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between a pair of PCEs 💖. then [RFC8664] and [RFC9603] add PCEP extensions for Segment Routing (SR) over MPLS and IPv6 data planes, respectively 🌸.

this doc takes PCEP further for SR Traffic Engineering (TE) ✨. it's all about Segment Identifiers (SIDs) and SR-Algorithms 🦋. an SR-Algorithm tied to a SID defines the path computation algorithm the IGPs use 🧚.

here are the PCEP extensions this doc specifies 👑:

Signaling SR-Algorithm in ERO and RRO 🫶: PCEP peers get mechanisms to swap info about the SR-Algorithm for each SID. this means extending SR-ERO, SR-RRO, SRv6-ERO, and SRv6-RRO subobjects to carry an Algorithm field. this doc updates [RFC8664] and [RFC9603] to make that encoding work 💅.
SR-Algorithm Constraint for Path Computation 🔥: there are mechanisms for signaling a specific SR-Algorithm as a constraint to the PCE for path computation. this includes a new SR-Algorithm TLV carried in the Label Switched Path Attributes (LSPA) object 🌈.
Extensions to METRIC object 📈: several new metric types are added to the METRIC object to support optimization metrics derived from Flexible Algorithm Definitions (FADs) during Flexible Algorithm path computation 🧚. these aren't limited to Flexible Algorithms, though. they can also be used with Label Switched Paths (LSPs) set up using different Path Setup Types (PSTs) 💜.

1.1. Requirements Language 🙈

the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💀.

2. Terminology 📖

this doc uses these terms from [RFC5440]: Explicit Route Object (ERO), Label Switched Path Attributes (LSPA), Path Computation Client (PCC), Path Computation Element (PCE), Path Computation Element Communication Protocol (PCEP), PCEP peer, PCEP speaker, Record Route Object (RRO), and Traffic Engineering Database (TED) 🌸.

it uses this term from [RFC3031]: Label Switched Path (LSP) 🦋.

it uses this term from [RFC9479] and [RFC9492]: Application-Specific Link Attributes (ASLA) ✨.

it uses these terms from [RFC8664]: Node or Adjacency Identifier (NAI) and Segment Routing Database (SR-DB) 🧚.

it uses these terms from [RFC9350]: Flexible Algorithm Definition (FAD) and winning FAD 👑.

quick history lesson 🎀: the base PCEP spec [RFC4655] originally defined the PCE architecture for MPLS and GMPLS networks, with LSPs set up using the RSVP-TE signaling protocol 💅. over time, more PSTs came along, like SRv6 [RFC9603] 🌈. the term "LSP" gets used a lot in PCEP specs, and in this doc it refers to a Candidate Path inside an SR Policy. that can be an SRv6 path, and it's still represented with the LSP object from [RFC8231] 🫶.

"extension block" is the term this doc uses for the extra bytes tacked onto the end of a PCEP object, which may or may not be there depending on whether a flag in that object is set 🔥.

these terms are used in this doc too 💖:

P2MP: Point-to-Multipoint 🌸
Subobject Extension Block: an optional, variable-length extension block for SR-ERO and SR-RRO subobjects, defined in Section 4.2.1 of this doc 🦋.
Subobject Extension Block Flag (SEBF): any flag in the Flags field of SR-ERO or SR-RRO subobjects that signals the matching field is encoded in the Subobject Extension Block ✨.

3. Motivation 🧠

okay real talk, existing PCEP specs don't have a way to explicitly signal and negotiate SR-Algorithm capabilities and constraints 😭. that limits how well PCEs can make smart path computation choices based on which SR-Algorithms the network supports and wants 🙈. and if a PCEP message didn't say anything about an SR-Algorithm, that implied no specific constraint, which effectively let SIDs be used with any SR-Algorithm 🌀.

the big reason for all this is so the PCE can use the path computation logic and topology info that IGPs derive, Flexible Algorithms included 🧚. lining up PCE path computation with these IGP algorithms means operators can get paths that match the underlying routing behavior, which can end up with segment lists that have fewer SIDs 📉. supporting SR-Algorithm constraints in PCE path computation also makes Flexible Algorithm paths easier to deploy and manage in multi-domain networks 🌈.

the PCE and the PCC can each compute SR-TE paths on their own, using different SR-Algorithms 🦋. that info has to be shared between PCEP peers for things like network monitoring and troubleshooting 💜. in setups with multiple PCEs, when a PCC gets a path from the primary PCE, it needs to be able to report the full path info, SR-Algorithm included, to a backup PCE 🫶. this matters a lot for high availability (HA) scenarios, so the backup PCE can correctly verify Prefix SIDs 🔥.

the new SR-Algorithm TLV inside the LSPA object lets operators specify SR-Algorithm constraints directly 👑. that means they can fine-tune path computations for specific needs, like low-latency paths ⚡.

being able to specify an SR-Algorithm per SID in ERO and RRO is super important for a few reasons, for example 💅:

SID types without an algorithm specified 🙈: some SID types, like Binding SIDs (BSIDs) [RFC8402], may not have an SR-Algorithm specified. it could be inaccurate to say a whole end-to-end path follows one specific algorithm if it includes a BSID from another policy 💀.

Note: in SRv6, the BSID can come from an algorithm-specific SRv6 Locator, which means the path to that BSID's PCC node follows that algorithm-specific path. however, the implicit algorithm of the BSID is independent of the SR-Algorithm used for the SR Policy associated with that BSID 🌸.

Topologies with two IGP domains 🌍: each one uses the same FAD but with different algorithm numbers 🧚.

4. Object Formats 🎀

4.1. OPEN Object 💖

(part 1 ends here, more coming in part 2 bestie 🦋✨)

4.1.1. SR PCE Capability Sub-TLV 🎀

Okay bestie, so the SR-PCE-CAPABILITY sub-TLV is defined in Section 4.1.2 of [RFC8664] and gets tucked inside the PATH-SETUP-TYPE-CAPABILITY TLV 💖

This doc adds one new flag to the SR-PCE-CAPABILITY Sub-TLV Flags field ✨

S (SR-Algorithm Capability), bit 5 🦋: when S is 1, the PCEP speaker is saying "I support" the Algorithm field and the Subobject Extension Block in the SR-ERO subobject (Section 4.2), plus the SR-Algorithm TLV (Section 4.4). That counts for LSPs set up with PST 1 (Segment Routing) [RFC8664]. It does not count for any other PSTs 🙅‍♀️. When S is 0, everything goes back to the old rules from before this extension existed 🌸

4.1.2. SRv6 PCE Capability Sub-TLV 🌈

The SRv6-PCE-CAPABILITY sub-TLV is defined in Section 4.1.1 of [RFC9603] and goes inside the PATH-SETUP-TYPE-CAPABILITY TLV, same as the last one 🧚

This doc adds another flag to the SRv6-PCE-CAPABILITY Sub-TLV Flags field:

SR-Algorithm Capability (S), bit 13 💜: when S is 1, the PCEP speaker is saying it supports the Algorithm field in the SRv6-ERO subobject (Section 4.3) and the SR-Algorithm TLV (Section 4.4). This applies to LSPs set up with PST 3 (SRv6) [RFC9603]. It doesn't apply to other PSTs 😤. When S is 0, we're back to the procedures from before this extension, no drama 💅

4.2. SR-ERO Subobject 🔥

Okay this is the big one, so get comfy 🫶 This doc updates the SR-ERO subobject format from Section 4.3.1 of [RFC8664] with a brand new optional, variable-length Subobject Extension Block field. It carries extra info like the Algorithm field, and it's built so we can add stuff later without breaking everything 🦋 There's also a new A flag in the Flags field, which you can see in Figure 1 👀

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|   Type=36   |     Length    |  NT   |     Flags   |A|F|S|C|M|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         SID (optional)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //                   NAI (variable, optional)                  //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //       Subobject Extension Block (variable, optional)        //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: SR-ERO Subobject Format

Here's the new flag in the Flags field:

A (SR-Algorithm Flag) 🌸: if a PCEP speaker sets this, the Subobject Extension Block MUST be included in the SR-ERO subobject (see Figure 1), along with the specified algorithm. The block's length is variable. You figure it out by subtracting the size of the fixed fields and any optional SID or NAI fields from the total subobject Length. The length of the Subobject Extension Block MUST always be a multiple of 4 bytes 📏 If this flag is 0, then one of two things is true:
- the Subobject Extension Block isn't included, and the processing in Section 5.2.1 of [RFC8664] applies, or
- the Subobject Extension Block is included (because some SEBF shows up in a future spec) and the Algorithm field MUST be ignored.

This doc also updates the SR-ERO subobject validation in Section 5.2.1 of [RFC8664]. It extends the existing checks to cover the Subobject Extension Block and the A flag, like this 🫶

On receiving an SR-ERO subobject, a PCC MUST validate that the Length field, S bit, F bit, A bit, NT field, and any present SEBFs are consistent, as follows:

If the Subobject Extension Block is included (aka if any SEBF, like A or some future flag, is set to 1), the length of the subobject MUST include the size of the entire Subobject Extension Block, as determined by the set of SEBFs.
- The minimum size of the Subobject Extension Block is 4 bytes when only a single SEBF (like A) is set. It can be longer (in multiples of 4 bytes) if more SEBFs are set and need more room 🍓
- The total subobject Length is the sum of the sizes of the fixed and optional fields (SID, NAI, etc.) plus the total size of the Subobject Extension Block that the set of SEBFs needs.
- The exact Length math for each NT, S, F, and set of SEBFs goes like this 🧮
  - If NT=0, the F bit MUST be 1, the S bit MUST be 0, and the Length MUST be 8 + the size of the Subobject Extension Block.
  - If NT=1, the F bit MUST be 0.
    - If the S bit is 1, the Length MUST be 8 + the size of the Subobject Extension Block.
    - If the S bit is 0, the Length MUST be 12 + the size of the Subobject Extension Block.
  - If NT=2, the F bit MUST be 0.
    - If the S bit is 1, the Length MUST be 20 + the size of the Subobject Extension Block.
    - If the S bit is 0, the Length MUST be 24 + the size of the Subobject Extension Block.
  - If NT=3, the F bit MUST be 0.
    - If the S bit is 1, the Length MUST be 12 + the size of the Subobject Extension Block.
    - If the S bit is 0, the Length MUST be 16 + the size of the Subobject Extension Block.
  - If NT=4, the F bit MUST be 0.
    - If the S bit is 1, the Length MUST be 36 + the size of the Subobject Extension Block.
    - If the S bit is 0, the Length MUST be 40 + the size of the Subobject Extension Block.
  - If NT=5, the F bit MUST be 0.
    - If the S bit is 1, the Length MUST be 20 + the size of the Subobject Extension Block.
    - If the S bit is 0, the Length MUST be 24 + the size of the Subobject Extension Block.
  - If NT=6, the F bit MUST be 0.
    - If the S bit is 1, the Length MUST be 44 + the size of the Subobject Extension Block.
    - If the S bit is 0, the Length MUST be 48 + the size of the Subobject Extension Block.
If no SEBF (including the A flag defined in this document) is set, the Length value MUST follow the requirements in Section 5.2.1 of [RFC8664]. 💖

4.2.1. Subobject Extension Block 🦋

The Subobject Extension Block is an optional, extensible field in the SR-ERO subobject ✨ It shows up when any SEBF is set in the subobject's Flags field. That could be the A flag from this doc, or a flag from some future spec.

Block length and presence, bestie 📏

If the A flag is set and no other SEBF is set, the block length MUST be 4.
The block length is at least 4 bytes when it's present.
The block length MUST always be a multiple of 4 bytes.
The block MUST be included if any SEBF is set in the Flags field.
Future extensions may define more SEBFs and matching fields, so the block can grow past the initial 4 bytes whenever it needs to 🌱

The first 4 bytes of the Subobject Extension Block look like Figure 2:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Unassigned                    |  Algorithm    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 2: Subobject Extension Block Format

Here's what those fields do 🫶

Unassigned (24 bits): this is reserved for future use. It MUST be set to zero when sending and ignored when receiving 🤫
Algorithm (8 bits): this is the SR-Algorithm value from the "IGP Algorithm Types" registry in the "Interior Gateway Protocol (IGP) Parameters" registry group (see [IANA-ALGORITHM-TYPES]) 🔥

Future extensions SHOULD first use the Unassigned part of the initial 4 bytes to carry new info 🧠 If they need more space, the Subobject Extension Block may be extended in 4-byte increments. Each of those extensions must get its own dedicated SEBF in the Flags field (kinda like the A flag), and must come with capability signaling in an appropriate capability sub-TLV. This spec doesn't lock in which sub-TLV to use. It could be the SR-PCE-CAPABILITY sub-TLV, the SRv6-PCE-CAPABILITY sub-TLV, or some other capability TLV, depending on the context. Interoperability procedures and the exact signaling for each new SEBF and its capability will be defined by future specs or procedures that describe those extensions 🌈

When receiving a Subobject Extension Block longer than 4 bytes, receivers that don't recognize, or haven't negotiated support for, the additional flags MUST ignore the unknown extra bytes beyond what this doc defines. 🙈

4.2.2. Guidance for Future Extensions 🧚

Future enhancements that extend the Subobject Extension Block must:

Define a new SEBF in the Flags field to indicate the presence of the new extension, and specify the matching capability signaling for it 💜
Specify which parts of the reserved/extension block are used, and how the block length is calculated when that extension is present 📐
Make sure the reserved bits in the initial 4 bytes get used when possible, and only extend the block when more space is truly necessary 🍓
Have future extensions define more SEBFs and matching fields, so the block can grow past the initial 4 bytes when needed 🌸

Example: a future extension that introduces a Z flag and a new Z field (8 bits) 🎀

If the A flag and/or the Z flag is set, the Subobject Extension Block is included. The Z field may use 8 bits of the reserved portion. A field only counts as valid if its matching flag is set. For example, if the Z flag is 1 but the A flag is 0, then the Z field is valid but the Algorithm field gets ignored 🙃
If more space past the initial 4 bytes is needed, the extension's document specifies the new block layout and total length. To keep parsing simple, if a flag for such an extension is set, the full extended block gets encoded, including the initial 4 bytes, even when the A flag is 0. ✨

4.3. SRv6-ERO Subobject ✨

Okay bestie, so this doc updates the SRv6-ERO subobject format from Section 4.3.1 of [RFC9603] 🎀 The Algorithm field gets carved out of the Reserved field, and there's a brand new A flag living in the existing Flags field. Figure 3 is the whole vibe 💅

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |L|  Type=40    |     Length    |   NT  |    Flags    |A|V|T|F|S|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Reserved   |   Algorithm   |        Endpoint Behavior      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                      SRv6 SID (optional)                      |
      |                           (128-bit)                           |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      //                    NAI (variable, optional)                 //
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     SID Structure (optional)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 3: SRv6-ERO Subobject Format

Flags field:

A (SR-Algorithm Flag): If set by a PCEP speaker, the Algorithm field is included in the SRv6-ERO subobject as specified in Figure 3. If this flag is set to 0, then the Algorithm field is absent and processing described in Section 5.2.1 of [RFC9603] applies. 🦋
Reserved (8 bits): It MUST be set to 0 while sending and ignored on receipt. 🫶
Algorithm (8 bits): The SR-Algorithm value from the "IGP Algorithm Types" registry of the "Interior Gateway Protocol (IGP) Parameters" registry group. 🌸

📝 Heads up, bestie: The Subobject Extension Block is applicable to the SRv6-ERO subobject but is not required by this specific specification as existing reserved space is used. When additional space is needed in the SRv6-ERO subobject, the future extensions SHOULD specify the usage of the Subobject Extension Block for the SRv6-ERO subobject. 🧚

4.4. SR-Algorithm TLV 🦋

Okay so a brand new TLV gets introduced for the LSPA object to carry the SR-Algorithm constraint (Section 5.2) 💖 This TLV MUST only be used when PST = 1 or 3 for SR-MPLS and SRv6, respectively. And only the first instance of this TLV MUST be processed. Any subsequent instances MUST be ignored. Not me being picky, just how it works 🙈

The format of the SR-Algorithm TLV looks like this:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Type=66               |            Length=4           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Reserved              |   Flags     |S|   Algorithm   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 4: SR-Algorithm TLV Format

Type (16 bits): 66 🍓
Length (16 bits): 4 🍓

The 32-bit value is formatted as follows. ✨

Reserved (16 bits): MUST be set to 0 by the sender and MUST be ignored by the receiver. Zero in, zero out, periodt 💅
Flags (8 bits): This document defines the following flag. The other flags MUST be set to 0 by the sender and MUST be ignored by the receiver.
- S (Strict): If set, the path computation at the PCE MUST fail if the specified SR-Algorithm constraint cannot be satisfied. If the S (Strict) bit is unset and the PCE is unable to compute a path that satisfies the specified SR-Algorithm constraint, the PCE MUST attempt to compute a path as if no SR-Algorithm constraint had been requested. This means the PCE may use any available SR-Algorithm for the computation, consistent with the default behavior in the absence of SR-Algorithm constraint. 👑
Algorithm (8 bits): The SR-Algorithm to be used during path computation (see Section 5.2). 🔥

4.5. Extensions to METRIC Object 🌈

The METRIC object is defined in Section 7.8 of [RFC5440]. This document adds some extra types for the METRIC object so you can encode optimization metric types derived from the FAD during Flexible Algorithm path computation (see Section 5.2.2). These new metric types were made for that use case, but they're not restricted to Flexible Algorithm path computation or to any specific PST, so they're giving versatile ✨

Here's the lineup:

T=22: Path Min Delay metric (Section 4.5.1.1)
T=23: P2MP Path Min Delay metric (Section 4.5.1.2)
T=24: Path Bandwidth metric (Section 4.5.2.1)
T=25: P2MP Path Bandwidth metric (Section 4.5.2.2)
T=128-255: User-defined metric (Section 4.5.3)

Here's the terminology we'll be using as we go, so you're not lost later 🧚

A network comprises a set of N links {Li, (i=1...N)}.
A path P of a point-to-point (P2P) LSP is a list of K links {Lpi,(i=1...K)}.
A P2MP tree T comprises a set of M destinations {Dest_j,(j=1...M)}.

4.5.1. Path Min Delay Metric 💜

[RFC7471] and [RFC8570] define the "Min/Max Unidirectional Link Delay" sub-TLV to advertise the link minimum and maximum delay in microseconds in a 24-bit field. 🕰️

[RFC5440] defines the METRIC object with a 32-bit metric value encoded in IEEE floating point format (see [IEEE.754.2019]).

The encoding for the Path Min Delay metric value is quantified in units of microseconds and encoded in IEEE floating point format.

For use in the PCEP METRIC object, the 24-bit unsigned integer delay value is converted to a 32-bit IEEE floating point value. This conversion follows the procedure specified in [IEEE.754.2019].

4.5.1.1. P2P Path Min Delay Metric 🎀

The minimum Link Delay metric is defined in [RFC7471] and [RFC8570] as "Min Unidirectional Link Delay". The Path Min Link Delay metric represents the measured minimum link delay value over a configurable interval.

The Path Min Delay metric type of the METRIC object in PCEP represents the sum of the Min Link Delay metric of all links along a P2P path.

A Min Link Delay metric of link L is denoted by D(L).
A Path Min Delay metric for the P2P path P = Sum {D(Lpi), (i=1...K)}.

4.5.1.2. P2MP Path Min Delay Metric 🌸

The P2MP Path Min Delay metric type of the METRIC object in PCEP encodes the Path Min Delay metric for the destination that observes the worst (i.e., highest value) delay metric among all destinations of the P2MP tree.

The P2P Path Min Delay metric of the path to destination Dest_j is denoted by PMDM(Dest_j).
The P2MP Path Min Delay metric for the P2MP tree T = Maximum{PMDM(Dest_j), (j=1...M)}.

4.5.2. Path Bandwidth Metric 🦋

Section 4 of [RFC9843] defines a new metric type, "Bandwidth metric", which may be advertised in their link metric advertisements.

When performing Flexible Algorithm path computation as described in Section 5.2.2, procedures described in Sections 4.1 and 5 from [RFC9843] MUST be followed with automatic metric calculation.

For path computations in contexts other than Flexible Algorithm (including PSTs other than 1 or 3 for SR-MPLS and SRv6, respectively), if the Generic Metric sub-TLV with the Bandwidth metric type is not advertised for a link, the PCE implementation MAY apply a local policy to derive a metric value (similar to the procedures in Sections 4.1.3 and 4.1.4 of [RFC9843]) or the link MAY be treated as if the metric value is unavailable (e.g., by using a default value). If the Bandwidth metric value is advertised for a link, the PCE MUST use the advertised value to compute the path metric in accordance with Sections 4.5.2.1 and 4.5.2.2.

The Path Bandwidth metric value is encoded in IEEE floating point format (see [IEEE.754.2019]).

For use in the PCEP METRIC object, the 24-bit unsigned integer delay value is converted to a 32-bit IEEE floating point value. This conversion follows the procedure specified in [IEEE.754.2019].

4.5.2.1. P2P Path Bandwidth Metric 💅

The Path Bandwidth metric type of the METRIC object in PCEP represents the sum of the Bandwidth metric of all links along a P2P path.

📝 Note: The link Bandwidth metric utilized in the formula may be the original metric advertised on the link, which may have a value inversely proportional to the link capacity.

A Bandwidth metric of link L is denoted by B(L).
A Path Bandwidth metric for the P2P path P = Sum {B(Lpi), (i=1...K)}.

4.5.2.2. P2MP Path Bandwidth Metric 🌈

The Bandwidth metric type of the METRIC object in PCEP encodes the Path Bandwidth metric for the destination that observes the worst Bandwidth metric among all destinations of the P2MP tree.

The P2P Bandwidth metric of the path to destination Dest_j is denoted by BM(Dest_j).
The P2MP Path Bandwidth metric for the P2MP tree T = Maximum{BM(Dest_j), (j=1...M)}.

4.5.3. User-Defined Metric 👑

Section 2 of [RFC9843] defined a new metric type range for "User-defined metric", which may be advertised in their link metric advertisements. These are user defined and can be assigned by an operator for local use.

User-defined metric values are encoded using the IEEE floating point format (see [IEEE.754.2019]).

For use in the PCEP METRIC object, the 24-bit unsigned integer delay value is converted to a 32-bit IEEE floating point value. This conversion follows the procedure specified in [IEEE.754.2019].

The metric type range was chosen to allow mapping with values assigned in the "IGP Metric-Type" registry. For example, the User-defined metric type 130 of the METRIC object in PCEP can represent the sum of the User-defined metric 130 of all links along a P2P path. 🧠

User-defined metrics are equally applicable to P2P and P2MP paths. 💖

5. Operation ⭐

Okay, this part is important, so listen up 👂 The PCEP extensions defined in Sections 5.1 and 5.2 of this document MUST NOT be used unless both PCEP speakers have indicated support by setting the S flag in the Path Setup Type sub-TLV corresponding to the PST of the LSP. If this condition is not met, the receiving PCEP speaker MUST respond with a PCErr message with Error-Type 19 (Invalid Operation) and Error-value 33 (Attempted use of SR-Algorithm without advertised capability). Not a vibe 💀

The SR-Algorithm used in this document refers to a complete range of SR-Algorithm values (0-255) if a specific section does not specify otherwise. Valid SR-Algorithm values are defined in the "IGP Algorithm Types" registry of the "Interior Gateway Protocol (IGP) Parameters" registry group. Refer to Section 3.1.1 of [RFC8402] and [RFC9256] for the definition of SR-Algorithm in SR. [RFC8665] and [RFC8667] describe the use of the SR-Algorithm in IGP. Note that some RFCs refer to SR-Algorithm with different names, for example, "Prefix-SID Algorithm" and "SR Algorithm". 🧚✨

5.1. ERO and RRO Subobjects ✨

okay so if a PCC gets the Algorithm field in the ERO subobject inside a PCInitiate, PCUpd, or PCRep message, and that path is getting copied into the ERO of a PCRpt message, then the PCC MUST include the Algorithm field in the encoded subobjects with that same received SR-Algorithm value 🫶

bestie, the SR-RRO subobject is basically the twin of the SR-ERO subobject per [RFC8664], just without the L flag 👯 so it can also carry the A flag and the Algorithm field in its Subobject Extension Block. Same vibe for the SRv6-RRO subobject per [RFC9603]: it matches the SRv6-ERO subobject minus the L flag, so it may also carry the A flag and Algorithm field 💜

5.1.1. SR-ERO 🎀

a PCEP speaker MAY set the A flag and include the Algorithm field as part of the Subobject Extension Block in an SR-ERO subobject, but only if both PCEP speakers advertised the S flag in the SR-PCE-CAPABILITY sub-TLV 🌸

if the PCEP peer gets an SR-ERO subobject with the A flag set but the S flag was never advertised in the SR-PCE-CAPABILITY sub-TLV, it MUST consider the entire ERO invalid, as described in Section 5.2.1 of [RFC8664]. big nope energy 💀

the Subobject Extension Block field in the SR-ERO subobject MUST be included after the optional SID, NAI, or SID structure, and the length of the SR-ERO subobject MUST be increased by the size of the Subobject Extension Block, as determined by the set of SEBFs ✨

if the length and the A flag don't agree, as specified in Section 4.2, the PCEP peer MUST consider the entire ERO invalid and MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 11 ("Malformed object") 😭

if the SID value is absent (S flag is set to 1), the NAI value is present (F flag is set to 0), and the Algorithm field is set (the A flag is set to 1), then the PCC is responsible for picking the SRv6-SID value based on the values in the NAI and Algorithm fields 🧚 if the PCC can't find a SID index in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 14 ("Unknown SID") 🙈

5.1.2. SRv6-ERO 🦋

a PCEP speaker MAY set the A flag and include the Algorithm field in an SRv6-ERO subobject, but only if both speakers advertised the S flag in the SRv6-PCE-CAPABILITY sub-TLV 🍓

if the PCEP peer gets an SRv6-ERO subobject with the A flag set or with the SR-Algorithm included, but the S flag was not advertised in the SRv6-PCE-CAPABILITY sub-TLV, it MUST consider the entire ERO invalid, as described in Section 5.2.1 of [RFC8664]. not it 💅

the Algorithm field in the SRv6-ERO subobject MUST be included in the position specified in Section 4.3, and the length of the SRv6-ERO subobject doesn't change just because the Algorithm field is there 🌈

if the SRv6-SID value is absent (S flag is set to 1), the NAI value is present (F flag is n), and the Algorithm field is set (the A flag is set to 1), the PCC is responsible for choosing the SRv6-SID value based on the values in the NAI and Algorithm fields. if the PCC can't find a SID index in the SR-DB, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 14 ("Unknown SID") 🫠

5.2. SR-Algorithm Constraint 👑

to tell the PCE about a specific SR-Algorithm constraint, the headend MUST encode the SR-Algorithm TLV inside the LSPA object 📣

if a PCC gets an LSPA object with the SR-Algorithm TLV as part of PCInitiate or PCUpd messages, then it MUST include an LSPA object with the SR-Algorithm TLV in a PCRpt message as part of the intended-attribute-list 🔥

if a PCE gets an LSPA object with the SR-Algorithm TLV in PCRpt or PCReq, then it MUST include the LSPA object with the SR-Algorithm TLV in a PCUpd message, or in a PCRep message if the path computation was unsuccessful, based on the rules in Section 7.11 of [RFC5440] ✨

a PCEP peer that did not advertise the S flag in the Path Setup Type sub-TLV for the LSP's PST MUST ignore the SR-Algorithm TLV on receipt 🙃

the PCE MUST NOT use Prefix SIDs associated with an SR-Algorithm other than the one in the SR-Algorithm constraint. if a protected Adjacency SID gets used without an associated SR-Algorithm, the backup path might fail to forward traffic over parts of the topology that aren't part of the specified SR-Algorithm 😱 so it is NOT RECOMMENDED to use protected Adjacency SIDs without an explicitly specified SR-Algorithm. if an Adjacency SID does have an associated SR-Algorithm, the PCE MUST ensure that it matches the one in the SR-Algorithm constraint 🧠

the SR-Algorithm constraint is the main thing here. protected Adjacency SIDs with no SR-Algorithm are a footgun, so keep that in mind 🚩

other SID types, like BSIDs, are allowed 🦋 and including a path BSID from another policy is only permitted if that policy's path fully satisfies all the constraints of the current path computation 💜

the SR-Algorithm constraint applies to the end-to-end SR Policy path. using different SR-Algorithm constraints, or using winning FADs with different optimization metrics or constraints for the same SR-Algorithm in each domain or part of the topology during a single path computation, is out of scope for this document 🌸

if the PCE can't find a path with the given SR-Algorithm constraint, doesn't support a combination of the specified constraints, or the FAD contains constraints, optimization metrics, or other attributes that the PCE doesn't support or recognize, then it MUST use an empty ERO in PCInitiate for LSP instantiation, a PCUpd message if an update is needed, or a NO-PATH object in PCRep to say it couldn't find a valid path 🥲

if the Algorithm field value is in the range 128-255, the PCE MUST perform path computation according to the Flexible Algorithm procedures in Section 5.2.2. otherwise, the PCE MUST adhere to the path computation procedures with SID filtering defined in Section 5.2.1 🎀

if the NO-PATH object is included in PCRep, then the PCE MAY include the SR-Algorithm TLV to indicate a constraint that couldn't be satisfied, as described in Section 7.5 of [RFC5440] 🫶

SR-Algorithm does not replace the objective function defined in [RFC5541] 💅

the SR-Algorithm constraint acts like a filter, limiting which SIDs can be used as a result of the path computation function. path computation is based on the optimization metric type and the constraints in the PCEP message the PCC sent 💖

this section only applies to SR-Algorithm values in the range 0-127. it doesn't apply to Flexible Algorithms (range 128-255), which are handled in Section 5.2.2 🌈 within the 0-127 range, the currently defined algorithms are 0 (Shortest Path First (SPF)) and 1 (Strict-SPF), as introduced in Section 3.1.1 of [RFC8402]. future algorithms defined in this range that don't need explicit PCEP extensions beyond the SR-Algorithm TLV may also use this SID filtering approach ✨

if a PCE implementation gets a request with an SR-Algorithm value in the 0-127 range that it doesn't support for path computation, it MUST reject the PCEP message and send a PCErr message with Error-Type 19 (Invalid Operation) and Error-value 34 (Unsupported combination of constraints) 💀

5.2.2. Path Computation for Flexible Algorithms 👑

this section only applies to the Flexible Algorithms range of SR-Algorithm values. the PCE does Flexible Algorithm path computation based on topology information stored in its TED [RFC5440]. the TED is expected to be filled with what it needs, including Flexible Algorithm Definitions (FADs), node participation, and ASLA-specific link attributes, through standard mechanisms such as IGPs with Traffic Engineering extensions or BGP - Link State (BGP-LS) [RFC9552] 🧠

the PCE must follow the IGP Flexible Algorithm path computation logic described in [RFC9350]. that includes doing the FAD selection as described in Section 5.3 of [RFC9350] and other sections, figuring out the topology for a specific Flexible Algorithm based on the FAD, the node participation (Section 11 of [RFC9350]), using ASLA-specific link attributes (Section 12 of [RFC9350]), and applying the other rules for Flexible Algorithm path calculation (Section 13 of [RFC9350]). [RFC9350] defines the base procedures for IGP Flexible Algorithms, and other documents like [RFC9843] extend them further, so a PCE implementation may need to support those IGP extensions if it wants to use specific constraints in the FAD 🫠 [RFC9917] created an IANA registry called "IGP Flex-Algorithm Path Computation Rules" <https://www.iana.org/assignments/igp-parameters> inside the "Interior Gateway Protocol (IGP) Parameters" registry group, with the ordered set of rules that MUST be used to prune links from the topology during Flexible Algorithm path computation 🌸

the PCE MUST optimize the computed path based on the metric type specified in the FAD. the optimization metric type included in PCEP messages from the PCC MUST be ignored 🙅‍♀️ the PCE MUST use the metric type from the FAD in messages sent to the PCC, unless that metric type isn't defined in PCEP or isn't supported by the PCEP peer. SID types other than Prefix SID (e.g., Adjacency or BSID) are allowed, but only from nodes participating in the specified SR-Algorithm 🦋

there are matching metric types in PCEP for the IGP and TE metrics from the FAD introduced in [RFC9350], but no matching metric types were defined for "Min Unidirectional Link Delay" from [RFC9350] or for "Bandwidth metric" and "User-defined metric" from [RFC9843]. Section 4.5 of this document introduces them 🎀 heads up: the "Path Bandwidth metric" is accumulative, and it's totally different from the BANDWIDTH object defined in [RFC5440] ⚠️

the PCE MUST use the constraints specified in the FAD, plus the constraints (except the optimization metric type) directly included in PCEP messages from the PCC. the PCE implementation MAY decide to ignore specific constraints it gets from the PCC, based on the existing processing rules for PCEP objects and TLVs, such as the P flag described in Section 7.2 of [RFC5440] and the processing rules in [RFC9753]. if the PCE doesn't support a specified combination of constraints, it MUST fail path computation and respond with a PCEP message: a PCInitiate or PCUpd message with an empty ERO, or a PCRep with a NO-PATH object 😤 the PCC MUST NOT include constraints from the FAD in the PCEP message sent to the PCE, since that can lead to undesired behavior in various cases. the PCE SHOULD NOT include constraints from the FAD in PCEP messages sent to the PCC 💜

the combinations of the constraints in the FAD and the constraints directly included in PCEP messages from the PCC might make it less likely that Flexible-Algorithm-specific Prefix SIDs represent an optimal path while satisfying all the specified constraints. as a result, a longer SID list may be needed for the computed path. adding more constraints on top of the FAD takes complex path computation and may reduce the benefit of this scheme 🥹

5.3. Metric Types 📏

okay so all the rules for handling the METRIC object in [RFC5440] and [RFC8233] apply to the metric types defined in this doc 💅 no need to reinvent the wheel, bestie 🛞

6. Manageability Considerations 🛠️

okay manageability time 🫶 all the manageability requirements and considerations listed in [RFC5440], [RFC8231], [RFC8664], and [RFC9603] apply to the PCEP extensions defined here. on top of that, the stuff in this section applies too ✨

6.1. Control of Function and Policy 🎛️

a PCE or PCC implementation MAY let you turn the capability of supporting the PCEP extensions from this doc on or off as part of global config. by default this capability SHOULD be enabled 💖

6.2. Information and Data Models 📊

an implementation SHOULD let the operator view this capability 👀 also, sections 4.1 and 4.1.1 of [RFC9826] should be extended to include the capabilities from sections 4.1.1 and 4.1.2 for the PCEP peer. it's giving organized data model energy 🗂️

6.3. Liveness Detection and Monitoring 💓

this doc doesn't define any new mechanism that impacts liveness detection and monitoring of PCEP. literally nothing new here, so chill 😌

6.4. Verify Correct Operations ✅

an implementation SHOULD also let the operator view FADs, which may be used in Flexible Algorithm path computation as defined in Section 5.2.2 🔍

an implementation SHOULD allow the operator to view nodes participating in the specified SR-Algorithm 🧚

6.5. Requirements on Other Protocols and Functional Components 🧩

this doc doesn't put new requirements on anyone 🙅‍♀️ but it does rely on the necessary IGP extensions. the IGP side is doing the heavy lifting here 💪

6.6. Impact on Network Operations 🌐

this doc inherits considerations from documents describing IGP Flexible Algorithm, for example [RFC9350] and [RFC9843]. the network ops girlies should go check those out 🫶

7. Operational Considerations 📋

this doc inherits operational considerations from documents describing IGP Flexible Algorithm, for example [RFC9350] and [RFC9843]. same energy as above, no cap 🌸

8. Security Considerations 🔐

⚠️ okay this section is SERIOUS bestie, read it carefully 😭

the security considerations described in [RFC5440], [RFC8231], [RFC8253], [RFC8281], [RFC8664], [RFC9603], and [RFC9350] apply to the extensions in this doc as well 🛡️

also note that this spec makes it possible for the PCE to compute paths based on Flexible-Algorithm-related topology attributes and on the metric type and constraints from the FAD. this creates extra vulnerabilities 💀 they're already described for path computation done by IGP, like in the Security Considerations section of [RFC9350], but they also apply to path computation done by the PCE. so, securing the PCEP session using Transport Layer Security (TLS) [RFC8253] [RFC9916] is RECOMMENDED, as per the recommendations and best current practices in [RFC9325]. protect that session, king/queen 👑🔥

9. IANA Considerations 🦋

9.1. SR Capability Flag 🏳️‍🌈

IANA maintains a registry named "SR Capability Flag Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of the SR-PCE-CAPABILITY sub-TLV. IANA has registered the following:

               +=====+=========================+===========+
               | Bit | Description             | Reference |
               +=====+=========================+===========+
               |  5  | SR-Algorithm Capability | RFC 9933  |
               +-----+-------------------------+-----------+

                                  Table 1

9.2. SRv6 PCE Capability Flag 💜

IANA maintains a registry named "SRv6 Capability Flag Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of SRv6-PCE-CAPABILITY sub-TLV. IANA has registered the following:

               +=====+=========================+===========+
               | Bit | Description             | Reference |
               +=====+=========================+===========+
               |  13 | SR-Algorithm Capability | RFC 9933  |
               +-----+-------------------------+-----------+

                                  Table 2

9.3. SR-ERO Flag 🎀

IANA maintains a registry named "SR-ERO Flag Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of the SR-ERO Subobject. IANA has registered the following:

                +=====+=======================+===========+
                | Bit | Description           | Reference |
                +=====+=======================+===========+
                |  7  | SR-Algorithm Flag (A) | RFC 9933  |
                +-----+-----------------------+-----------+

                                  Table 3

9.4. SRv6-ERO Flag 🌈

IANA maintains a registry named "SRv6-ERO Flag Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the Flags field of the SRv6-ERO subobject. IANA has registered the following:

                +=====+=======================+===========+
                | Bit | Description           | Reference |
                +=====+=======================+===========+
                |  7  | SR-Algorithm Flag (A) | RFC 9933  |
                +-----+-----------------------+-----------+

                                  Table 4

9.5. PCEP TLV Types 🍓

IANA maintains a registry named "PCEP TLV Type Indicators" within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA has registered the following TLV type for the new LSPA TLV specified in this document:

                   +=======+==============+===========+
                   | Value | Description  | Reference |
                   +=======+==============+===========+
                   |   66  | SR-Algorithm | RFC 9933  |
                   +-------+--------------+-----------+

                                 Table 5

9.6. Metric Types 📈

IANA maintains a registry named "METRIC Object T Field" within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA has registered these codepoints as follows:

           +=========+============================+===========+
           |  Value  | Description                | Reference |
           +=========+============================+===========+
           |    22   | Path Min Delay metric      | RFC 9933  |
           +---------+----------------------------+-----------+
           |    23   | P2MP Path Min Delay metric | RFC 9933  |
           +---------+----------------------------+-----------+
           |    24   | Path Bandwidth metric      | RFC 9933  |
           +---------+----------------------------+-----------+
           |    25   | P2MP Path Bandwidth metric | RFC 9933  |
           +---------+----------------------------+-----------+
           | 128-255 | User-defined metric        | RFC 9933  |
           +---------+----------------------------+-----------+

                                 Table 6

9.7. PCEP-Error Object 🚨

IANA has registered the following Error-Types and Error-values within the "PCEP-ERROR Object Error Types and Values" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group:

      +============+===========+=======================+===========+
      | Error-Type | Meaning   | Error-value           | Reference |
      +============+===========+=======================+===========+
      |     19     | Invalid   | 33: Attempted use of  | RFC 9933  |
      |            | Operation | SR-Algorithm without  |           |
      |            |           | advertised capability |           |
      +------------+-----------+-----------------------+-----------+
      |            |           | 34: Unsupported       | RFC 9933  |
      |            |           | combination of        |           |
      |            |           | constraints           |           |
      +------------+-----------+-----------------------+-----------+

                                 Table 7

10. References 📚

10.1. Normative References 📚✨

okay bestie, these are the normative refs, the ones you actually NEED to have read before any of this clicks 💅 every entry is copied exactly so you can look each one up 🔍

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
           Element (PCE) Communication Protocol (PCEP)", RFC 5440,
           DOI 10.17487/RFC5440, March 2009,
           <https://www.rfc-editor.org/info/rfc5440>.

[RFC7471]  Giacalone, S., Ward, D., Drake, J., Atlas, A., and S.
           Previdi, "OSPF Traffic Engineering (TE) Metric
           Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015,
           <https://www.rfc-editor.org/info/rfc7471>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
           Computation Element Communication Protocol (PCEP)
           Extensions for Stateful PCE", RFC 8231,
           DOI 10.17487/RFC8231, September 2017,
           <https://www.rfc-editor.org/info/rfc8231>.

[RFC8233]  Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki,
           "Extensions to the Path Computation Element Communication
           Protocol (PCEP) to Compute Service-Aware Label Switched
           Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September
           2017, <https://www.rfc-editor.org/info/rfc8233>.

[RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
           "PCEPS: Usage of TLS to Provide a Secure Transport for the
           Path Computation Element Communication Protocol (PCEP)",
           RFC 8253, DOI 10.17487/RFC8253, October 2017,
           <https://www.rfc-editor.org/info/rfc8253>.

[RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
           Computation Element Communication Protocol (PCEP)
           Extensions for PCE-Initiated LSP Setup in a Stateful PCE
           Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
           <https://www.rfc-editor.org/info/rfc8281>.

[RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
           Decraene, B., Litkowski, S., and R. Shakir, "Segment
           Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
           July 2018, <https://www.rfc-editor.org/info/rfc8402>.

[RFC8570]  Ginsberg, L., Ed., Previdi, S., Ed., Giacalone, S., Ward,
           D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE)
           Metric Extensions", RFC 8570, DOI 10.17487/RFC8570, March
           2019, <https://www.rfc-editor.org/info/rfc8570>.

[RFC8664]  Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
           and J. Hardwick, "Path Computation Element Communication
           Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
           DOI 10.17487/RFC8664, December 2019,
           <https://www.rfc-editor.org/info/rfc8664>.

[RFC8665]  Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
           H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
           Extensions for Segment Routing", RFC 8665,
           DOI 10.17487/RFC8665, December 2019,
           <https://www.rfc-editor.org/info/rfc8665>.

[RFC8667]  Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C.,
           Bashandy, A., Gredler, H., and B. Decraene, "IS-IS
           Extensions for Segment Routing", RFC 8667,
           DOI 10.17487/RFC8667, December 2019,
           <https://www.rfc-editor.org/info/rfc8667>.

[RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
           A., and P. Mattes, "Segment Routing Policy Architecture",
           RFC 9256, DOI 10.17487/RFC9256, July 2022,
           <https://www.rfc-editor.org/info/rfc9256>.

[RFC9350]  Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
           and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
           DOI 10.17487/RFC9350, February 2023,
           <https://www.rfc-editor.org/info/rfc9350>.

[RFC9603]  Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,
           and Y. Zhu, "Path Computation Element Communication
           Protocol (PCEP) Extensions for IPv6 Segment Routing",
           RFC 9603, DOI 10.17487/RFC9603, July 2024,
           <https://www.rfc-editor.org/info/rfc9603>.

[RFC9753]  Li, C., Zheng, H., and S. Litkowski, "Extension for
           Stateful PCE to Allow Optional Processing of Path
           Computation Element Communication Protocol (PCEP)
           Objects", RFC 9753, DOI 10.17487/RFC9753, April 2025,
           <https://www.rfc-editor.org/info/rfc9753>.

[RFC9843]  Hegde, S., Britto, W., Shetty, R., Decraene, B., Psenak,
           P., and T. Li, "IGP Flexible Algorithms: Bandwidth, Delay,
           Metrics, and Constraints", RFC 9843, DOI 10.17487/RFC9843,
           September 2025, <https://www.rfc-editor.org/info/rfc9843>.

[RFC9916]  Dhody, D., Turner, S., and R. Housley, "Updates to the
           Usage of TLS to Provide a Secure Transport for the Path
           Computation Element Communication Protocol (PCEP)",
           RFC 9916, DOI 10.17487/RFC9916, July 2026,
           <https://www.rfc-editor.org/info/rfc9916>.

[RFC9917]  Psenak, P., Horn, J., and A. Dhamija, "IGP Flexible
           Algorithms Reverse Affinity Constraint", RFC 9917,
           DOI 10.17487/RFC9917, January 2026,
           <https://www.rfc-editor.org/info/rfc9917>.

10.2. Informative References 🦋

these are the extra-helpful reads, the ones that give you the backstory and context without being strictly required 🌸

[IANA-ALGORITHM-TYPES]
           IANA, "IGP Algorithm Types",
           <https://www.iana.org/assignments/igp-parameters>.

[IEEE.754.2019]
           IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
           Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, July 2019,
           <https://doi.org/10.1109/IEEESTD.2019.8766229>.

[RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
           Label Switching Architecture", RFC 3031,
           DOI 10.17487/RFC3031, January 2001,
           <https://www.rfc-editor.org/info/rfc3031>.

[RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
           Computation Element (PCE)-Based Architecture", RFC 4655,
           DOI 10.17487/RFC4655, August 2006,
           <https://www.rfc-editor.org/info/rfc4655>.

[RFC5541]  Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of
           Objective Functions in the Path Computation Element
           Communication Protocol (PCEP)", RFC 5541,
           DOI 10.17487/RFC5541, June 2009,
           <https://www.rfc-editor.org/info/rfc5541>.

[RFC9325]  Sheffer, Y., Saint-Andre, P., and T. Fossati,
           "Recommendations for Secure Use of Transport Layer
           Security (TLS) and Datagram Transport Layer Security
           (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
           2022, <https://www.rfc-editor.org/info/rfc9325>.

[RFC9479]  Ginsberg, L., Psenak, P., Previdi, S., Henderickx, W., and
           J. Drake, "IS-IS Application-Specific Link Attributes",
           RFC 9479, DOI 10.17487/RFC9479, October 2023,
           <https://www.rfc-editor.org/info/rfc9479>.

[RFC9492]  Psenak, P., Ed., Ginsberg, L., Henderickx, W., Tantsura,
           J., and J. Drake, "OSPF Application-Specific Link
           Attributes", RFC 9492, DOI 10.17487/RFC9492, October 2023,
           <https://www.rfc-editor.org/info/rfc9492>.

[RFC9552]  Talaulikar, K., Ed., "Distribution of Link-State and
           Traffic Engineering Information Using BGP", RFC 9552,
           DOI 10.17487/RFC9552, December 2023,
           <https://www.rfc-editor.org/info/rfc9552>.

[RFC9826]  Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura,
           "A YANG Data Model for the Path Computation Element
           Communication Protocol (PCEP)", RFC 9826,
           DOI 10.17487/RFC9826, September 2025,
           <https://www.rfc-editor.org/info/rfc9826>.

Acknowledgements 🙏

huge thank you to Dhruv Dhody for shepherding this doc and for all his contributions and suggestions 🫶

the authors also want to thank Adrian Farrel, Aijun Wang, Alexey Melnikov, Boris Khasanov, Deb Cooley, Éric Vyncke, Gunter Van de Velde, Jie Dong, Ketan Talaulikar, Mahesh Jethanandani, Marina Fizgeer, Mike Bishop, Mohamed Boucadair, Nagendra Nainar, Rakesh Gandhi, Russ White, and Shraddha Hegde for reviewing and giving suggestions. the whole squad showed up 💅✨

Contributors 🎀

these are the contributors who helped build this 💖

Mike Koldychev
Ciena Corporation
Email: mkoldych@proton.me


Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com


Stephane Litkowski
Cisco Systems, Inc.
Email: slitkows.ietf@gmail.com


Siva Sivabalan
Ciena
Email: msiva282@gmail.com


Tarek Saad
Cisco Systems, Inc.
Email: tsaad.net@gmail.com


Mahendra Singh Negi
RtBrick Inc
Email: mahend.ietf@gmail.com


Tom Petch
Email: ietfc@btconnect.com

Authors' Addresses 🧚

and last but definitely not least, here's where to find the authors 🌈

Samuel Sidor
Cisco Systems, Inc.
Eurovea Central 3.
Pribinova 10
811 09 Bratislava
Slovakia
Email: ssidor@cisco.com


Zoey Rose
Cisco Systems, Inc.
2300 East President George
Richardson, TX 75082
United States of America
Email: atokar@cisco.com


Shaofu Peng
ZTE Corporation
No.50 Software Avenue
Nanjing
Jiangsu, 210012
China
Email: peng.shaofu@zte.com.cn


Shuping Peng
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: pengshuping@huawei.com


Andrew Stone
Nokia
Email: andrew.stone@nokia.com

📦 where this page comes from

ietf: rfc9933 2026-07
💖 girlified by claude-haiku-5-5 on 2026-10-19: a language model's rewrite of the original, under its terms

RFC 9933

📜 RFC 9933: Carrying SR-Algorithm in Path Computation Element Communication Protocol (PCEP) 🦋

Abstract ✨

Status of This Memo 📋

Copyright Notice 🌈

Table of Contents 🗺️

1. Introduction 🎀

1.1. Requirements Language 🙈

2. Terminology 📖

3. Motivation 🧠

4. Object Formats 🎀

4.1. OPEN Object 💖

4.1.1. SR PCE Capability Sub-TLV 🎀

4.1.2. SRv6 PCE Capability Sub-TLV 🌈

4.2. SR-ERO Subobject 🔥

4.2.1. Subobject Extension Block 🦋

4.2.2. Guidance for Future Extensions 🧚

4.3. SRv6-ERO Subobject ✨

4.4. SR-Algorithm TLV 🦋

4.5. Extensions to METRIC Object 🌈

4.5.1. Path Min Delay Metric 💜

4.5.1.1. P2P Path Min Delay Metric 🎀

4.5.1.2. P2MP Path Min Delay Metric 🌸

4.5.2. Path Bandwidth Metric 🦋

4.5.2.1. P2P Path Bandwidth Metric 💅

4.5.2.2. P2MP Path Bandwidth Metric 🌈

4.5.3. User-Defined Metric 👑

5. Operation ⭐

5.1. ERO and RRO Subobjects ✨

5.1.1. SR-ERO 🎀

5.1.2. SRv6-ERO 🦋

5.2. SR-Algorithm Constraint 👑

5.2.1. Path Computation for SR-Algorithms 0-127 🧚

5.2.2. Path Computation for Flexible Algorithms 👑

5.3. Metric Types 📏

6. Manageability Considerations 🛠️

6.1. Control of Function and Policy 🎛️

6.2. Information and Data Models 📊

6.3. Liveness Detection and Monitoring 💓

6.4. Verify Correct Operations ✅

6.5. Requirements on Other Protocols and Functional Components 🧩

6.6. Impact on Network Operations 🌐

7. Operational Considerations 📋

8. Security Considerations 🔐

9. IANA Considerations 🦋

9.1. SR Capability Flag 🏳️‍🌈

9.2. SRv6 PCE Capability Flag 💜

9.3. SR-ERO Flag 🎀

9.4. SRv6-ERO Flag 🌈

9.5. PCEP TLV Types 🍓

9.6. Metric Types 📈

9.7. PCEP-Error Object 🚨

10. References 📚

10.1. Normative References 📚✨

10.2. Informative References 🦋

Acknowledgements 🙏

Contributors 🎀

Authors' Addresses 🧚