RFC 9603

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

πŸ“… published July 2024, from ietf

πŸŽ€ RFC 9603: PCEP Extensions for IPv6 Segment Routing πŸŽ€

Okay bestie, let's get into it! πŸ’– This is the one that teaches PCEP how to handle SRv6 (Segment Routing over the IPv6 data plane) paths. Here's the title block so you know who wrote it and where it fits. ✨

Authors: ζŽε‘ˆ (C. Li), Ed. from Huawei Technologies, P. Kaladharan from RtBrick Inc, S. Sivabalan and M. Koldychev from Ciena Corporation, and Y. Zhu from China Telecom. 🫢

Category: Standards Track πŸ‘‘. It's an Internet Standards Track document, published by the IETF in July 2024 πŸ¦‹. The ISSN is 2070-1721.

It doesn't obsolete or update anything. It just builds new stuff on top of the existing PCEP SR work. πŸ’…

Abstract ✨

Segment Routing (SR) can steer packets through a network using either the IPv6 or MPLS data plane, using the source routing paradigm 🌈. An SR Path can come from an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE) 🧚.

Since SR works with both MPLS and IPv6, a PCE should be able to compute SR Paths for both. PCEP already has extensions and mechanisms for SR-MPLS. This document adds what's needed to support SR for the IPv6 data plane inside PCEP. It's giving completeness 😭πŸ”₯

Status of This Memo 🌸

This is an Internet Standards Track document. It's a product of the IETF, it represents the consensus of the IETF community, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). More on Internet Standards is in Section 2 of RFC 7841. Current status, errata, and feedback info live at https://www.rfc-editor.org/info/rfc9603.

Copyright Notice πŸ’œ

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication. Please review those carefully, because they describe your rights and restrictions. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and are provided without warranty as described in the Revised BSD License. πŸ™ˆ

Table of Contents 🧚

1.  Introduction
  1.1.  Requirements Language
2.  Terminology
3.  Overview of PCEP Operation in SRv6 Networks
  3.1.  Operation Overview
  3.2.  SRv6-Specific PCEP Message Extensions
4.  Object Formats
  4.1.  The OPEN Object
    4.1.1.  The SRv6 PCE Capability sub-TLV
  4.2.  The RP/SRP Object
  4.3.  ERO
    4.3.1.  SRv6-ERO Subobject
      4.3.1.1.  SID Structure
      4.3.1.2.  Order of the Optional Fields
  4.4.  RRO
    4.4.1.  SRv6-RRO Subobject
5.  Procedures
  5.1.  Exchanging the SRv6 Capability
  5.2.  ERO Processing
    5.2.1.  SRv6 ERO Validation
    5.2.2.  Interpreting the SRv6-ERO
  5.3.  RRO Processing
6.  Security Considerations
7.  Manageability Considerations
  7.1.  Control of Function and Policy
  7.2.  Information and Data Models
  7.3.  Liveness Detection and Monitoring
  7.4.  Verify Correct Operations
  7.5.  Requirements on Other Protocols
  7.6.  Impact on Network Operations
8.  IANA Considerations
  8.1.  PCEP ERO and RRO Subobjects
  8.2.  New SRv6-ERO NAI Type Registry
  8.3.  New SRv6-ERO Flag Registry
  8.4.  LSP-ERROR-CODE TLV
  8.5.  PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators
  8.6.  SRv6 PCE Capability Flags
  8.7.  New Path Setup Type
  8.8.  ERROR Objects
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction ✨

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. πŸŽ€

Okay so the intro is where the story starts. As defined in [RFC8402], Segment Routing (SR) lets the source node steer a packet through a path described by an ordered list of instructions, called "segments" πŸ¦‹. A segment can be topological or service based, and its meaning can be local to one SR node or global within the SR domain.

[RFC5440] describes PCEP for talking between a Path Computation Client (PCC) and a PCE, or between a pair of PCEs. A PCE, or a PCC acting as a PCE in a hierarchical PCE setup, computes paths for MPLS-TE LSPs based on constraints and optimization criteria 🌸.

[RFC8231] adds stateful PCE extensions that let a PCE compute and recommend network paths in compliance with [RFC4657], and defines objects and TLVs for MPLS-TE LSPs. These cover LSP state sync between PCC and PCE, LSP control delegation, LSP state reporting from PCC to PCE, and controlling LSP setup and routing from PCE to PCC. This model assumes LSPs are configured on the PCC, with control delegated to the PCE πŸ’œ.

[RFC8281] lets a stateful PCE, or a controller using one, dynamically initiate LSPs on a PCC 🧚. Per [RFC8664], a stateful PCE can compute one or more SR-TE paths while considering various constraints and objective functions. Once the path is computed, the stateful PCE can initiate an SR-TE path on a PCC using the PCEP extensions from [RFC8281] together with the SR-specific PCEP extensions from [RFC8664] ✨.

[RFC8664] covers PCEP extensions for an SR-TE LSP on the MPLS data plane. This document extends [RFC8664] to support SR for the IPv6 data plane. πŸ’– With these procedures, a PCC can request an SRv6 path from either a stateful or stateless PCE. This spec uses the PATH-SETUP-TYPE TLV and procedures from [RFC8408] 🫢.

Last bit of the intro: this spec gives a network controller (acting as a PCE) a way to instantiate candidate paths for an SR Policy onto a head-end node (acting as a PCC) using PCEP. For the SR Policy architecture, see [RFC9256], which covers both SR-MPLS and SRv6 πŸ’….

