diff options
Diffstat (limited to 'doc/rfc/rfc9603.txt')
| -rw-r--r-- | doc/rfc/rfc9603.txt | 1243 |
1 files changed, 1243 insertions, 0 deletions
diff --git a/doc/rfc/rfc9603.txt b/doc/rfc/rfc9603.txt new file mode 100644 index 0000000..43010a6 --- /dev/null +++ b/doc/rfc/rfc9603.txt @@ -0,0 +1,1243 @@ + + + + +Internet Engineering Task Force (IETF) 李呈 (C. Li), Ed. +Request for Comments: 9603 华为技术有限公司 (Huawei Technologies) +Category: Standards Track P. Kaladharan +ISSN: 2070-1721 RtBrick Inc + S. Sivabalan + M. Koldychev + Ciena Corporation + Y. Zhu + China Telecom + July 2024 + + + Path Computation Element Communication Protocol (PCEP) Extensions for + IPv6 Segment Routing + +Abstract + + Segment Routing (SR) can be used to steer packets through a network + using the IPv6 or MPLS data plane, employing the source routing + paradigm. + + An SR Path can be derived from a variety of mechanisms, including an + IGP Shortest Path Tree (SPT), explicit configuration, or a Path + Computation Element (PCE). + + Since SR can be applied to both MPLS and IPv6 data planes, a PCE + should be able to compute an SR Path for both MPLS and IPv6 data + planes. The Path Computation Element Communication Protocol (PCEP) + extension and mechanisms to support SR-MPLS have been defined. This + document outlines the necessary extensions to support SR for the IPv6 + data plane within PCEP. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained 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 of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. 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 + + As defined in [RFC8402], Segment Routing (SR) architecture allows the + source node to steer a packet through a path indicated by an ordered + list of instructions, called "segments". A segment can represent any + instruction, topological or service based, and it can have a semantic + local to an SR node or global within an SR domain. + + [RFC5440] describes Path Computation Element Communication Protocol + (PCEP) for communication between a Path Computation Client (PCC) and + a PCE or between a pair of PCEs. A PCE or a PCC operating as a PCE + (in a hierarchical PCE environment) computes paths for MPLS Traffic + Engineering Label Switched Paths (MPLS-TE LSPs) based on various + constraints and optimization criteria. + + [RFC8231] specifies extensions to PCEP that allow a stateful PCE to + compute and recommend network paths in compliance with [RFC4657] and + defines objects and TLVs for MPLS-TE LSPs. Stateful PCEP extensions + provide synchronization of LSP state between a PCC and a PCE or + between a pair of PCEs, delegation of LSP control, reporting of LSP + state from a PCC to a PCE, and controlling the setup and path routing + of an LSP from a PCE to a PCC. Stateful PCEP extensions are intended + for an operational model in which LSPs are configured on the PCC, and + control over them is delegated to the PCE. + + A mechanism to dynamically initiate LSPs on a PCC based on the + requests from a stateful PCE or a controller using stateful PCE is + specified in [RFC8281]. As per [RFC8664], it is possible to use a + stateful PCE for computing one or more SR-TE paths taking into + account various constraints and objective functions. Once a path is + computed, the stateful PCE can initiate an SR-TE path on a PCC using + PCEP extensions specified in [RFC8281] and the SR-specific PCEP + extensions specified in [RFC8664]. + + [RFC8664] specifies PCEP extensions for supporting an SR-TE LSP for + the MPLS data plane. This document extends [RFC8664] to support SR + for the IPv6 data plane. Additionally, using procedures described in + this document, a PCC can request an SRv6 path from either a stateful + or stateless PCE. This specification relies on the PATH-SETUP-TYPE + TLV and procedures specified in [RFC8408]. + + This specification provides a mechanism for a network controller + (acting as a PCE) to instantiate candidate paths for an SR Policy + onto a head-end node (acting as a PCC) using PCEP. For more + information on the SR Policy architecture, see [RFC9256], which + applies to both SR-MPLS and SRv6. + +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 document uses the following terms defined in [RFC5440]: PCC, + PCE, PCEP, PCEP Peer. + + This document uses the following terms defined in [RFC8051]: Stateful + PCE, Delegation. + + Further, the following terms are used in the document: + + 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.) + + Further, note that the term "LSP" used in the PCEP specifications + would be 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 operations for PCEP speakers are built on [RFC8664]. + + In PCEP messages, route information is carried in the Explicit Route + Object (ERO), which consists of a sequence of subobjects. [RFC8664] + defined a new ERO subobject denoted by "SR-ERO subobject" that is + capable of carrying a SID as well as the identity of the node/ + adjacency represented by the SID for SR-MPLS. SR-capable PCEP + speakers can generate and/or process such an ERO 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], as well + as in 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 was applied by the PCC, which is the actual path taken by + the LSP in SR-MPLS network. + + The SRv6 paths 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 established, both PCEP + speakers exchange their capabilities to indicate their ability to + support SRv6-specific functionality as described in Section 4.1.1. + + In summary, 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 resulting in a segment list. + + When SR leverages the IPv6 data plane (i.e., SRv6), the PCEP + procedures and mechanisms are extended in this document. + + This document describes the extension to support SRv6 in PCEP. A PCC + or PCE indicates its ability to support SRv6 during the PCEP session + initialization phase via a new SRv6-PCE-CAPABILITY sub-TLV (see + details in Section 4.1.1). + +3.2. SRv6-Specific PCEP Message Extensions + + As defined in [RFC5440], a PCEP message consists of a common header + followed by a variable-length body made up of mandatory and/or + optional objects. This document does not require any changes in the + format of PCReq and PCRep messages specified in [RFC5440], the + PCInitiate message specified in [RFC8281], or PCRpt and PCUpd + messages specified in [RFC8231]. However, PCEP messages pertaining + to SRv6 MUST include PATH-SETUP-TYPE TLV in the Request Parameters + (RP) or Stateful PCE Request Parameters (SRP) object to clearly + identify that SRv6 is intended. + +4. Object Formats + +4.1. The OPEN Object + +4.1.1. The SRv6 PCE Capability sub-TLV + + This document defines a new Path Setup Type (PST) [RFC8408] for SRv6, + as follows: + + PST=3: Path is set up using SRv6. + + A PCEP speaker indicates its support of the function described in + this document 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. PCEP + speakers use this sub-TLV to exchange information 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, please see Section 5. + + The format of the SRv6-PCE-CAPABILITY sub-TLV is shown 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | 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 is compliant + with the PCEP TLV format defined in [RFC5440]. That is, the sub-TLV + is composed of 2 octets for the type, 2 octets specifying the length, + and a Value field. When set to 27, the Type field identifies the + SRv6-PCE-CAPABILITY sub-TLV, and the presence of the sub-TLV + indicates the support for the SRv6 paths in PCEP. The Length field + defines the length of the value portion in octets. The sub-TLV is + padded to 4-octet alignment, and padding is not included in the + Length field. The (MSD-Type,MSD-Value) pairs are OPTIONAL. The + number of (MSD-Type,MSD-Value) pairs can be determined by the Length + field of the TLV. + + The value is comprised 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. + + - Unassigned bits MUST be set to 0 on transmission and ignored on + receipt + + * A pair of (MSD-Type,MSD-Value): Where MSD-Type (1 octet) is as per + the IGP MSD Type registry created by [RFC8491] and populated with + SRv6 MSD types as per [RFC9352], and where MSD-Value (1 octet) is + as per [RFC8491]. + + The SRv6 MSD information advertised via SRv6-PCE-Capability sub-TLV + conveys the SRv6 capabilities of the PCEP speaker alone. However, + when it comes to the computation of an SR Policy for the SRv6 data + plane, the SRv6 MSD capabilities of the intermediate SRv6 Endpoint + node and the tail-end node also need to be considered to ensure those + midpoints are able to correctly process their segments and for the + tail-end to dispose of the SRv6 encapsulation. The SRv6 MSD + capabilities of other nodes might be learned as part of the topology + information 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 information not be included in + the SRv6-PCE-Capability sub-TLV in deployments where the PCE is able + to obtain this via IGP/BGP-LS as part of the topology information. + +4.2. The RP/SRP Object + + This document defines a new Path Setup Type (PST=3) for SRv6. In + order to indicate that the path is for SRv6, any RP or SRP object + MUST include the PATH-SETUP-TYPE TLV as specified in [RFC8408], where + PST is set to 3. + +4.3. ERO + + In order to support SRv6, a new "SRv6-ERO" subobject is defined for + inclusion 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 + + The fields in the SRv6-ERO subobject are as follows: + + * The "L" flag: Indicates whether the subobject represents 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: Indicates the content of the subobject, i.e., when the field + is set to 40, the subobject is an SRv6-ERO subobject representing + an SRv6 SID. + + * Length: Contains 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 indicates whether the + SRv6-SID or NAI fields are absent. + + * NAI Type (NT): Indicates the type and format of the NAI contained + in the object body, if any are present. 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. This is + used to identify the owner of the SRv6 Identifier. This is + optional, as 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 specify a pair of IPv6 + addresses. This is used to identify the IPv6 adjacency and + used 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 specify a pair of + (global IPv6 address, interface ID) tuples. It is used to + identify the IPv6 adjacency and used with the SRv6 Adj-SID. + + * Flags: Used to carry additional information pertaining to 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 registry 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 up in the SR- + DB using the NAI that, 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. Thus, the T bit indicates the + presence of an optional 8-byte SID Structure when SRv6 SID is + included. The SID Structure is defined in Section 4.3.1.1. + + - V: The "SID verification" bit usage is 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 information is optional, but + providing it is recommended whenever possible. It could be used + for maintainability and diagnostic purposes. If behavior is not + known, value "0xFFFF" as defined in the "SRv6 Endpoint Behaviors" + registry is used [RFC8986]. + + * SRv6 SID: 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 + + The SID Structure is an optional part of the SR-ERO subobject, as + described in Section 4.3.1. + + [RFC8986] defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a + locator (LOC) is encoded in the L most significant bits of the SID, + followed by F bits of function (FUNCT) and A bits of arguments (ARG). + A locator may be represented as B:N where B is the SRv6 SID locator + block (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is + the identifier of the parent node instantiating the SID called + "locator node". + + The SID Structure is formatted as shown 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 + + Where: + + * 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 sum of all four sizes in the SID Structure must be less than or + equal to 128 bits. If the sum of all four sizes advertised in the + SID Structure is larger than 128 bits, the corresponding SRv6 SID + MUST be considered invalid and a PCErr message with Error-Type = 10 + ("Reception of an invalid object") and Error-value = 37 ("Invalid + SRv6 SID Structure") is returned. + + * 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. + + The SRv6 SID Structure provides the detailed encoding information of + an SRv6 SID, which is helpful in the use cases that require the SRv6 + SID structure to be known. When a PCEP speaker receives the SRv6 SID + and its structure information, the SRv6 SID can be parsed based on + the SRv6 SID Structure and/or possible local policies. The SRv6 SID + Structure could be used by the PCE for ease of operations and + monitoring. For example, this information could be used for + validation of SRv6 SIDs being instantiated in the network and checked + for conformance with the SRv6 SID allocation scheme chosen by the + operator as described in Section 3.2 of [RFC8986]. In the future, + PCE might also be utilized to verify and automate the security of the + SRv6 domain by provisioning filtering rules at the domain boundaries + as described in Section 5 of [RFC8754]. The details of these + potential applications are outside the scope of this document. + +4.3.1.2. Order of the Optional Fields + + The optional elements in the SRv6-ERO subobject, i.e., SRv6 SID, NAI, + and the SID Structure, MUST be encoded in the order as depicted in + Figure 2. The presence or absence of each of them is indicated by + the respective flags, i.e., S flag, F flag, and T flag. + + In order to ensure future compatibility, any optional elements added + to the SRv6-ERO subobject in the future must specify their order and + request that the Internet Assigned Numbers Authority (IANA) allocate + a flag to indicate their presence from the subregistry created in + Section 8.3. + +4.4. RRO + + In order to support SRv6, a new "SRv6-RRO" subobject is defined for + inclusion 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 this message represents the SID list that was + applied by the PCC, that is, the actual path taken. The procedures + of [RFC8664] with respect to the RRO apply equally to this + specification without change. + + An RRO contains one or more subobjects called "SRv6-RRO subobjects", + whose format is shown 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 format of the SRv6-RRO subobject is the same as that of the + SRv6-ERO subobject but without the L flag. + + The V flag has no meaning in the SRv6-RRO and is ignored on receipt + at the PCE. + + The ordering of SRv6-RRO subobjects by PCC in PCRpt message remains + as per [RFC8664]. + + The ordering of optional elements in the SRv6-RRO subobject is the + same as described in Section 4.3.1.2. + +5. Procedures + +5.1. Exchanging the SRv6 Capability + + A PCC indicates that it is capable of supporting the head-end + functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in + the Open message that it sends to a PCE. A PCE indicates that it is + capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY + sub-TLV in the Open message that it sends to a PCC. + + If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a + PST list containing PST=3, but the SRv6-PCE-CAPABILITY sub-TLV is + absent, 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 MUST then close the PCEP + session. If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV + with an SRv6-PCE-CAPABILITY sub-TLV, but the PST list does not + contain PST=3, then the PCEP speaker MUST ignore the SRv6-PCE- + CAPABILITY sub-TLV. + + In case the MSD-Type in the SRv6-PCE-CAPABILITY sub-TLV received by + the PCE does not correspond to 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.")). + + Note that the (MSD-Type,MSD-Value) pair exchanged via the SRv6-PCE- + CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the + sender PCC node only. However, if a PCE learns these via alternate + mechanisms, e.g., routing protocols [RFC9352], then it ignores the + values in the SRv6-PCE-CAPABILITY sub-TLV. Furthermore, whenever a + PCE learns any other SRv6 MSD types that may be defined in the future + via alternate mechanisms, it MUST use those values regardless of the + values exchanged in the SRv6-PCE-CAPABILITY sub-TLV. + + During path computation, a PCE must consider the MSD information of + all the nodes along the path instead of only the MSD information of + the ingress PCC since a packet may be dropped on any node in a + forwarding path because of the SID depth exceeding the MSD of the + node. The MSD capabilities of all SR nodes along the path can be + learned as part of the topology information via IGP/BGP-LS or via + PCEP if the PCE also happens to have PCEP sessions with those nodes. + + A PCE MUST NOT send SRv6 paths that exceed the SRv6 MSD capabilities + of the PCC. If a PCC needs to modify the SRv6 MSD value signaled via + the Open message, it MUST close the PCEP session and re-establish it + with the new value. If the PCC receives an SRv6 path that exceeds + 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 (MSD-Type,MSD-Value) pair inside the SRv6-PCE- + CAPABILITY sub-TLV are meaningful only in the Open message sent to a + PCE. As such, 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 flags + and any (MSD-Type,MSD-Value) pair in a received Open message. If a + PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open + message, it processes only the first sub-TLV received. + +5.2. ERO Processing + + The processing of ERO remains unchanged in accordance with both + [RFC5440] and [RFC8664]. + +5.2.1. SRv6 ERO Validation + + If a PCC does not support the SRv6 PCE Capability and thus cannot + recognize the SRv6-ERO or SRv6-RRO subobjects, it should respond + according to the rules for a malformed object as described in + [RFC5440]. + + On receiving an SRv6-ERO, a PCC MUST validate that the Length field, + the S bit, the F bit, the T bit, and the NT field are consistent, as + follows: + + * 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 are not consistent, 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 does not 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 in which the S and F bits are + both set to 1 (that is, 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 in which the S bit is set to + 1 and the F bit is set to zero (that is, the SID is absent and the + NAI is present), but the PCC does not 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 mixture of + SRv6-ERO subobjects and subobjects of other types, then 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 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"). + + 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 contains a sequence of subobjects. According to + [RFC9256], each SRv6-ERO subobject in the sequence identifies a + segment that the traffic will be directed to, in the order given. + That is, the first subobject identifies the first segment the traffic + will be directed to, the second SRv6-ERO subobject represents the + second segment, and so on. + +5.3. RRO Processing + + The syntax-checking rules that apply to the SRv6-RRO subobject are + identical to those of the SRv6-ERO subobject, except as noted below. + + If a PCEP speaker receives an SRv6-RRO subobject in which both 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 mixture of + SRv6-RRO subobjects and subobjects of other types, then 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 mechanism by which 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] are + applicable to this specification. + + Note that this specification enables a network controller to + instantiate an SRv6 path in the network. This creates an additional + vulnerability if the security mechanisms of [RFC5440], [RFC8231], and + [RFC8281] are not used. If there is no integrity protection on the + session, then an attacker could create an SRv6 path that may not be + subjected to the further verification checks. Further, the MSD field + in the Open message could disclose node forwarding capabilities if + suitable security mechanisms are not in place. Hence, securing the + PCEP session using Transport Layer Security (TLS) [RFC8253] is + RECOMMENDED. + +7. Manageability Considerations + + All manageability requirements and considerations listed in + [RFC5440], [RFC8231], [RFC8281], and [RFC8664] apply to PCEP protocol + extensions defined in this document. In addition, requirements and + considerations listed in this section apply. + +7.1. Control of Function and Policy + + A PCEP implementation SHOULD allow the operator to configure the SRv6 + capability. Further, a policy to accept NAI only for the SRv6 SHOULD + be allowed to be set. + +7.2. Information and Data Models + + The PCEP YANG module is out of the scope of this document; it is + defined in other documents, for example, [PCEP-YANG]. An augmented + YANG module for SRv6 is also specified in [PCEP-SRv6-YANG] that + allows for SRv6 capability and MSD configurations as well as to + monitor the SRv6 paths set in the network. + +7.3. Liveness Detection and Monitoring + + Mechanisms defined in this document do not imply any new liveness + detection and monitoring requirements in addition to those already + listed in [RFC5440]. + +7.4. Verify Correct Operations + + Verification of the mechanisms defined in this document can be built + on those already listed in [RFC5440], [RFC8231], and [RFC8664]. + +7.5. Requirements on Other Protocols + + Mechanisms defined in this document do not imply any new requirements + on other protocols. + +7.6. Impact on Network Operations + + Mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also apply + to 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 "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 + + IANA has created the "SRv6 Capability Flag Field" registry within the + "Path Computation Element Protocol (PCEP) Numbers" registry group to + manage the 16-bit Flag field of the SRv6-PCE-CAPABILITY sub-TLV. 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 value is defined in this document. + + +=====+==============================+===========+ + | Bit | Description | Reference | + +=====+==============================+===========+ + | 14 | Node or Adjacency Identifier | RFC 9603 | + | | (NAI) is supported (N) | | + +-----+------------------------------+-----------+ + + Table 7 + +8.7. New Path Setup Type + + [RFC8408] created the "PCEP Path Setup Types" registry within the + "Path Computation Element Protocol (PCEP) Numbers" registry group. + IANA has allocated the following value: + + +=======+==========================+===========+ + | Value | Description | Reference | + +=======+==========================+===========+ + | 3 | Traffic engineering path | RFC 9603 | + | | is set up using SRv6. | | + +-------+--------------------------+-----------+ + + Table 8 + +8.8. ERROR Objects + + IANA has allocated the following Error-values in the "PCEP-ERROR + Object Error Types and Values" registry within the "Path Computation + Element Protocol (PCEP) Numbers" registry group: + + +============+=================+===================================+ + | 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 + + Cheng Li (editor) + Huawei Technologies + Huawei Campus, No. 156 Beiqing Rd. + Beijing + 100095 + China + Email: c.l@huawei.com + + Additional contact information: + + 李呈 (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 |