idnits 2.17.1 draft-ietf-pce-segment-routing-ipv6-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (11 January 2022) is 836 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-19) exists of draft-ietf-lsr-isis-srv6-extensions-18 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 == Outdated reference: A later version (-15) exists of draft-ietf-lsr-ospfv3-srv6-extensions-03 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-09 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-17 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group C. Li 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track M. Negi 5 Expires: 15 July 2022 RtBrick Inc 6 S. Sivabalan 7 Ciena Corporation 8 M. Koldychev 9 Cisco Systems, Inc. 10 P. Kaladharan 11 RtBrick Inc 12 Y. Zhu 13 China Telecom 14 11 January 2022 16 PCEP Extensions for Segment Routing leveraging the IPv6 data plane 17 draft-ietf-pce-segment-routing-ipv6-11 19 Abstract 21 The Source Packet Routing in Networking (SPRING) architecture 22 describes how Segment Routing (SR) can be used to steer packets 23 through an IPv6 or MPLS network using the source routing paradigm. 24 SR enables any head-end node to select any path without relying on a 25 hop-by-hop signaling technique (e.g., LDP or RSVP-TE). 27 It depends only on "segments" that are advertised by Link- State 28 IGPs. A Segment Routed Path can be derived from a variety of 29 mechanisms, including an IGP Shortest Path Tree (SPT), explicit 30 configuration, or a Path Computation Element (PCE). 32 Since SR can be applied to both MPLS and IPv6 forwarding plane, a PCE 33 should be able to compute SR-Path for both MPLS and IPv6 forwarding 34 plane. This document describes the extensions required for SR 35 support for IPv6 data plane in Path Computation Element communication 36 Protocol (PCEP). The PCEP extension and mechanism to support SR-MPLS 37 is described in RFC 8664. This document extends it to support SRv6 38 (SR over IPv6). 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 44 "OPTIONAL" in this document are to be interpreted as described in BCP 45 14 [RFC2119] [RFC8174] when, and only when, they appear in all 46 capitals, as shown here. 48 Status of This Memo 50 This Internet-Draft is submitted in full conformance with the 51 provisions of BCP 78 and BCP 79. 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF). Note that other groups may also distribute 55 working documents as Internet-Drafts. The list of current Internet- 56 Drafts is at https://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 This Internet-Draft will expire on 15 July 2022. 65 Copyright Notice 67 Copyright (c) 2022 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 72 license-info) in effect on the date of publication of this document. 73 Please review these documents carefully, as they describe your rights 74 and restrictions with respect to this document. Code Components 75 extracted from this document must include Revised BSD License text as 76 described in Section 4.e of the Trust Legal Provisions and are 77 provided without warranty as described in the Revised BSD License. 79 Table of Contents 81 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 82 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 83 3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5 84 3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6 85 3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 7 86 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 87 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 88 4.1.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 7 89 4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 9 90 4.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 91 4.3.1. SRv6-ERO Subobject . . . . . . . . . . . . . . . . . 9 92 4.3.1.1. SID Structure . . . . . . . . . . . . . . . . . . 11 93 4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 4.4.1. SRv6-RRO Subobject . . . . . . . . . . . . . . . . . 13 95 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 13 96 5.1. Exchanging the SRv6 Capability . . . . . . . . . . . . . 14 97 5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 15 98 5.2.1. SRv6 ERO Validation . . . . . . . . . . . . . . . . . 15 99 5.2.2. Interpreting the SRv6-ERO . . . . . . . . . . . . . . 16 100 5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 17 101 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 102 7. Manageability Considerations . . . . . . . . . . . . . . . . 17 103 7.1. Control of Function and Policy . . . . . . . . . . . . . 17 104 7.2. Information and Data Models . . . . . . . . . . . . . . . 17 105 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 17 106 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 18 107 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 18 108 7.6. Impact On Network Operations . . . . . . . . . . . . . . 18 109 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 110 8.1. Cisco's Commercial Delivery . . . . . . . . . . . . . . . 18 111 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 112 9.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 19 113 9.2. New SRv6-ERO Flag Registry . . . . . . . . . . . . . . . 19 114 9.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 20 115 9.4. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 20 116 9.5. New Path Setup Type . . . . . . . . . . . . . . . . . . . 21 117 9.6. ERROR Objects . . . . . . . . . . . . . . . . . . . . . . 21 118 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 119 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 120 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 121 11.2. Informative References . . . . . . . . . . . . . . . . . 23 122 Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 25 123 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 125 1. Introduction 127 As per [RFC8402], with Segment Routing (SR), a node steers a packet 128 through an ordered list of instructions, called segments. A segment 129 can represent any instruction, topological or service-based. A 130 segment can have a semantic local to an SR node or global within an 131 SR domain. SR allows to enforce a flow through any path and service 132 chain while maintaining per-flow state only at the ingress node of 133 the SR domain. Segments can be derived from different components: 134 IGP, BGP, Services, Contexts, Locater, etc. The list of segment 135 forming the path is called the Segment List and is encoded in the 136 packet header. Segment Routing can be applied to the IPv6 137 architecture with the Segment Routing Header (SRH) [RFC8754]. A 138 segment is encoded as an IPv6 address. An ordered list of segments 139 is encoded as an ordered list of IPv6 addresses in the routing 140 header. The active segment is indicated by the Destination Address 141 of the packet. Upon completion of a segment, a pointer in the new 142 routing header is incremented and indicates the next segment. 144 Segment Routing use cases are described in [RFC7855] and [RFC8354]. 145 Segment Routing protocol extensions are defined in [RFC8667], and 146 [RFC8666]. 148 As per [RFC8754], an SRv6 Segment is a 128-bit value. "SRv6 SID" or 149 simply "SID" are often used as a shorter reference for "SRv6 150 Segment". Further details are in an illustration provided in 151 [RFC8986]. 153 The SR architecture can be applied to the MPLS forwarding plane 154 without any change, in which case an SR path corresponds to an MPLS 155 Label Switching Path (LSP). The SR is applied to IPV6 forwarding 156 plane using SRH. A SR path can be derived from an IGP Shortest Path 157 Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may 158 be chosen by a suitable network planning tool, or a PCE and 159 provisioned on the ingress node. 161 [RFC5440] describes Path Computation Element communication Protocol 162 (PCEP) for communication between a Path Computation Client (PCC) and 163 a Path Computation Element (PCE) or between a pair of PCEs. A PCE or 164 a PCC operating as a PCE (in hierarchical PCE environment) computes 165 paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on 166 various constraints and optimization criteria. [RFC8231] specifies 167 extensions to PCEP that allow a stateful PCE to compute and recommend 168 network paths in compliance with [RFC4657] and defines objects and 169 TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide 170 synchronization of LSP state between a PCC and a PCE or between a 171 pair of PCEs, delegation of LSP control, reporting of LSP state from 172 a PCC to a PCE, controlling the setup and path routing of an LSP from 173 a PCE to a PCC. Stateful PCEP extensions are intended for an 174 operational model in which LSPs are configured on the PCC, and 175 control over them is delegated to the PCE. 177 A mechanism to dynamically initiate LSPs on a PCC based on the 178 requests from a stateful PCE or a controller using stateful PCE is 179 specified in [RFC8281]. As per [RFC8664], it is possible to use a 180 stateful PCE for computing one or more SR-TE paths taking into 181 account various constraints and objective functions. Once a path is 182 chosen, the stateful PCE can initiate an SR-TE path on a PCC using 183 PCEP extensions specified in [RFC8281] using the SR specific PCEP 184 extensions specified in [RFC8664]. [RFC8664] specifies PCEP 185 extensions for supporting a SR-TE LSP for MPLS data plane. This 186 document extends [RFC8664] to support SR for IPv6 data plane. 187 Additionally, using procedures described in this document, a PCC can 188 request an SRv6 path from either stateful or a stateless PCE. This 189 specification relies on the PATH-SETUP-TYPE TLV and procedures 190 specified in [RFC8408]. 192 This specification provides a mechanism for a network controller 193 (acting as a PCE) to instantiate candidate paths for an SR Policy 194 onto a head-end node (acting as a PCC) using PCEP. For more 195 information on the SR Policy Architecture, see 196 [I-D.ietf-spring-segment-routing-policy]. 198 2. Terminology 200 This document uses the following terms defined in [RFC5440]: PCC, 201 PCE, PCEP Peer. 203 This document uses the following terms defined in [RFC8051]: Stateful 204 PCE, Delegation. 206 The message formats in this document are specified using Routing 207 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 209 NAI: Node or Adjacency Identifier. 211 PCC: Path Computation Client. 213 PCE: Path Computation Element. 215 PCEP: Path Computation Element Protocol. 217 SR: Segment Routing. 219 SID: Segment Identifier. 221 SRv6: Segment Routing for IPv6 forwarding plane. 223 SRH: IPv6 Segment Routing Header. 225 SR Path: IPv6 Segment List (List of IPv6 SIDs representing a path in 226 IPv6 SR domain) 228 Further, note that the term LSP used in the PCEP specifications, 229 would be equivalent to a SRv6 Path (represented as a list of SRv6 230 segments) in the context of supporting SRv6 in PCEP. 232 3. Overview of PCEP Operation in SRv6 Networks 234 Basic operations for PCEP speakers is as per [RFC8664]. SRv6 Paths 235 computed by a PCE can be represented as an ordered list of SRv6 236 segments of 128-bit value. "SRv6 SID" or simply "SID" are often used 237 as a shorter reference for "SRv6 Segment" in this document. 239 [RFC8664] defined a new Explicit Route Object (ERO) subobject denoted 240 by "SR-ERO subobject" capable of carrying a SID as well as the 241 identity of the node/adjacency represented by the SID. SR-capable 242 PCEP speakers should be able to generate and/or process such ERO 243 subobject. An ERO containing SR-ERO subobjects can be included in 244 the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], 245 the PCEP LSP Initiate Request message (PCInitiate) defined in 246 [RFC8281], as well as in the PCEP LSP Update Request (PCUpd) and PCEP 247 LSP State Report (PCRpt) messages defined in defined in [RFC8231]. 249 This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in ERO 250 and RRO respectively to carry SRv6 SID (IPv6 Address). SRv6-capable 251 PCEP speakers MUST be able to generate and/or process this. 253 When a PCEP session between a PCC and a PCE is established, both PCEP 254 speakers exchange their capabilities to indicate their ability to 255 support SRv6 specific functionality. 257 In summary, this document: 259 * Defines a new PCEP capability for SRv6. 261 * Defines a new subobject SRv6-ERO in ERO. 263 * Defines a new subobject SRv6-RRO in RRO. 265 * Defines a new path setup type carried in the PATH-SETUP-TYPE TLV 266 and the PATH-SETUP-TYPE-CAPABILITY TLV. 268 3.1. Operation Overview 270 In SR networks, an ingress node of an SR path appends all outgoing 271 packets with an SR header consisting of a list of SIDs (IPv6 Prefix 272 in case of SRv6). The header has all necessary information to guide 273 the packets from the ingress node to the egress node of the path, and 274 hence there is no need for any signaling protocol. 276 For IPv6 in control plane with MPLS data-plane, mechanism remains 277 same as [RFC8664] 279 This document describes extensions to SR path for IPv6 data plane. 280 SRv6 Path (i.e. ERO) consists of an ordered set of SRv6 SIDs(see 281 details in Figure 2). 283 A PCC or PCE indicates its ability to support SRv6 during the PCEP 284 session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV 285 (see details in Section 4.1.1). 287 3.2. SRv6-Specific PCEP Message Extensions 289 As defined in [RFC5440], a PCEP message consists of a common header 290 followed by a variable length body made up of mandatory and/or 291 optional objects. This document does not require any changes in the 292 format of PCReq and PCRep messages specified in [RFC5440], PCInitiate 293 message specified in [RFC8281], and PCRpt and PCUpd messages 294 specified in [RFC8231]. However, PCEP messages pertaining to SRv6 295 MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly 296 identify that SRv6 is intended. 298 4. Object Formats 300 4.1. The OPEN Object 302 4.1.1. The SRv6 PCE Capability sub-TLV 304 This document defines a new Path Setup Type (PST) [RFC8408] for SRv6, 305 as follows: 307 * PST = TBD2: Path is setup using SRv6. 309 A PCEP speaker MUST indicate its support of the function described in 310 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 311 object with this new PST included in the PST list. 313 This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP 314 speakers use this sub-TLV to exchange information about their SRv6 315 capability. If a PCEP speaker includes PST=TBD2 in the PST List of 316 the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the 317 SRv6-PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY 318 TLV. 320 The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the 321 following figure: 323 0 1 2 3 324 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 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Type=TBD1 | Length | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Reserved | Flags |N|X| 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | MSD-Type | MSD-Value | MSD-Type | MSD-Value | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 // ... // 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | MSD-Type | MSD-Value | Padding | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Figure 1: SRv6-PCE-CAPABILITY sub-TLV format 339 The code point for the TLV type (TBD1) is to be defined by IANA. The 340 TLV length is variable. 342 The value comprises of - 344 Reserved: 2 octet, this field MUST be set to 0 on transmission, 345 and ignored on receipt. 347 Flags: 2 octet, two bits are currently assigned in this document. 349 - N bit: A PCC sets this flag bit to 1 to indicate that it is 350 capable of resolving a Node or Adjacency Identifier (NAI) to a 351 SRv6-SID. 353 - X bit: A PCC sets this bit to 1 to indicate that it does not 354 impose any limit on MSD (irrespective of the MSD-Type). 356 - Unassigned bits MUST be set to 0 and ignored on receipt. 358 A pair of (MSD-Type, MSD-Value): Where MSD-Type (1 octet) is as 359 per the IGP MSD Type registry created by [RFC8491] and populated 360 with SRv6 MSD types as per [I-D.ietf-lsr-isis-srv6-extensions]; 361 MSD-Value (1 octet) is as per [RFC8491]. 363 This sub-TLV format is compliant with the PCEP TLV format defined in 364 [RFC5440]. That is, the sub-TLV is composed of 2 octets for the 365 type, 2 octets specifying the length, and a Value field. The Type 366 field when set to TBD1 identifies the SRv6-PCE-CAPABILITY sub-TLV and 367 the presence of the sub-TLV indicates the support for the SRv6 paths 368 in PCEP. The Length field defines the length of the value portion in 369 octets. The TLV is padded to 4-octet alignment, and padding is not 370 included in the Length field. The number of (MSD-Type,MSD-Value) 371 pairs can be determined from the Length field of the TLV. 373 4.2. The RP/SRP Object 375 In order to indicate the SRv6 path, RP or SRP object MUST include the 376 PATH-SETUP-TYPE TLV specified in [RFC8408]. This document defines a 377 new Path Setup Type (PST=TBD2) for SRv6. 379 The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 381 4.3. ERO 383 In order to support SRv6, new subobject "SRv6-ERO" is defined in ERO. 385 4.3.1. SRv6-ERO Subobject 387 An SRv6-ERO subobject is formatted as shown in the following figure. 389 0 1 2 3 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 |L| Type=TBD3 | Length | NT | Flags |V|T|F|S| 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Reserved | Endpoint Behavior | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | | 397 | SRv6 SID (optional) | 398 | (128-bit) | 399 | | 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 // NAI (variable, optional) // 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | SID Structure (optional) | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 Figure 2: SRv6-ERO Subobject Format 408 The fields in the SRv6-ERO Subobject are as follows: 410 The 'L' Flag: Indicates whether the subobject represents a loose-hop 411 (see [RFC3209]). If this flag is set to zero, a PCC MUST NOT 412 overwrite the SID value present in the SRv6-ERO subobject. 413 Otherwise, a PCC MAY expand or replace one or more SID values in the 414 received SRv6-ERO based on its local policy. 416 Type: indicates the content of the subobject, i.e. when the field is 417 set to TBD3, the suboject is a SRv6-ERO subobject representing a SRv6 418 SID. 420 Length: Contains the total length of the subobject in octets. The 421 Length MUST be at least 24, and MUST be a multiple of 4. An SRv6-ERO 422 subobject MUST contain at least one of a SRv6-SID or an NAI. The S 423 and F bit in the Flags field indicates whether the SRv6-SID or NAI 424 fields are absent. 426 NAI Type (NT): Indicates the type and format of the NAI contained in 427 the object body, if any is present. If the F bit is set to zero (see 428 below) then the NT field has no meaning and MUST be ignored by the 429 receiver. This document reuses NT types defined in [RFC8664]: 431 If NT value is 0, the NAI MUST NOT be included. 433 When NT value is 2, the NAI is as per the 'IPv6 Node ID' format 434 defined in [RFC8664], which specifies an IPv6 address. This is 435 used to identify the owner of the SRv6 Identifier. This is 436 optional, as the LOC (the locater portion) of the SRv6 SID serves 437 a similar purpose (when present). 439 When NT value is 4, the NAI is as per the 'IPv6 Adjacency' format 440 defined in [RFC8664], which specify a pair of IPv6 addresses. 441 This is used to identify the IPv6 Adjacency and used with the SRv6 442 Adj-SID. 444 When NT value is 6, the NAI is as per the 'link-local IPv6 445 addresses' format defined in [RFC8664], which specify a pair of 446 (global IPv6 address, interface ID) tuples. It is used to 447 identify the IPv6 Adjacency and used with the SRv6 Adj-SID. 449 SR-MPLS specific NT types are not valid in SRv6-ERO. 451 Flags: Used to carry additional information pertaining to the 452 SRv6-SID. This document defines the following flag bits. The other 453 bits MUST be set to zero by the sender and MUST be ignored by the 454 receiver. 456 * S: When this bit is set to 1, the SRv6-SID value in the subobject 457 body is absent. In this case, the PCC is responsible for choosing 458 the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI 459 which, in this case, MUST be present in the subobject. If the S 460 bit is set to 1 then F bit MUST be set to zero. 462 * F: When this bit is set to 1, the NAI value in the subobject body 463 is absent. The F bit MUST be set to 1 if NT=0, and otherwise MUST 464 be set to zero. The S and F bits MUST NOT both be set to 1. 466 * T: When this bit is set to 1, the SID Structure value in the 467 subobject body is present. The T bit MUST be set to 0 when S bit 468 is set to 1. If the T bit is set when the S bit is set, the T bit 469 MUST be ignored. Thus, the T bit indicates the presence of an 470 optional 8-byte SID Structure when SRv6 SID is included. The SID 471 Structure is defined in Section 4.3.1.1. 473 * V: The "SID verification" bit usage is as per Section 5.1 of 474 [I-D.ietf-spring-segment-routing-policy]. 476 Reserved: MUST be set to zero while sending and ignored on receipt. 478 Endpoint Behavior: A 16 bit field representing the behavior 479 associated with the SRv6 SIDs. This information is optional and 480 plays no role in the fields in SRH imposed on the packet. It could 481 be used for maintainability and diagnostic purpose. If behavior is 482 not known, 0 is used. The list of Endpoint behavior are defined in 483 [RFC8986]. 485 SRv6 SID: SRv6 Identifier is the 128 bit IPv6 addresses representing 486 the SRv6 segment. 488 NAI: The NAI associated with the SRv6-SID. The NAI's format depends 489 on the value in the NT field, and is described in [RFC8664]. 491 At least one of the SRv6-SID or the NAI MUST be included in the 492 SRv6-ERO subobject, and both MAY be included. 494 4.3.1.1. SID Structure 496 The SID Structure is an optional part of the SR-ERO subobject, as 497 described in Section 4.3.1. It is formatted as shown in the 498 following figure. 500 0 1 2 3 501 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 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | LB Length | LN Length | Fun. Length | Arg. Length | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Reserved | Flags | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 3: SID Structure Format 510 where: 512 LB Length: 1 octet. SRv6 SID Locator Block length in bits. 514 LN Length: 1 octet. SRv6 SID Locator Node length in bits. 516 Fun. Length: 1 octet. SRv6 SID Function length in bits. 518 Arg. Length: 1 octet. SRv6 SID Arguments length in bits. 520 The sum of all four sizes in the SID Structure must be lower or equal 521 to 128 bits. If the sum of all four sizes advertised in the SID 522 Structure is larger than 128 bits, the corresponding SRv6 SID MUST be 523 considered as an Error. A PCErr message with Error-Type = 10 524 ("Reception of an invalid object") and Error-Value = TBD ("Invalid 525 SRv6 SID Structure"). 527 Reserved: MUST be set to zero while sending and ignored on receipt. 529 Flags: Currentky no flags are defined. Unassigned bits must be set 530 to zero while sending and ignored on receipt. 532 The SRv6 SID Structure TLV provides the detailed encoding information 533 of an SRv6 SID, which is useful in the use cases that require to know 534 the SRv6 SID structure. When a PCEP speaker receives the SRv6 SID 535 and its structure information, the SRv6 SID can be parsed based on 536 the SRv6 SID Structure TLV and/or possible local policies. The 537 cunsumers of SRv6 SID structure MAY be other use cases, and the 538 processing and usage of SRv6 SID structure TLV are different based on 539 use cases. This is out of the scope of this document, and will be 540 described in other documents. 542 4.4. RRO 544 In order to support SRv6, new subobject "SRv6-RRO" is defined in RRO. 546 4.4.1. SRv6-RRO Subobject 548 A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per 549 [RFC8231]. The RRO on this message represents the SID list that was 550 applied by the PCC, that is, the actual path taken. The procedures 551 of [RFC8664] with respect to the RRO apply equally to this 552 specification without change. 554 An RRO contains one or more subobjects called "SRv6-RRO subobjects" 555 whose format is shown below: 557 0 1 2 3 558 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 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Type=TBD4 | Length | NT | Flags |V|T|F|S| 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Reserved | Endpoint Behavior | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | | 565 | SRv6 SID | 566 | (128-bit) | 567 | | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 // NAI (variable) // 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | SID Structure (optional) | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Figure 4: SRv6-RRO Subobject Format 576 The format of the SRv6-RRO subobject is the same as that of the 577 SRv6-ERO subobject, but without the L flag. 579 The V flag has no meaning in the SRv6-RRO and is ignored on receipt 580 at the PCE. 582 Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as 583 per [RFC8664]. 585 5. Procedures 586 5.1. Exchanging the SRv6 Capability 588 A PCC indicates that it is capable of supporting the head-end 589 functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in 590 the Open message that it sends to a PCE. A PCE indicates that it is 591 capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY 592 sub-TLV in the Open message that it sends to a PCC. 594 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 595 PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is 596 absent, then the PCEP speaker MUST send a PCErr message with Error- 597 Type 10 (Reception of an invalid object) and Error-Value TBD5 (to be 598 assigned by IANA) (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then 599 close the PCEP session. If a PCEP speaker receives a PATH-SETUP- 600 TYPE-CAPABILITY TLV with a SRv6-PCE-CAPABILITY sub-TLV, but the PST 601 list does not contain PST=TBD2, then the PCEP speaker MUST ignore the 602 SRv6-PCE-CAPABILITY sub-TLV. 604 The number of SRv6 SIDs that can be imposed on a packet depends on 605 the PCC's IPv6 data plane's capability. If a PCC sets the X flag to 606 1 then the MSD is not used and MUST NOT be included. If a PCE 607 receives an SRv6-PCE-CAPABILITY sub-TLV with the X flag set to 1 then 608 it MUST ignore any MSD-Type, MSD-Value fields and MUST assume that 609 the sender can impose any length of SRH. If a PCC sets the X flag to 610 zero, then it sets the SRv6 MSD-Type, MSD-Value fields that it can 611 impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV 612 with the X flag and SRv6 MSD-Type, MSD-Value fields both set to zero 613 then it is considered as an error and the PCE MUST respond with a 614 PCErr message (Error-Type=1 "PCEP session establishment failure" and 615 Error-Value=1 "reception of an invalid Open message or a non Open 616 message."). In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV 617 received by the PCE does not correspond to one of the SRv6 MSD types, 618 the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session 619 establishment failure" and Error-Value=1 "reception of an invalid 620 Open message or a non Open message."). 622 Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE- 623 CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the 624 PCC node. However, if a PCE learns these via different means, e.g 625 routing protocols, as specified in: 626 [I-D.ietf-lsr-ospfv3-srv6-extensions]; 627 [I-D.ietf-lsr-isis-srv6-extensions]; [I-D.ietf-idr-bgpls-srv6-ext], 628 then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV. 629 Furthermore, whenever a PCE learns the other advanced SRv6 MSD via 630 different means, it MUST use that value regardless of the values 631 exchanged in the SRv6-PCE-CAPABILITY sub-TLV. 633 Once an SRv6-capable PCEP session is established with a non-zero SRv6 634 MSD value, the corresponding PCE MUST NOT send SRv6 paths with a 635 number of SIDs exceeding that SRv6 MSD value (based on the SRv6 MSD 636 Type). If a PCC needs to modify the SRv6 MSD value, it MUST close 637 the PCEP session and re-establish it with the new value. If a PCEP 638 session is established with a non-zero SRv6 MSD value, and the PCC 639 receives an SRv6 path containing more SIDs than specified in the SRv6 640 MSD value (based on the SRv6 MSD type), the PCC MUST send a PCErr 641 message with Error-Type 10 (Reception of an invalid object) and 642 Error-Value 3 (Unsupported number of Segment ERO subobjects). If a 643 PCEP session is established with an SRv6 MSD value of zero, then the 644 PCC MAY specify an SRv6 MSD for each path computation request that it 645 sends to the PCE, by including a "maximum SID depth" metric object on 646 the request similar to [RFC8664]. 648 The N flag, X flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE- 649 CAPABILITY sub-TLV are meaningful only in the Open message sent from 650 a PCC to a PCE. As such, a PCE MUST set the flags to zero and not 651 include any (MSD-Type,MSD-Value) pair in the SRv6-PCE-CAPABILITY sub- 652 TLV in an outbound message to a PCC. Similarly, a PCC MUST ignore 653 N,X flag and any (MSD-Type,MSD-Value) pair received from a PCE. If a 654 PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open 655 message, it processes only the first sub-TLV received. 657 5.2. ERO Processing 659 The ERO processing remains as per [RFC5440] and [RFC8664]. 661 5.2.1. SRv6 ERO Validation 663 If a PCC does not support the SRv6 PCE Capability and thus cannot 664 recognize the SRv6-ERO or SRv6-RRO subobjects, it will respond 665 according to the rules for a malformed object per [RFC5440]. 667 On receiving an SRv6-ERO, a PCC MUST validate that the Length field, 668 the S bit, the F bit, the T bit, and the NT field are consistent, as 669 follows. 671 * If NT=0, the F bit MUST be 1, the S bit MUST be zero and the 672 Length MUST be 24. 674 * If NT=2, the F bit MUST be zero. If the S bit is 1, the Length 675 MUST be 24, otherwise the Length MUST be 40. 677 * If NT=4, the F bit MUST be zero. If the S bit is 1, the Length 678 MUST be 40, otherwise the Length MUST be 56. 680 * If NT=6, the F bit MUST be zero. If the S bit is 1, the Length 681 MUST be 48, otherwise the Length MUST be 64. 683 * NT types (1,3, and 5) are not valid for SRv6. 685 * If T bit is 1, then S bit MUST be zero. 687 If a PCC finds that the NT field, Length field, S bit, F bit, and T 688 bit are not consistent, it MUST consider the entire ERO invalid and 689 MUST send a PCErr message with Error-Type = 10 ("Reception of an 690 invalid object") and Error-Value = 11 ("Malformed object"). 692 If a PCEP speaker that does not recognize the NT value received in 693 SRv6-ERO subobject, it would behave as per [RFC8664]. 695 In case a PCEP speaker receives the SRv6-ERO subobject, when the PST 696 is not set to TBD2 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged, 697 it MUST send a PCErr message with Error-Type = 19 ("Invalid 698 Operation") and Error-Value = TBD9 ("Attempted SRv6 when the 699 capability was not advertised"). 701 If a PCC receives a list of SRv6 segments, and the number of SRv6 702 segments exceeds the SRv6 MSD that the PCC can impose on the packet 703 (SRH), it MUST send a PCErr message with Error-Type = 10 ("Reception 704 of an invalid object") and Error-Value = TBD ("Unsupported number of 705 Segment ERO subobjects") as per [RFC8664]. 707 When a PCEP speaker detects that all subobjects of ERO are not of 708 type TBD3, and if it does not handle such ERO, it MUST send a PCErr 709 message with Error-Type = 10 ("Reception of an invalid object") and 710 Error-Value = TBD ("Non-identical ERO subobjects")as per [RFC8664]. 712 5.2.2. Interpreting the SRv6-ERO 714 The SRv6-ERO contains a sequence of subobjects. According to 715 [I-D.ietf-spring-segment-routing-policy], each SRv6-ERO subobject in 716 the sequence identifies a segment that the traffic will be directed 717 to, in the order given. That is, the first subobject identifies the 718 first segment the traffic will be directed to, the second SRv6-ERO 719 subobject represents the second segment, and so on. 721 The PCC interprets the SRv6-ERO by converting it to an SRv6 SRH plus 722 a next hop. The PCC sends packets along the segment routed path by 723 prepending the SRH onto the packets and sending the resulting, 724 modified packet to the next hop. 726 5.3. RRO Processing 728 The syntax checking rules that apply to the SRv6-RRO subobject are 729 identical to those of the SRv6-ERO subobject, except as noted below. 731 If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6 732 SID and NAI are absent, it MUST consider the entire RRO invalid and 733 send a PCErr message with Error-Type = 10 ("Reception of an invalid 734 object") and Error-Value = TBD6 ("Both SID and NAI are absent in 735 SRv6-RRO subobject"). 737 If a PCE detects that the subobjects of an RRO are a mixture of 738 SRv6-RRO subobjects and subobjects of other types, then it MUST send 739 a PCErr message with Error-Type = 10 ("Reception of an invalid 740 object") and Error-Value = TBD7 ("RRO mixes SRv6-RRO subobjects with 741 other subobject types"). 743 6. Security Considerations 745 The security considerations described in [RFC5440], [RFC8231] and 746 [RFC8281], [RFC8664], are applicable to this specification. No 747 additional security measure is required. 749 7. Manageability Considerations 751 All manageability requirements and considerations listed in 752 [RFC5440], [RFC8231], and [RFC8664] apply to PCEP protocol extensions 753 defined in this document. In addition, requirements and 754 considerations listed in this section apply. 756 7.1. Control of Function and Policy 758 A PCEP implementation SHOULD allow the operator to configure the 759 policy based on which it allocates the SIDs. 761 7.2. Information and Data Models 763 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. An 764 implementation SHOULD allow the operator to view the SIDs allocated 765 to the LSP for the SR path. 767 7.3. Liveness Detection and Monitoring 769 Mechanisms defined in this document do not imply any new liveness 770 detection and monitoring requirements in addition to those already 771 listed in [RFC5440]. 773 7.4. Verify Correct Operations 775 Mechanisms defined in this document do not imply any new operation 776 verification requirements in addition to those already listed in 777 [RFC5440], [RFC8231], and [RFC8664] . 779 7.5. Requirements On Other Protocols 781 Mechanisms defined in this document do not imply any new requirements 782 on other protocols. 784 7.6. Impact On Network Operations 786 Mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also apply 787 to PCEP extensions defined in this document. 789 8. Implementation Status 791 [Note to the RFC Editor - remove this section before publication, as 792 well as remove the reference to [RFC7942]. 794 This section records the status of known implementations of the 795 protocol defined by this specification at the time of posting of this 796 Internet-Draft, and is based on a proposal described in [RFC7942]. 797 The description of implementations in this section is intended to 798 assist the IETF in its decision processes in progressing drafts to 799 RFCs. Please note that the listing of any individual implementation 800 here does not imply endorsement by the IETF. Furthermore, no effort 801 has been spent to verify the information presented here that was 802 supplied by IETF contributors. This is not intended as, and must not 803 be construed to be, a catalog of available implementations or their 804 features. Readers are advised to note that other implementations may 805 exist. 807 According to [RFC7942], "this will allow reviewers and working groups 808 to assign due consideration to documents that have the benefit of 809 running code, which may serve as evidence of valuable experimentation 810 and feedback that have made the implemented protocols more mature. 811 It is up to the individual working groups to use this information as 812 they see fit". 814 8.1. Cisco's Commercial Delivery 816 * Organization: Cisco Systems, Inc. 818 * Implementation: IOS-XR PCE and PCC. 820 * Description: Implementation with experimental codepoints. 822 * Maturity Level: Production 824 * Coverage: Partial 826 * Contact: ssidor@cisco.com 828 9. IANA Considerations 830 9.1. PCEP ERO and RRO subobjects 832 This document defines a new subobject type for the PCEP explicit 833 route object (ERO), and a new subobject type for the PCEP record 834 route object (RRO). The code points for subobject types of these 835 objects is maintained in the RSVP parameters registry, under the 836 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to 837 allocate code-points in the RSVP Parameters registry for each of the 838 new subobject types defined in this document. 840 Object Subobject Subobject Type 841 --------------------- -------------------------- ------------------ 842 EXPLICIT_ROUTE SRv6-ERO (PCEP-specific) TBD3 843 ROUTE_RECORD SRv6-RRO (PCEP-specific) TBD4 845 9.2. New SRv6-ERO Flag Registry 847 IANA is requested to create a new sub-registry, named "SRv6-ERO Flag 848 Field", within the "Path Computation Element Protocol (PCEP) Numbers" 849 registry to manage the Flag field of the SRv6-ERO subobject. New 850 values are to be assigned by Standards Action [RFC8126]. Each bit 851 should be tracked with the following qualities: 853 * Bit number (counting from bit 0 as the most significant bit) 855 * Capability description 857 * Defining RFC 859 The following values are defined in this document: 861 Bit Description Reference 862 ----- ------------------ -------------- 863 0-7 Unassigned 864 8 SID Verification (V) This document 865 9 SID Structure is This document 866 present (T) 867 10 NAI is absent (F) This document 868 11 SID is absent (S) This document 870 9.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 872 IANA maintains a sub-registry, named "PATH-SETUP-TYPE-CAPABILITY Sub- 873 TLV Type Indicators", within the "Path Computation Element Protocol 874 (PCEP) Numbers" registry to manage the type indicator space for sub- 875 TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA is requested to 876 make the following assignment: 878 Value Meaning Reference 879 ----- ------- --------- 880 TBD1 SRv6-PCE-CAPABILITY This Document 882 9.4. SRv6 PCE Capability Flags 884 IANA is requested to create a new sub-registry, named "SRv6 885 Capability Flag Field", within the "Path Computation Element Protocol 886 (PCEP) Numbers" registry to manage the Flag field of the SRv6-PCE- 887 CAPABILITY sub-TLV. New values are to be assigned by Standards 888 Action [RFC8126]. Each bit should be tracked with the following 889 qualities: 891 * Bit number (counting from bit 0 as the most significant bit) 893 * Capability description 895 * Defining RFC 897 The following values are defined in this document: 899 Bit Description Reference 901 0-13 Unassigned 902 14 Node or Adjacency This document 903 Identifier (NAI) is 904 supported (N) 905 15 Unlimited Maximum SID This document 906 Depth (X) 908 9.5. New Path Setup Type 910 [RFC8408] created a sub-registry within the "Path Computation Element 911 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 912 IANA is requested to allocate a new code point within this registry, 913 as follows: 915 Value Description Reference 916 ----- ----------- --------- 917 TBD2 Traffic engineering path is This Document 918 setup using SRv6. 920 9.6. ERROR Objects 922 IANA is requested to allocate code-points in the PCEP-ERROR Object 923 Error Types and Values registry for the following new error-values: 925 Error-Type Meaning 926 ---------- ------- 927 10 Reception of an invalid object 928 Error-value = TBD5 (Missing 929 PCE-SRv6-CAPABILITY sub-TLV) 930 Error-value = TBD6 (Both SID and NAI are absent 931 in SRv6-RRO subobject) 932 Error-value = TBD7 (RRO mixes SRv6-RRO subobjects 933 with other subobject types) 934 Error-value = TBD8 (Invalid SRv6 SID Structure) 935 19 Invalid Operation 936 Error-value = TBD9 (Attempted SRv6 when the 937 capability was not advertised) 939 10. Acknowledgements 941 The authors would like to thank Jeff Tantsura, Adrian Farrel, Aijun 942 Wang and Khasanov Boris for valuable suggestions. 944 11. References 946 11.1. Normative References 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, 950 DOI 10.17487/RFC2119, March 1997, 951 . 953 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 954 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 955 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 956 . 958 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 959 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 960 DOI 10.17487/RFC5440, March 2009, 961 . 963 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 964 Used to Form Encoding Rules in Various Routing Protocol 965 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 966 2009, . 968 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 969 Writing an IANA Considerations Section in RFCs", BCP 26, 970 RFC 8126, DOI 10.17487/RFC8126, June 2017, 971 . 973 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 974 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 975 May 2017, . 977 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 978 Computation Element Communication Protocol (PCEP) 979 Extensions for Stateful PCE", RFC 8231, 980 DOI 10.17487/RFC8231, September 2017, 981 . 983 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 984 Computation Element Communication Protocol (PCEP) 985 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 986 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 987 . 989 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 990 Decraene, B., Litkowski, S., and R. Shakir, "Segment 991 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 992 July 2018, . 994 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 995 Hardwick, "Conveying Path Setup Type in PCE Communication 996 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 997 July 2018, . 999 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1000 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1001 DOI 10.17487/RFC8491, November 2018, 1002 . 1004 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1005 and J. Hardwick, "Path Computation Element Communication 1006 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1007 DOI 10.17487/RFC8664, December 2019, 1008 . 1010 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1011 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1012 (SRv6) Network Programming", RFC 8986, 1013 DOI 10.17487/RFC8986, February 2021, 1014 . 1016 [I-D.ietf-lsr-isis-srv6-extensions] 1017 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1018 Z. Hu, "IS-IS Extensions to Support Segment Routing over 1019 IPv6 Dataplane", Work in Progress, Internet-Draft, draft- 1020 ietf-lsr-isis-srv6-extensions-18, 20 October 2021, 1021 . 1024 11.2. Informative References 1026 [RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation 1027 Element (PCE) Communication Protocol Generic 1028 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1029 2006, . 1031 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1032 Code: The Implementation Status Section", BCP 205, 1033 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1034 . 1036 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1037 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1038 Packet Routing in Networking (SPRING) Problem Statement 1039 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1040 2016, . 1042 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1043 Stateful Path Computation Element (PCE)", RFC 8051, 1044 DOI 10.17487/RFC8051, January 2017, 1045 . 1047 [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., 1048 Ed., and M. Townsley, "Use Cases for IPv6 Source Packet 1049 Routing in Networking (SPRING)", RFC 8354, 1050 DOI 10.17487/RFC8354, March 2018, 1051 . 1053 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 1054 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 1055 December 2019, . 1057 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 1058 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 1059 Extensions for Segment Routing", RFC 8667, 1060 DOI 10.17487/RFC8667, December 2019, 1061 . 1063 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1064 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1065 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1066 . 1068 [I-D.ietf-spring-segment-routing-policy] 1069 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1070 P. Mattes, "Segment Routing Policy Architecture", Work in 1071 Progress, Internet-Draft, draft-ietf-spring-segment- 1072 routing-policy-14, 25 October 2021, 1073 . 1076 [I-D.ietf-lsr-ospfv3-srv6-extensions] 1077 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 1078 "OSPFv3 Extensions for SRv6", Work in Progress, Internet- 1079 Draft, draft-ietf-lsr-ospfv3-srv6-extensions-03, 19 1080 November 2021, . 1083 [I-D.ietf-idr-bgpls-srv6-ext] 1084 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1085 Bernier, D., and B. Decraene, "BGP Link State Extensions 1086 for SRv6", Work in Progress, Internet-Draft, draft-ietf- 1087 idr-bgpls-srv6-ext-09, 10 November 2021, 1088 . 1091 [I-D.ietf-pce-pcep-yang] 1092 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 1093 "A YANG Data Model for Path Computation Element 1094 Communications Protocol (PCEP)", Work in Progress, 1095 Internet-Draft, draft-ietf-pce-pcep-yang-17, 23 October 1096 2021, . 1099 Appendix A. Contributor 1101 The following persons contributed to this document: 1103 Dhruv Dhody 1104 Huawei Technologies 1105 Divyashree Techno Park, Whitefield 1106 Bangalore, Karnataka 560066 1107 India 1109 EMail: dhruv.ietf@gmail.com 1111 Huang Wumin 1112 Huawei Technologies 1113 Huawei Building, No. 156 Beiqing Rd. 1114 Beijing 100095 1115 China 1117 Email: huangwumin@huawei.com 1119 Shuping Peng 1120 Huawei Technologies 1121 Huawei Building, No. 156 Beiqing Rd. 1122 Beijing 100095 1123 China 1125 Email: pengshuping@huawei.com 1127 Authors' Addresses 1129 Cheng Li(Editor) 1130 Huawei Technologies 1131 Huawei Campus, No. 156 Beiqing Rd. 1132 Beijing 1133 100095 1134 China 1136 Email: c.l@huawei.com 1138 Mahendra Singh Negi 1139 RtBrick Inc 1140 Bangalore 1141 Karnataka 1142 India 1144 Email: mahend.ietf@gmail.com 1146 Siva Sivabalan 1147 Ciena Corporation 1149 Email: msiva282@gmail.com 1151 Mike Koldychev 1152 Cisco Systems, Inc. 1153 Canada 1155 Email: mkoldych@cisco.com 1157 Prejeeth Kaladharan 1158 RtBrick Inc 1159 Bangalore 1160 Karnataka 1161 India 1163 Email: prejeeth@rtbrick.com 1165 Yongqing Zhu 1166 China Telecom 1167 109 West Zhongshan Ave, Tianhe District 1168 Bangalore 1169 Guangzhou, 1170 P.R. China 1172 Email: zhuyq8@chinatelecom.cn