2. Terminology 🌈

This document uses these terms from [RFC5440]: PCC, PCE, PCEP, PCEP Peer.

It also uses these terms from [RFC8051]: Stateful PCE, Delegation.

Some more terms the doc uses:

  • MSD: Maximum SID Depth
  • PST: Path Setup Type
  • SR: Segment Routing
  • SID: Segment Identifier
  • SRv6: Segment Routing over IPv6 data plane
  • SRH: IPv6 Segment Routing Header [RFC8754]
  • SRv6 path: IPv6 Segment List (A list of IPv6 SIDs representing a path in IPv6 SR domain in the context of this document.)

Also, the term "LSP" used in the PCEP specs is equivalent to an SRv6 path (represented as a list of SRv6 segments) in the context of supporting SRv6 in PCEP. πŸ¦‹

3. Overview of PCEP Operation in SRv6 Networks 🧚

Basic PCEP operations are built on [RFC8664] 🌸.

In PCEP messages, route information is carried in the Explicit Route Object (ERO), which is a sequence of subobjects. [RFC8664] defined a new ERO subobject called "SR-ERO subobject" that can carry a SID plus the identity of the node or adjacency that the SID represents, for SR-MPLS. SR-capable PCEP speakers can generate and/or process that subobject. An ERO containing SR-ERO subobjects can be included in the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], the PCEP LSP Initiate Request message (PCInitiate) defined in [RFC8281], and the PCEP LSP Update Request (PCUpd) and PCEP LSP State Report (PCRpt) messages defined in [RFC8231]. [RFC8664] also defines a new Reported Route Object (RRO), called "SR-RRO", to represent the SID list that the PCC applied, which is the actual path the LSP takes in an SR-MPLS network πŸ’œ.

For SRv6, a path computed by a PCE can be represented as an ordered list of SRv6 segments. This document defines new subobjects "SRv6-ERO" and "SRv6-RRO" in the ERO and the RRO, respectively, to carry the SRv6 SID. SRv6-capable PCEP speakers MUST be able to generate and/or process these subobjects. πŸ”₯

When a PCEP session between a PCC and a PCE is set up, both speakers exchange capabilities to show they can support SRv6-specific functionality, as described in Section 4.1.1 ✨.

Here's the summary of what this document defines πŸ’…:

  • a new PCEP capability for SRv6,
  • a new subobject SRv6-ERO in ERO,
  • a new subobject SRv6-RRO in RRO, and
  • a new Path Setup type (PST) [RFC8408], carried in the PATH-SETUP-TYPE and PATH-SETUP-TYPE-CAPABILITY TLVs.

3.1. Operation Overview 🌈

In SR networks, an SR source node [RFC8754] steers a packet into an SR Policy, which results in a segment list πŸ¦‹.

When SR uses the IPv6 data plane (that's SRv6), the PCEP procedures and mechanisms get extended in this document πŸ’–.

This document describes the extension that adds SRv6 support to PCEP. A PCC or PCE shows it can support SRv6 during PCEP session initialization, through a new SRv6-PCE-CAPABILITY sub-TLV (more details in Section 4.1.1) 🫢.

3.2. SRv6-Specific PCEP Message Extensions 🧚

As defined in [RFC5440], a PCEP message is a common header followed by a variable-length body made of mandatory and/or optional objects. This document doesn't require any changes to the format of the PCReq and PCRep messages from [RFC5440], the PCInitiate message from [RFC8281], or the PCRpt and PCUpd messages from [RFC8231]. However, PCEP messages about SRv6 MUST include the PATH-SETUP-TYPE TLV in the Request Parameters (RP) or Stateful PCE Request Parameters (SRP) object, so it's clear that SRv6 is intended. πŸ‘‘

4. Object Formats πŸ’œ

4.1. The OPEN Object 🌸

(Part 1 ends here, bestie. Part 2 picks up with Section 4.1 and the SRv6 PCE Capability sub-TLV! πŸŽ€)

4.1.1. The SRv6 PCE Capability sub-TLV ✨

Okay bestie, this is where SRv6 finally gets its own seat at the PCEP table πŸ’… This document defines a new Path Setup Type (PST) [RFC8408] for SRv6, and it's PST=3, which just means "this path is set up using SRv6" πŸ¦‹

A PCEP speaker tells its friends it supports this function by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN object, with this new PST (value 3) included in the PST list 🫢

This document also defines the SRv6-PCE-CAPABILITY sub-TLV, which is how PCEP speakers swap info about their SRv6 capability 🌸 If a PCEP speaker includes PST=3 in the PST list of the PATH-SETUP-TYPE-CAPABILITY TLV, then it MUST also include the SRv6-PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY TLV. For further error handling, check out Section 5 πŸ”₯

Here's what the SRv6-PCE-CAPABILITY sub-TLV looks like:

    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=27            |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            Reserved           |             Flags         |N| |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   MSD-Type    | MSD-Value     |   MSD-Type    | MSD-Value     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                             ...                             //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   MSD-Type    | MSD-Value     |           Padding             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 1: SRv6-PCE-CAPABILITY Sub-TLV Format

The code point for the TLV type is 27, and the format follows the PCEP TLV format defined in [RFC5440] 🧚 So the sub-TLV is 2 octets for the type, 2 octets for the length, and then a Value field. When it's set to 27, the Type field identifies the SRv6-PCE-CAPABILITY sub-TLV, and just having it there tells everyone SRv6 paths are supported in PCEP ✨ The Length field gives the length of the value portion in octets. The sub-TLV gets padded to 4-octet alignment, but the padding is NOT counted in the Length field, so don't sneak it in there πŸ™ˆ The (MSD-Type,MSD-Value) pairs are OPTIONAL, and you can figure out how many pairs there are from the Length field of the TLV πŸ’œ

The value is made up of:

  • Reserved: 2 octets. This field MUST be set to 0 on transmission and ignored on receipt πŸ“
  • Flags: 2 octets. One bit is currently assigned in Section 8.6 🌈
    • N bit (bit position 14): A PCC sets this flag bit to 1 to indicate that it is capable of resolving a Node or Adjacency Identifier (NAI) to an SRv6-SID. Main character energy πŸ‘‘
    • Unassigned bits MUST be set to 0 on transmission and ignored on receipt 🫢
  • A pair of (MSD-Type,MSD-Value): MSD-Type (1 octet) is as per the IGP MSD Type registry created by [RFC8491] and populated with SRv6 MSD types as per [RFC9352]. MSD-Value (1 octet) is as per [RFC8491] πŸ’–

Now the tea β˜• The SRv6 MSD info advertised through the SRv6-PCE-CAPABILITY sub-TLV only tells you about the PCEP speaker's own capabilities. But when it comes to computing an SR Policy for the SRv6 data plane, the SRv6 MSD capabilities of the intermediate SRv6 Endpoint nodes and the tail-end node also matter. That's how you make sure the midpoints can process their segments and the tail-end can get rid of the SRv6 encapsulation 😭 The SRv6 MSD capabilities of other nodes might be learned from the topology info via the Border Gateway Protocol - Link State (BGP-LS) [RFC9514], or via PCEP if the PCE also happens to have PCEP sessions with those nodes πŸ¦‹

It is recommended that the SRv6 MSD info not be included in the SRv6-PCE-CAPABILITY sub-TLV in deployments where the PCE can get it through IGP/BGP-LS as part of the topology info. Not extra, just efficient πŸ’…

4.2. The RP/SRP Object

This document defines a new Path Setup Type (PST=3) for SRv6 🌸 To say "this path is for SRv6," any RP or SRP object MUST include the PATH-SETUP-TYPE TLV as specified in [RFC8408], with PST set to 3 πŸ’–

4.3. ERO

To support SRv6, there's a brand new "SRv6-ERO" subobject that can be included in the ERO 🧚

4.3.1. SRv6-ERO Subobject

An SRv6-ERO subobject is formatted as shown in Figure 2 πŸŽ€

    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     |V|T|F|S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Reserved         |      Endpoint Behavior        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                   SRv6 SID (conditional)                      |
   |                        (128-bit)                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                 NAI (variable, conditional)                 //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                  SID Structure (conditional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 2: SRv6-ERO Subobject Format

Here's the rundown on the fields in the SRv6-ERO subobject πŸ‘‘

  • The "L" flag: Tells you whether the subobject is a loose hop (see [RFC3209]). If this flag is set to zero, a PCC MUST NOT overwrite the SID value present in the SRv6-ERO subobject. Otherwise, a PCC MAY expand or replace one or more SID values in the received SRv6-ERO based on its local policy πŸ”₯
  • Type: Says what the subobject contains. When the field is set to 40, the subobject is an SRv6-ERO subobject representing an SRv6 SID πŸ¦‹
  • Length: The total length of the subobject in octets. The Length MUST be at least 24 and MUST be a multiple of 4. An SRv6-ERO subobject MUST contain at least one of an SRv6-SID or an NAI. The S and F bits in the Flags field indicate whether the SRv6-SID or NAI fields are absent 🫢
  • NAI Type (NT): Says what type and format of NAI is in the object body, if any are there. If the F bit is set to one (see below), then the NT field has no meaning and MUST be ignored by the receiver. This document creates a new PCEP SRv6-ERO NAI Types registry in Section 8.2 and allocates the following values:
    • If NT value is 0, the NAI MUST NOT be included.
    • When NT value is 2, the NAI is as per the "IPv6 node ID" format defined in [RFC8664], which specifies an IPv6 address. It's used to identify the owner of the SRv6 Identifier. This is optional, since the LOC (the locator portion) of the SRv6 SID serves a similar purpose (when present) 🌸
    • When NT value is 4, the NAI is as per the "IPv6 adjacency" format defined in [RFC8664], which specifies a pair of IPv6 addresses. It's used to identify the IPv6 adjacency and goes with the SRv6 Adj-SID πŸ’–
    • When NT value is 6, the NAI is as per the "link-local IPv6 addresses" format defined in [RFC8664], which specifies a pair of (global IPv6 address, interface ID) tuples. It's used to identify the IPv6 adjacency and goes with the SRv6 Adj-SID 🧚
  • Flags: Carries additional info about the SRv6-SID. This document defines the following flag bits. The other bits MUST be set to zero by the sender and MUST be ignored by the receiver. This document creates a new SRv6-ERO Flag Field registry in Section 8.3 and allocates the following values πŸŽ€
    • S: When this bit is set to 1, the SRv6-SID value in the subobject body is absent. In this case, the PCC is responsible for choosing the SRv6-SID value, e.g., by looking it up in the SR-DB using the NAI, which in this case MUST be present in the subobject. If the S bit is set to 1, then the F bit MUST be set to zero 😭
    • F: When this bit is set to 1, the NAI value in the subobject body is absent. The F bit MUST be set to 1 if NT=0; otherwise, it MUST be set to zero. The S and F bits MUST NOT both be set to 1 πŸ™ˆ
    • T: When this bit is set to 1, the SID Structure value in the subobject body is present. The T bit MUST be set to 0 when the S bit is set to 1. If the T bit is set when the S bit is set, the T bit MUST be ignored. So the T bit tells you whether an optional 8-byte SID Structure is there when an SRv6 SID is included. The SID Structure is defined in Section 4.3.1.1 πŸ’…
    • V: The "SID verification" bit is used as per Section 5.1 of [RFC9256]. If a PCC "Verification fails" for a SID, it MUST report this error by including the LSP-ERROR-CODE TLV with LSP Error-value "SID Verification fails" in the LSP object in the PCRpt message to the PCE 🚨
  • Reserved: MUST be set to zero while sending and ignored on receipt πŸ“
  • Endpoint Behavior: A 16-bit field representing the behavior associated with the SRv6 SIDs. This info is optional, but providing it is recommended whenever possible. It can help with maintainability and diagnostics. If the behavior is not known, the value 0xFFFF, as defined in the "SRv6 Endpoint Behaviors" registry, is used [RFC8986] 🌈
  • SRv6 SID: The SRv6 Identifier is a 128-bit value representing the SRv6 segment πŸ¦‹
  • NAI: The NAI associated with the SRv6-SID. The NAI's format depends on the value in the NT field and is described in [RFC8664] ✨

At least one SRv6-SID or the NAI MUST be included in the SRv6-ERO subobject, and both MAY be included πŸ’œ

4.3.1.1. SID Structure ✨

okay so the SID Structure is an optional extra bit tucked inside the SR-ERO subobject πŸŽ€, as covered in Section 4.3.1.

[RFC8986] says an SRv6 SID is built as LOC:FUNCT:ARG 🧚. The locator (LOC) sits in the L most significant bits, then F bits of function (FUNCT), then A bits of arguments (ARG). A locator can also be written as B:N, where B is the SRv6 SID locator block (an IPv6 prefix the operator hands out for SRv6 SIDs) and N is the ID of the parent node that instantiates the SID, called the "locator node" πŸ’….

The SID Structure looks like this in Figure 3 πŸ¦‹:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    LB Length  |  LN Length    | Fun. Length   |  Arg. Length  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Reserved                      |   Flags       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3: SID Structure Format

Here's the breakdown:

  • LB Length: 1 octet; SRv6 SID Locator Block length in bits
  • LN Length: 1 octet; SRv6 SID Locator Node length in bits
  • Fun. Length: 1 octet; SRv6 SID Function length in bits
  • Arg. Length: 1 octet; SRv6 SID Arguments length in bits

The four sizes added together must be less than or equal to 128 bits πŸ™ˆ. If they add up to more than 128 bits, the SRv6 SID is MUST-level invalid, so it MUST be treated as invalid, and a PCErr message comes back with Error-Type = 10 ("Reception of an invalid object") and Error-value = 37 ("Invalid SRv6 SID Structure"). Yikes 😭.

  • Reserved: MUST be set to zero while sending and ignored on receipt.
  • Flags: Currently no flags are defined.
  • Unassigned bits MUST be set to zero while sending and ignored on receipt.

Now the fun part 🌈. The SRv6 SID Structure gives the detailed encoding info for an SRv6 SID, which is super helpful when something needs to know the SID's shape. When a PCEP speaker gets the SID plus its structure info, it can parse the SID based on that structure and/or its local policies. The PCE can use the structure for ease of operations and monitoring, like checking that SIDs actually running in the network match the SID allocation scheme the operator picked, as described in Section 3.2 of [RFC8986]. Down the road, the PCE might even help verify and automate SRv6 domain security by provisioning filtering rules at the domain boundaries, as described in Section 5 of [RFC8754]. The details of those possible uses are outside the scope of this document πŸ“.

4.3.1.2. Order of the Optional Fields πŸ’œ

The optional elements in the SRv6-ERO subobject (the SRv6 SID, the NAI, and the SID Structure) MUST be encoded in the order shown in Figure 2 πŸ§šβ€β™€οΈ. You can tell whether each one is there by checking its flag: the S flag, F flag, or T flag.

For future-proofing, any new optional elements added to the SRv6-ERO subobject later must spell out their order and ask the Internet Assigned Numbers Authority (IANA) to allocate a flag for them from the subregistry created in Section 8.3 🌸.

4.4. RRO πŸ¦‹

To support SRv6, there's a brand new "SRv6-RRO" subobject that can be included in the RRO ✨.

4.4.1. SRv6-RRO Subobject πŸ’…

A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per [RFC8231] πŸ“¨. The RRO on that message shows the SID list the PCC actually applied, which is the real path that was taken. The [RFC8664] procedures for the RRO apply to this spec as well, with no changes at all 🫢.

An RRO holds one or more subobjects called "SRv6-RRO subobjects", and they look like this in Figure 4 πŸŽ€:

    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=40     |     Length    |  NT   |     Flags     |V|T|F|S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Reserved         |      Endpoint Behavior        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                      SRv6 SID(optional)                       |
   |                           (128-bit)                           |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   //                    NAI (variable)                           //
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                     SID Structure (optional)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 4: SRv6-RRO Subobject Format

The SRv6-RRO subobject has the same format as the SRv6-ERO subobject, just without the L flag 🌈.

The V flag means nothing in the SRv6-RRO, and the PCE just ignores it on receipt πŸ™ˆ.

PCCs order SRv6-RRO subobjects in a PCRpt message exactly as [RFC8664] says, and that doesn't change πŸ’œ.

The optional elements in the SRv6-RRO subobject follow the same order described in Section 4.3.1.2 πŸ“.

5. Procedures πŸ‘‘

5.1. Exchanging the SRv6 Capability 🧚

Here's how the SRv6 capability gets shared πŸ’–. A PCC says it can handle the head-end functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in the Open message it sends to a PCE. A PCE says it can compute SRv6 paths by putting the SRv6-PCE-CAPABILITY sub-TLV in the Open message it sends to a PCC ✨.

If a PCEP speaker gets a PATH-SETUP-TYPE-CAPABILITY TLV whose PST list contains PST=3, but the SRv6-PCE-CAPABILITY sub-TLV is missing, then the PCEP speaker MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-Value = 34 ("Missing PCE-SRv6-CAPABILITY sub-TLV"), and then MUST close the PCEP session πŸ’€. If a PCEP speaker gets a PATH-SETUP-TYPE-CAPABILITY TLV with an SRv6-PCE-CAPABILITY sub-TLV, but the PST list doesn't contain PST=3, then the PCEP speaker MUST ignore the SRv6-PCE-CAPABILITY sub-TLV πŸ™ˆ.

If the MSD-Type in the SRv6-PCE-CAPABILITY sub-TLV that a PCE receives isn't one of the SRv6 MSD types, the PCE MUST respond with a PCErr message (Error-Type = 1 ("PCEP session establishment failure") and Error-Value = 1 ("reception of an invalid Open message or a non Open message.")) 😀.

Quick heads-up: the (MSD-Type,MSD-Value) pair exchanged through the SRv6-PCE-CAPABILITY sub-TLV only tells you the SRv6 SID imposition limit for the sender PCC node. If a PCE learns these values some other way, like routing protocols ([RFC9352]), then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV 🧠. And if a PCE learns any other SRv6 MSD types that get defined in the future through other mechanisms, it MUST use those values, no matter what was exchanged in the SRv6-PCE-CAPABILITY sub-TLV 🫢.

During path computation, a PCE must look at the MSD info for every node along the path, not just the ingress PCC's MSD πŸ‘€. Why? A packet can get dropped on any node in the forwarding path if its SID depth goes over that node's MSD. The MSD capabilities of all SR nodes along the path can be learned as part of the topology info via IGP/BGP-LS, or via PCEP if the PCE happens to have PCEP sessions with those nodes 🌸.

A PCE MUST NOT send SRv6 paths that go over the SRv6 MSD capabilities of the PCC 🚫. If a PCC needs to change the SRv6 MSD value it signaled in the Open message, it MUST close the PCEP session and re-establish it with the new value πŸ”„. If the PCC gets an SRv6 path that goes over its SRv6 MSD capabilities, the PCC MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 40 ("Unsupported number of SRv6-ERO subobjects") 😭.

The N flag and the (MSD-Type,MSD-Value) pair inside the SRv6-PCE-CAPABILITY sub-TLV only mean something in the Open message sent to a PCE πŸ’–. So the flags MUST be set to zero, and a (MSD-Type,MSD-Value) pair MUST NOT be present in the SRv6-PCE-CAPABILITY sub-TLV in an Open message sent to a PCC. Similarly, a PCC MUST ignore the flags and any (MSD-Type,MSD-Value) pair in a received Open message. And if a PCE gets multiple SRv6-PCE-CAPABILITY sub-TLVs in one Open message, it only processes the first one it receives πŸ₯Ή.

5.2. ERO Processing πŸ’…

ERO processing stays exactly the same, in line with both [RFC5440] and [RFC8664] ✨.

5.2.1. SRv6 ERO Validation πŸ’…

Okay so if a PCC doesn't support the SRv6 PCE Capability and can't recognize the SRv6-ERO or SRv6-RRO subobjects, it should respond according to the rules for a malformed object in [RFC5440]. πŸ™ˆ

When a PCC gets an SRv6-ERO, it MUST check that the Length field, the S bit, the F bit, the T bit, and the NT field all match up, like this:

  • If NT=0, the F bit MUST be 1, the S bit MUST be zero, and the Length MUST be 24.
  • If NT=2, the F bit MUST be zero. If the S bit is 1, the Length MUST be 24; otherwise, the Length MUST be 40.
  • If NT=4, the F bit MUST be zero. If the S bit is 1, the Length MUST be 40; otherwise, the Length MUST be 56.
  • If NT=6, the F bit MUST be zero. If the S bit is 1, the Length MUST be 48; otherwise, the Length MUST be 64.
  • If the T bit is 1, then the S bit MUST be zero.

If a PCC finds that the NT field, Length field, S bit, F bit, and T bit don't line up, it 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 a PCC doesn't recognize or support the value in the NT field, it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 41 ("Unsupported NAI Type in the SRv6-ERO/SRv6-RRO subobject"). πŸ’€

If a PCC receives an SRv6-ERO subobject where the S and F bits are both set to 1 (so both the SID and NAI are absent), it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 42 ("Both SID and NAI are absent in the SRv6-ERO subobject"). 🚫

If a PCC receives an SRv6-ERO subobject where the S bit is set to 1 and the F bit is set to zero (so the SID is absent and the NAI is present), but the PCC doesn't support NAI resolution, it MUST consider the entire ERO invalid and send a PCErr message with Error-Type = 4 ("Not supported object") and Error-value = 4 ("Unsupported parameter"). 🧐

If a PCC detects that the subobjects of an ERO are a mix of SRv6-ERO subobjects and subobjects of other types, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 43 ("ERO mixes SRv6-ERO subobjects with other subobject types"). πŸŒ€

In case a PCEP speaker receives an SRv6-ERO subobject when the PST is not set to 3 or the SRv6-PCE-CAPABILITY sub-TLV was not exchanged, it MUST send a PCErr message with Error-Type = 19 ("Invalid Operation") and Error-value = 19 ("Attempted SRv6 when the capability was not advertised"). Not allowed, no cap! 🚨

If a PCC receives an SRv6 path that exceeds the SRv6 MSD capabilities, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 40 ("Unsupported number of SRv6-ERO subobjects") as per [RFC8664]. πŸ“

5.2.2. Interpreting the SRv6-ERO πŸ—ΊοΈ

The SRv6-ERO holds a sequence of subobjects. According to [RFC9256], each SRv6-ERO subobject in the sequence identifies a segment that the traffic will be directed to, and they're read in the order given. So the first subobject is the first segment the traffic goes to, the second SRv6-ERO subobject is the second segment, and so on. It's giving step-by-step directions. 🧭

5.3. RRO Processing πŸ¦‹

The syntax-checking rules for the SRv6-RRO subobject are identical to the ones for the SRv6-ERO subobject, except as noted below. ✨

If a PCEP speaker receives an SRv6-RRO subobject where both the SRv6 SID and NAI are absent, it MUST consider the entire RRO invalid and send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 35 ("Both SID and NAI are absent in SRv6-RRO subobject"). πŸ™…β€β™€οΈ

If a PCE detects that the subobjects of an RRO are a mix of SRv6-RRO subobjects and subobjects of other types, it MUST send a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = 36 ("RRO mixes SRv6-RRO subobjects with other subobject types"). πŸ“

The way the PCC learns the path is outside the scope of this document. πŸ€·β€β™€οΈ

6. Security Considerations πŸ”

The Security Considerations described in [RFC5440], Section 2.5 of [RFC6952], [RFC8231], [RFC8281], [RFC8253], and [RFC8664] apply to this specification. πŸ›‘οΈ

Here's the big deal, bestie. This specification lets a network controller instantiate an SRv6 path in the network. That creates an extra vulnerability if the security mechanisms of [RFC5440], [RFC8231], and [RFC8281] aren't used. If there's no integrity protection on the session, an attacker could create an SRv6 path that may not be subjected to the further verification checks. Scary stuff! 😱

Also, the MSD field in the Open message could disclose node forwarding capabilities if suitable security mechanisms aren't in place. So, securing the PCEP session using Transport Layer Security (TLS) [RFC8253] is RECOMMENDED. Protect your session, babe. πŸ”’πŸ’œ

7. Manageability Considerations πŸ› οΈ

All manageability requirements and considerations listed in [RFC5440], [RFC8231], [RFC8281], and [RFC8664] apply to the PCEP protocol extensions defined in this document. On top of that, the requirements and considerations in this section apply too. πŸŽ€

7.1. Control of Function and Policy πŸŽ›οΈ

A PCEP implementation SHOULD allow the operator to configure the SRv6 capability. Also, a policy to accept NAI only for the SRv6 SHOULD be allowed to be set. Operator control, yes queen. πŸ‘‘

7.2. Information and Data Models πŸ“š

The PCEP YANG module is out of the scope of this document. It's defined in other documents, for example, [PCEP-YANG]. An augmented YANG module for SRv6 is also specified in [PCEP-SRv6-YANG], which allows for SRv6 capability and MSD configurations and lets you monitor the SRv6 paths set in the network. 🌈

7.3. Liveness Detection and Monitoring πŸ’“

The mechanisms defined in this document don't imply any new liveness detection and monitoring requirements beyond the ones already listed in [RFC5440]. Nothing extra to see here. πŸ₯±

7.4. Verify Correct Operations βœ…

Verifying the mechanisms defined in this document can be built on the ones already listed in [RFC5440], [RFC8231], and [RFC8664]. Build on what's already there, periodt. 🧱

7.5. Requirements on Other Protocols 🀝

The mechanisms defined in this document don't imply any new requirements on other protocols. No drama with the neighbours. 🫢

7.6. Impact on Network Operations 🌐

The mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also apply to the PCEP extensions defined in this document. ⭐

8. IANA Considerations πŸ“

8.1. PCEP ERO and RRO Subobjects 🧩

This document defines a new subobject type for the PCEP Explicit Route Object (ERO) and a new subobject type for the PCEP Reported Route Object (RRO). These have been registered in the "Resource Reservation Protocol (RSVP) Parameters" registry group, as shown below. πŸ¦„

IANA has allocated the following new subobject in the "Subobject type - 20 EXPLICIT_ROUTE - Type 1 Explicit Route" registry:

                 +=======+==========================+
                 | Value | Description              |
                 +=======+==========================+
                 | 40    | SRv6-ERO (PCEP-specific) |
                 +-------+--------------------------+

                               Table 1

IANA has allocated the following new subobject in the "Subobject type - 21 ROUTE_RECORD - Type 1 Route Record" registry:

                 +=======+==========================+
                 | Value | Description              |
                 +=======+==========================+
                 | 40    | SRv6-RRO (PCEP-specific) |
                 +-------+--------------------------+

                               Table 2

8.2. New SRv6-ERO NAI Type Registry πŸ†•

IANA has created the "PCEP SRv6-ERO NAI Types" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the 4-bit NT field in the SRv6-ERO subobject. The registration policy is IETF Review [RFC8126]. IANA has registered the values in Table 3. πŸ“‹

         +=======+===============================+===========+
         | Value | Description                   | Reference |
         +=======+===============================+===========+
         | 0     | NAI is absent.                | RFC 9603  |
         +-------+-------------------------------+-----------+
         | 2     | NAI is an IPv6 node ID.       | RFC 9603  |
         +-------+-------------------------------+-----------+
         | 4     | NAI is an IPv6 adjacency with | RFC 9603  |
         |       | global IPv6 addresses.        |           |
         +-------+-------------------------------+-----------+
         | 6     | NAI is an IPv6 adjacency with | RFC 9603  |
         |       | link-local IPv6 addresses.    |           |
         +-------+-------------------------------+-----------+

                                Table 3

8.3. New SRv6-ERO Flag Registry 🚩

IANA has created the "SRv6-ERO Flag Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the 12-bit Flag field of the SRv6-ERO subobject. New values are to be assigned by Standards Action [RFC8126]. Each registration should include the following information:

  • Bit (counting from bit 0 as the most significant bit)
  • Description
  • Reference

The following values are defined in this document:

          +=====+==============================+===========+
          | Bit | Description                  | Reference |
          +=====+==============================+===========+
          | 8   | SID Verification (V)         | RFC 9603  |
          +-----+------------------------------+-----------+
          | 9   | SID Structure is present (T) | RFC 9603  |
          +-----+------------------------------+-----------+
          | 10  | NAI is absent (F)            | RFC 9603  |
          +-----+------------------------------+-----------+
          | 11  | SID is absent (S)            | RFC 9603  |
          +-----+------------------------------+-----------+

                               Table 4

8.4. LSP-ERROR-CODE TLV 🧾

This document defines a new value in the "LSP-ERROR-CODE TLV Error Code Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group.

            +=======+========================+===========+
            | Value | Meaning                | Reference |
            +=======+========================+===========+
            | 10    | SID Verification fails | RFC 9603  |
            +-------+------------------------+-----------+

                               Table 5

8.5. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators πŸ”’

IANA maintains the "PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group to manage the type indicator space for sub-TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA has registered the following value:

              +=======+=====================+===========+
              | Value | Meaning             | Reference |
              +=======+=====================+===========+
              | 27    | SRv6-PCE-CAPABILITY | RFC 9603  |
              +-------+---------------------+-----------+

                               Table 6

8.6. SRv6 PCE Capability Flags ✨

okay so IANA made a new registry called "SRv6 Capability Flag Field" πŸŽ€ inside the "Path Computation Element Protocol (PCEP) Numbers" group, and it's where the 16-bit Flag field of the SRv6-PCE-CAPABILITY sub-TLV gets managed πŸ’…. New values are assigned by Standards Action [RFC8126]. Every registration needs three things: the bit (counting from bit 0 as the most significant bit) πŸ¦‹, a description 🌸, and a reference πŸ’œ.

this document only defines one value, and it's bit 14 for the Node or Adjacency Identifier (NAI) is supported (N) flag πŸ”₯ 🫢

    +=====+==============================+===========+
    | Bit | Description                  | Reference |
    +=====+==============================+===========+
    | 14  | Node or Adjacency Identifier | RFC 9603  |
    |     | (NAI) is supported (N)       |           |
    +-----+------------------------------+-----------+

                         Table 7

8.7. New Path Setup Type 🌈

[RFC8408] made the "PCEP Path Setup Types" registry inside the "Path Computation Element Protocol (PCEP) Numbers" group ✨, and IANA has now allocated the value below πŸ’–

    +=======+==========================+===========+
    | Value | Description              | Reference |
    +=======+==========================+===========+
    | 3     | Traffic engineering path | RFC 9603  |
    |       | is set up using SRv6.    |           |
    +-------+--------------------------+-----------+

                         Table 8

8.8. ERROR Objects πŸ™ˆ

IANA allocated some Error-values in the "PCEP-ERROR Object Error Types and Values" registry, which lives in the "Path Computation Element Protocol (PCEP) Numbers" group. The full list is below, and it's a lot 😭

+============+=================+===================================+
| Error-Type | Meaning         | Error-value                       |
+============+=================+===================================+
| 10         | Reception of an | 34: Missing PCE-SRv6-CAPABILITY   |
|            | invalid object  | sub-TLV                           |
|            |                 +-----------------------------------+
|            |                 | 35: Both SID and NAI are absent   |
|            |                 | in SRv6-RRO subobject             |
|            |                 +-----------------------------------+
|            |                 | 36: RRO mixes SRv6-RRO subobjects |
|            |                 | with other subobject types        |
|            |                 +-----------------------------------+
|            |                 | 37: Invalid SRv6 SID Structure    |
|            |                 +-----------------------------------+
|            |                 | 40: Unsupported number of         |
|            |                 | SRv6-ERO subobjects               |
|            |                 +-----------------------------------+
|            |                 | 41: Unsupported NAI Type in the   |
|            |                 | SRv6-ERO/SRv6-RRO subobject       |
|            |                 +-----------------------------------+
|            |                 | 42: Both SID and NAI are absent   |
|            |                 | in the SRv6-ERO subobject         |
|            |                 +-----------------------------------+
|            |                 | 43: ERO mixes SRv6-ERO subobjects |
|            |                 | with other subobject types        |
+------------+-----------------+-----------------------------------+
| 19         | Invalid         | 19: Attempted SRv6 when the       |
|            | Operation       | capability was not advertised     |
+------------+-----------------+-----------------------------------+

                         Table 9

9. References πŸ“š

9.1. Normative References πŸ’œ

[RFC3209]  Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
           and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
           Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001,
           <https://www.rfc-editor.org/info/rfc3209>.

[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>.

[RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
           Writing an IANA Considerations Section in RFCs", BCP 26,
           RFC 8126, DOI 10.17487/RFC8126, June 2017,
           <https://www.rfc-editor.org/info/rfc8126>.

[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>.

[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>.

[RFC8408]  Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
           Hardwick, "Conveying Path Setup Type in PCE Communication
           Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
           July 2018, <https://www.rfc-editor.org/info/rfc8408>.

[RFC8491]  Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg,
           "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491,
           DOI 10.17487/RFC8491, November 2018,
           <https://www.rfc-editor.org/info/rfc8491>.

[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>.

[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>.

[RFC8986]  Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
           D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
           (SRv6) Network Programming", RFC 8986,
           DOI 10.17487/RFC8986, February 2021,
           <https://www.rfc-editor.org/info/rfc8986>.

[RFC9514]  Dawra, G., Filsfils, C., Talaulikar, K., Ed., Chen, M.,
           Bernier, D., and B. Decraene, "Border Gateway Protocol -
           Link State (BGP-LS) Extensions for Segment Routing over
           IPv6 (SRv6)", RFC 9514, DOI 10.17487/RFC9514, December
           2023, <https://www.rfc-editor.org/info/rfc9514>.

[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>.

[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>.

9.2. Informative References πŸ¦‹

[RFC4657]  Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation
           Element (PCE) Communication Protocol Generic
           Requirements", RFC 4657, DOI 10.17487/RFC4657, September
           2006, <https://www.rfc-editor.org/info/rfc4657>.

[RFC6952]  Jethanandani, M., Patel, K., and L. Zheng, "Analysis of
           BGP, LDP, PCEP, and MSDP Issues According to the Keying
           and Authentication for Routing Protocols (KARP) Design
           Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013,
           <https://www.rfc-editor.org/info/rfc6952>.

[RFC8051]  Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
           Stateful Path Computation Element (PCE)", RFC 8051,
           DOI 10.17487/RFC8051, January 2017,
           <https://www.rfc-editor.org/info/rfc8051>.

[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>.

[RFC8754]  Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
           Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
           (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
           <https://www.rfc-editor.org/info/rfc8754>.

[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>.

[RFC9352]  Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B.,
           and Z. Hu, "IS-IS Extensions to Support Segment Routing
           over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352,
           February 2023, <https://www.rfc-editor.org/info/rfc9352>.

[PCEP-YANG]
           Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura,
           "A YANG Data Model for Path Computation Element
           Communications Protocol (PCEP)", Work in Progress,
           Internet-Draft, draft-ietf-pce-pcep-yang-25, 21 May 2024,
           <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
           pcep-yang-25>.

[PCEP-SRv6-YANG]
           Li, C., Sivabalan, S., Peng, S., Koldychev, M., and L.
           Ndifor, "A YANG Data Model for Segment Routing (SR) Policy
           and SR in IPv6 (SRv6) support in Path Computation Element
           Communications Protocol (PCEP)", Work in Progress,
           Internet-Draft, draft-ietf-pce-pcep-srv6-yang-05, 18 March
           2024, <https://datatracker.ietf.org/doc/html/draft-ietf-
           pce-pcep-srv6-yang-05>.

Acknowledgements 🫢

The authors would like to thank Jeff Tantsura, Adrian Farrel, Aijun Wang, Khasanov Boris, Ketan Talaulikar, Martin Vigoureux, Hariharan Ananthakrishnan, Xinyue Zhang, John Scudder, Julien Meuric, and Robert Varga for valuable suggestions πŸ’–

Thanks to Gunter Van de Velde, Γ‰ric Vyncke, Jim Guichard, and Mahesh Jethanandani for their comments during the IESG review ✨

Contributors πŸ‘‘

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


Dhruv Dhody
Huawei
India
Email: dhruv.ietf@gmail.com


Huang Wumin
Huawei Technologies
Huawei Building, No. 156 Beiqing Rd.
Beijing
100095
China
Email: huangwumin@huawei.com


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


Ran Chen
ZTE Corporation
China
Email: chen.ran@zte.com.cn

Authors' Addresses πŸ¦‹

Okay bestie, here are the humans who wrote this whole thing and where you can find them πŸ’–

Cheng Li (editor) πŸ‘‘ Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: c.l@huawei.com

Additional contact information (the extra details, lowkey iconic):

ζŽε‘ˆ (editor) δΈ­ε›½ 100095 εŒ—δΊ¬ εŽδΈΊεŒ—η ”ζ‰€ εŽδΈΊζŠ€ζœ―ζœ‰ι™ε…¬εΈ

Prejeeth Kaladharan 🌸 RtBrick Inc Bangalore Karnataka India Email: prejeeth@rtbrick.com

Siva Sivabalan 🧚 Ciena Corporation Email: msiva282@gmail.com

Mike Koldychev πŸ“ Ciena Corporation Canada Email: mkoldych@ciena.com

Yongqing Zhu 🫢 China Telecom 109 West Zhongshan Ave, Tianhe District Bangalore Guangzhou, China Email: zhuyq8@chinatelecom.cn

πŸ“¦ where this page comes from