idnits 2.17.00 (12 Aug 2021) /tmp/idnits25907/draft-ietf-pce-segment-routing-ipv6-13.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 document date (1 April 2022) is 43 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 0 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: 3 October 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 1 April 2022 16 PCEP Extensions for Segment Routing leveraging the IPv6 data plane 17 draft-ietf-pce-segment-routing-ipv6-13 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 IGPs. 28 A Segment Routed Path can be derived from a variety of mechanisms, 29 including an IGP Shortest Path Tree (SPT), explicit configuration, or 30 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 3 October 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.3.1.2. Order of the Optional fields . . . . . . . . . . 13 94 4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 95 4.4.1. SRv6-RRO Subobject . . . . . . . . . . . . . . . . . 13 97 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 5.1. Exchanging the SRv6 Capability . . . . . . . . . . . . . 14 99 5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 16 100 5.2.1. SRv6 ERO Validation . . . . . . . . . . . . . . . . . 16 101 5.2.2. Interpreting the SRv6-ERO . . . . . . . . . . . . . . 17 102 5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 17 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17 104 7. Manageability Considerations . . . . . . . . . . . . . . . . 18 105 7.1. Control of Function and Policy . . . . . . . . . . . . . 18 106 7.2. Information and Data Models . . . . . . . . . . . . . . . 18 107 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 18 108 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 18 109 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 18 110 7.6. Impact On Network Operations . . . . . . . . . . . . . . 18 111 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 112 8.1. Cisco's Commercial Delivery . . . . . . . . . . . . . . . 19 113 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 114 9.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 19 115 9.2. New SRv6-ERO Flag Registry . . . . . . . . . . . . . . . 20 116 9.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 20 117 9.4. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 21 118 9.5. New Path Setup Type . . . . . . . . . . . . . . . . . . . 21 119 9.6. ERROR Objects . . . . . . . . . . . . . . . . . . . . . . 21 120 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 121 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 122 11.1. Normative References . . . . . . . . . . . . . . . . . . 22 123 11.2. Informative References . . . . . . . . . . . . . . . . . 24 124 Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 25 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 127 1. Introduction 129 As per [RFC8402], with Segment Routing (SR), a node steers a packet 130 through an ordered list of instructions, called segments. A segment 131 can represent any instruction, topological or service-based. A 132 segment can have a semantic local to an SR node or global within an 133 SR domain. SR allows to enforce a flow through any path and service 134 chain while maintaining per-flow state only at the ingress node of 135 the SR domain. Segments can be derived from different components: 136 IGP, BGP, Services, Contexts, Locater, etc. The list of segment 137 forming the path is called the Segment List and is encoded in the 138 packet header. Segment Routing can be applied to the IPv6 139 architecture with the Segment Routing Header (SRH) [RFC8754]. A 140 segment is encoded as an IPv6 address. An ordered list of segments 141 is encoded as an ordered list of IPv6 addresses in the routing 142 header. The active segment is indicated by the Destination Address 143 of the packet. Upon completion of a segment, a pointer in the new 144 routing header is incremented and indicates the next segment. 146 Segment Routing use cases are described in [RFC7855] and [RFC8354]. 147 Segment Routing protocol extensions are defined in [RFC8667], and 148 [RFC8666]. 150 As per [RFC8754], an SRv6 Segment is a 128-bit value. "SRv6 SID" or 151 simply "SID" are often used as a shorter reference for "SRv6 152 Segment". Further details are in an illustration provided in 153 [RFC8986]. 155 The SR architecture can be applied to the MPLS forwarding plane 156 without any change, in which case an SR path corresponds to an MPLS 157 Label Switching Path (LSP). The SR is applied to IPV6 forwarding 158 plane using SRH. A SR path can be derived from an IGP Shortest Path 159 Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may 160 be chosen by a suitable network planning tool, or a PCE and 161 provisioned on the ingress node. 163 [RFC5440] describes Path Computation Element communication Protocol 164 (PCEP) for communication between a Path Computation Client (PCC) and 165 a Path Computation Element (PCE) or between a pair of PCEs. A PCE or 166 a PCC operating as a PCE (in hierarchical PCE environment) computes 167 paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on 168 various constraints and optimization criteria. [RFC8231] specifies 169 extensions to PCEP that allow a stateful PCE to compute and recommend 170 network paths in compliance with [RFC4657] and defines objects and 171 TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide 172 synchronization of LSP state between a PCC and a PCE or between a 173 pair of PCEs, delegation of LSP control, reporting of LSP state from 174 a PCC to a PCE, controlling the setup and path routing of an LSP from 175 a PCE to a PCC. Stateful PCEP extensions are intended for an 176 operational model in which LSPs are configured on the PCC, and 177 control over them is delegated to the PCE. 179 A mechanism to dynamically initiate LSPs on a PCC based on the 180 requests from a stateful PCE or a controller using stateful PCE is 181 specified in [RFC8281]. As per [RFC8664], it is possible to use a 182 stateful PCE for computing one or more SR-TE paths taking into 183 account various constraints and objective functions. Once a path is 184 chosen, the stateful PCE can initiate an SR-TE path on a PCC using 185 PCEP extensions specified in [RFC8281] using the SR specific PCEP 186 extensions specified in [RFC8664]. [RFC8664] specifies PCEP 187 extensions for supporting a SR-TE LSP for MPLS data plane. This 188 document extends [RFC8664] to support SR for IPv6 data plane. 189 Additionally, using procedures described in this document, a PCC can 190 request an SRv6 path from either stateful or a stateless PCE. This 191 specification relies on the PATH-SETUP-TYPE TLV and procedures 192 specified in [RFC8408]. 194 This specification provides a mechanism for a network controller 195 (acting as a PCE) to instantiate candidate paths for an SR Policy 196 onto a head-end node (acting as a PCC) using PCEP. For more 197 information on the SR Policy Architecture, see 198 [I-D.ietf-spring-segment-routing-policy]. 200 2. Terminology 202 This document uses the following terms defined in [RFC5440]: PCC, 203 PCE, PCEP Peer. 205 This document uses the following terms defined in [RFC8051]: Stateful 206 PCE, Delegation. 208 The message formats in this document are specified using Routing 209 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 211 NAI: Node or Adjacency Identifier. 213 PCC: Path Computation Client. 215 PCE: Path Computation Element. 217 PCEP: Path Computation Element Protocol. 219 SR: Segment Routing. 221 SID: Segment Identifier. 223 SRv6: Segment Routing for IPv6 forwarding plane. 225 SRH: IPv6 Segment Routing Header. 227 SR Path: IPv6 Segment List (List of IPv6 SIDs representing a path in 228 IPv6 SR domain) 230 Further, note that the term LSP used in the PCEP specifications, 231 would be equivalent to a SRv6 Path (represented as a list of SRv6 232 segments) in the context of supporting SRv6 in PCEP. 234 3. Overview of PCEP Operation in SRv6 Networks 236 Basic operations for PCEP speakers is as per [RFC8664]. SRv6 Paths 237 computed by a PCE can be represented as an ordered list of SRv6 238 segments of 128-bit value. "SRv6 SID" or simply "SID" are often used 239 as a shorter reference for "SRv6 Segment" in this document. 241 [RFC8664] defined a new Explicit Route Object (ERO) subobject denoted 242 by "SR-ERO subobject" capable of carrying a SID as well as the 243 identity of the node/adjacency represented by the SID. SR-capable 244 PCEP speakers should be able to generate and/or process such ERO 245 subobject. An ERO containing SR-ERO subobjects can be included in 246 the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], 247 the PCEP LSP Initiate Request message (PCInitiate) defined in 248 [RFC8281], as well as in the PCEP LSP Update Request (PCUpd) and PCEP 249 LSP State Report (PCRpt) messages defined in defined in [RFC8231]. 251 This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in ERO 252 and RRO respectively to carry SRv6 SID (IPv6 Address). SRv6-capable 253 PCEP speakers MUST be able to generate and/or process this. 255 When a PCEP session between a PCC and a PCE is established, both PCEP 256 speakers exchange their capabilities to indicate their ability to 257 support SRv6 specific functionality. 259 In summary, this document: 261 * Defines a new PCEP capability for SRv6. 263 * Defines a new subobject SRv6-ERO in ERO. 265 * Defines a new subobject SRv6-RRO in RRO. 267 * Defines a new path setup type carried in the PATH-SETUP-TYPE TLV 268 and the PATH-SETUP-TYPE-CAPABILITY TLV. 270 3.1. Operation Overview 272 In SR networks, an ingress node of an SR path appends all outgoing 273 packets with an SR header consisting of a list of SIDs (IPv6 Prefix 274 in case of SRv6). The header has all necessary information to guide 275 the packets from the ingress node to the egress node of the path, and 276 hence there is no need for any signaling protocol. 278 For IPv6 in control plane with MPLS data-plane, mechanism remains 279 same as [RFC8664] 281 This document describes extensions to SR path for IPv6 data plane. 282 SRv6 Path (i.e. ERO) consists of an ordered set of SRv6 SIDs(see 283 details in Figure 2). 285 A PCC or PCE indicates its ability to support SRv6 during the PCEP 286 session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV 287 (see details in Section 4.1.1). 289 3.2. SRv6-Specific PCEP Message Extensions 291 As defined in [RFC5440], a PCEP message consists of a common header 292 followed by a variable length body made up of mandatory and/or 293 optional objects. This document does not require any changes in the 294 format of PCReq and PCRep messages specified in [RFC5440], PCInitiate 295 message specified in [RFC8281], and PCRpt and PCUpd messages 296 specified in [RFC8231]. However, PCEP messages pertaining to SRv6 297 MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly 298 identify that SRv6 is intended. 300 4. Object Formats 302 4.1. The OPEN Object 304 4.1.1. The SRv6 PCE Capability sub-TLV 306 This document defines a new Path Setup Type (PST) [RFC8408] for SRv6, 307 as follows: 309 * PST = 3 (early allocated by IANA): Path is setup using SRv6. 311 A PCEP speaker MUST indicate its support of the function described in 312 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 313 object with this new PST included in the PST list. 315 This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP 316 speakers use this sub-TLV to exchange information about their SRv6 317 capability. If a PCEP speaker includes PST=3 (early allocated by 318 IANA) in the PST List of the PATH-SETUP-TYPE-CAPABILITY TLV then it 319 MUST also include the SRv6-PCE-CAPABILITY sub-TLV inside the PATH- 320 SETUP-TYPE-CAPABILITY TLV. 322 The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the 323 following figure: 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type=27 | Length | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Reserved | Flags |N|X| 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | MSD-Type | MSD-Value | MSD-Type | MSD-Value | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 // ... // 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | MSD-Type | MSD-Value | Padding | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Figure 1: SRv6-PCE-CAPABILITY sub-TLV format 341 The code point for the TLV type (27)(early allocated by IANA) is to 342 be defined by IANA. The TLV length is variable. 344 The value comprises of - 346 Reserved: 2 octet, this field MUST be set to 0 on transmission, 347 and ignored on receipt. 349 Flags: 2 octet, two bits are currently assigned in this document. 351 - N bit: A PCC sets this flag bit to 1 to indicate that it is 352 capable of resolving a Node or Adjacency Identifier (NAI) to a 353 SRv6-SID. 355 - X bit: A PCC sets this bit to 1 to indicate that it does not 356 impose any limit on MSD (irrespective of the MSD-Type). 358 - Unassigned bits MUST be set to 0 and ignored on receipt. 360 A pair of (MSD-Type, MSD-Value): Where MSD-Type (1 octet) is as 361 per the IGP MSD Type registry created by [RFC8491] and populated 362 with SRv6 MSD types as per [I-D.ietf-lsr-isis-srv6-extensions]; 363 MSD-Value (1 octet) is as per [RFC8491]. 365 This sub-TLV format is compliant with the PCEP TLV format defined in 366 [RFC5440]. That is, the sub-TLV is composed of 2 octets for the 367 type, 2 octets specifying the length, and a Value field. The Type 368 field when set to 27 (early allocated by IANA) identifies the SRv6- 369 PCE-CAPABILITY sub-TLV and the presence of the sub-TLV indicates the 370 support for the SRv6 paths in PCEP. The Length field defines the 371 length of the value portion in octets. The TLV is padded to 4-octet 372 alignment, and padding is not included in the Length field. The 373 number of (MSD-Type,MSD-Value) pairs can be determined from the 374 Length field of the TLV. 376 4.2. The RP/SRP Object 378 In order to indicate the SRv6 path, RP or SRP object MUST include the 379 PATH-SETUP-TYPE TLV specified in [RFC8408]. This document defines a 380 new Path Setup Type (PST=3(early allocated by IANA)) for SRv6. 382 The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 384 4.3. ERO 386 In order to support SRv6, new subobject "SRv6-ERO" is defined in ERO. 388 4.3.1. SRv6-ERO Subobject 390 An SRv6-ERO subobject is formatted as shown in the following figure. 392 0 1 2 3 393 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 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 |L| Type=40 | Length | NT | Flags |V|T|F|S| 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | Reserved | Endpoint Behavior | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 | | 400 | SRv6 SID (optional) | 401 | (128-bit) | 402 | | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 // NAI (variable, optional) // 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | SID Structure (optional) | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 Figure 2: SRv6-ERO Subobject Format 411 The fields in the SRv6-ERO Subobject are as follows: 413 The 'L' Flag: Indicates whether the subobject represents a loose-hop 414 (see [RFC3209]). If this flag is set to zero, a PCC MUST NOT 415 overwrite the SID value present in the SRv6-ERO subobject. 416 Otherwise, a PCC MAY expand or replace one or more SID values in the 417 received SRv6-ERO based on its local policy. 419 Type: indicates the content of the subobject, i.e. when the field is 420 set to 40 (early allocated by IANA), the suboject is a SRv6-ERO 421 subobject representing a SRv6 SID. 423 Length: Contains the total length of the subobject in octets. The 424 Length MUST be at least 24, and MUST be a multiple of 4. An SRv6-ERO 425 subobject MUST contain at least one of a SRv6-SID or an NAI. The S 426 and F bit in the Flags field indicates whether the SRv6-SID or NAI 427 fields are absent. 429 NAI Type (NT): Indicates the type and format of the NAI contained in 430 the object body, if any is present. If the F bit is set to one (see 431 below) then the NT field has no meaning and MUST be ignored by the 432 receiver. This document reuses NT types defined in [RFC8664]: 434 If NT value is 0, the NAI MUST NOT be included. 436 When NT value is 2, the NAI is as per the 'IPv6 Node ID' format 437 defined in [RFC8664], which specifies an IPv6 address. This is 438 used to identify the owner of the SRv6 Identifier. This is 439 optional, as the LOC (the locater portion) of the SRv6 SID serves 440 a similar purpose (when present). 442 When NT value is 4, the NAI is as per the 'IPv6 Adjacency' format 443 defined in [RFC8664], which specify a pair of IPv6 addresses. 444 This is used to identify the IPv6 Adjacency and used with the SRv6 445 Adj-SID. 447 When NT value is 6, the NAI is as per the 'link-local IPv6 448 addresses' format defined in [RFC8664], which specify a pair of 449 (global IPv6 address, interface ID) tuples. It is used to 450 identify the IPv6 Adjacency and used with the SRv6 Adj-SID. 452 SR-MPLS specific NT types are not valid in SRv6-ERO. 454 Flags: Used to carry additional information pertaining to the 455 SRv6-SID. This document defines the following flag bits. The other 456 bits MUST be set to zero by the sender and MUST be ignored by the 457 receiver. 459 * S: When this bit is set to 1, the SRv6-SID value in the subobject 460 body is absent. In this case, the PCC is responsible for choosing 461 the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI 462 which, in this case, MUST be present in the subobject. If the S 463 bit is set to 1 then F bit MUST be set to zero. 465 * F: When this bit is set to 1, the NAI value in the subobject body 466 is absent. The F bit MUST be set to 1 if NT=0, and otherwise MUST 467 be set to zero. The S and F bits MUST NOT both be set to 1. 469 * T: When this bit is set to 1, the SID Structure value in the 470 subobject body is present. The T bit MUST be set to 0 when S bit 471 is set to 1. If the T bit is set when the S bit is set, the T bit 472 MUST be ignored. Thus, the T bit indicates the presence of an 473 optional 8-byte SID Structure when SRv6 SID is included. The SID 474 Structure is defined in Section 4.3.1.1. 476 * V: The "SID verification" bit usage is as per Section 5.1 of 477 [I-D.ietf-spring-segment-routing-policy]. 479 Reserved: MUST be set to zero while sending and ignored on receipt. 481 Endpoint Behavior: A 16 bit field representing the behavior 482 associated with the SRv6 SIDs. This information is optional and 483 plays no role in the fields in SRH imposed on the packet. It could 484 be used for maintainability and diagnostic purpose. If behavior is 485 not known, 0 is used. The list of Endpoint behavior are defined in 486 [RFC8986]. 488 SRv6 SID: SRv6 Identifier is the 128 bit IPv6 addresses representing 489 the SRv6 segment. 491 NAI: The NAI associated with the SRv6-SID. The NAI's format depends 492 on the value in the NT field, and is described in [RFC8664]. 494 At least one of the SRv6-SID or the NAI MUST be included in the 495 SRv6-ERO subobject, and both MAY be included. 497 4.3.1.1. SID Structure 499 The SID Structure is an optional part of the SR-ERO subobject, as 500 described in Section 4.3.1. 502 [RFC8986] defines an SRv6 SID as consisting of LOC:FUNCT:ARG, where a 503 locator (LOC) is encoded in the L most significant bits of the SID, 504 followed by F bits of function (FUNCT) and A bits of arguments (ARG). 505 A locator may be represented as B:N where B is the SRv6 SID locator 506 block (IPv6 prefix allocated for SRv6 SIDs by the operator) and N is 507 the identifier of the parent node instantiating the SID called 508 locator node. 510 It is formatted as shown in the following figure. 512 0 1 2 3 513 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 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | LB Length | LN Length | Fun. Length | Arg. Length | 516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 | Reserved | Flags | 518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 Figure 3: SID Structure Format 522 where: 524 LB Length: 1 octet. SRv6 SID Locator Block length in bits. 526 LN Length: 1 octet. SRv6 SID Locator Node length in bits. 528 Fun. Length: 1 octet. SRv6 SID Function length in bits. 530 Arg. Length: 1 octet. SRv6 SID Arguments length in bits. 532 The sum of all four sizes in the SID Structure must be lower or equal 533 to 128 bits. If the sum of all four sizes advertised in the SID 534 Structure is larger than 128 bits, the corresponding SRv6 SID MUST be 535 considered invalid and a PCErr message with Error-Type = 10 536 ("Reception of an invalid object") and Error-Value = 37 (early 537 allocated by IANA) ("Invalid SRv6 SID Structure") is returned. 539 Reserved: MUST be set to zero while sending and ignored on receipt. 541 Flags: Currently no flags are defined. Unassigned bits must be set 542 to zero while sending and ignored on receipt. 544 The SRv6 SID Structure provides the detailed encoding information of 545 an SRv6 SID, which is useful in the use cases that require to know 546 the SRv6 SID structure. When a PCEP speaker receives the SRv6 SID 547 and its structure information, the SRv6 SID can be parsed based on 548 the SRv6 SID Structure and/or possible local policies. The SRv6 SID 549 Structure could be used by the PCE for ease of operations and 550 monitoring. For example, this information could be used for 551 validation of SRv6 SIDs being instantiated in the network and checked 552 for conformance to the SRv6 SID allocation scheme chosen by the 553 operator as described in Section 3.2 of [RFC8986]. In the future, 554 PCE could also be used for verification and the automation for 555 securing the SRv6 domain by provisioning filtering rules at SR domain 556 boundaries as described in Section 5 of [RFC8754]. The details of 557 these potential applications are outside the scope of this document. 559 4.3.1.2. Order of the Optional fields 561 The optional elements in the SRv6-ERO subobject i.e. SRv6 SID, NAI 562 and the SID Structure MUST be encoded in the order as depicted in 563 Figure 2. The presence of each of them is indicated by the 564 respective flags i.e. S flag, F flag and T flag. 566 To allow for future compatibility, any optional element added to the 567 SRv6-ERO subobject in future MUST specify the order of the optional 568 element and request IANA to allocate a flag to indicate its presence 569 from the subregistry created in Section 9.2. 571 4.4. RRO 573 In order to support SRv6, new subobject "SRv6-RRO" is defined in RRO. 575 4.4.1. SRv6-RRO Subobject 577 A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per 578 [RFC8231]. The RRO on this message represents the SID list that was 579 applied by the PCC, that is, the actual path taken. The procedures 580 of [RFC8664] with respect to the RRO apply equally to this 581 specification without change. 583 An RRO contains one or more subobjects called "SRv6-RRO subobjects" 584 whose format is shown below: 586 0 1 2 3 587 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 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 589 | Type=40 | Length | NT | Flags |V|T|F|S| 590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 591 | Reserved | Endpoint Behavior | 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 | | 594 | SRv6 SID | 595 | (128-bit) | 596 | | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 // NAI (variable) // 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | SID Structure (optional) | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 Figure 4: SRv6-RRO Subobject Format 605 The format of the SRv6-RRO subobject is the same as that of the 606 SRv6-ERO subobject, but without the L flag. 608 The V flag has no meaning in the SRv6-RRO and is ignored on receipt 609 at the PCE. 611 Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as 612 per [RFC8664]. 614 The ordering of optional elements in the SRv6-RRO subobject as same 615 as described in Section 4.3.1.2. 617 5. Procedures 619 5.1. Exchanging the SRv6 Capability 621 A PCC indicates that it is capable of supporting the head-end 622 functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in 623 the Open message that it sends to a PCE. A PCE indicates that it is 624 capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY 625 sub-TLV in the Open message that it sends to a PCC. 627 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 628 PST list containing PST=3 (early allocated by IANA), but the SRv6- 629 PCE-CAPABILITY sub-TLV is absent, then the PCEP speaker MUST send a 630 PCErr message with Error- Type 10 (Reception of an invalid object) 631 and Error-Value 34 (early allocated by IANA) (Missing PCE- 632 SRv6-CAPABILITY sub-TLV) and MUST then close the PCEP session. If a 633 PCEP speaker receives a PATH-SETUP- TYPE-CAPABILITY TLV with a SRv6- 634 PCE-CAPABILITY sub-TLV, but the PST list does not contain PST=3 635 (early allocated by IANA), then the PCEP speaker MUST ignore the 636 SRv6-PCE-CAPABILITY sub-TLV. 638 The number of SRv6 SIDs that can be imposed on a packet depends on 639 the PCC's IPv6 data plane's capability. If a PCC sets the X flag to 640 1 then the MSD is not used and MUST NOT be included. If a PCE 641 receives an SRv6-PCE-CAPABILITY sub-TLV with the X flag set to 1 then 642 it MUST ignore any MSD-Type, MSD-Value fields and MUST assume that 643 the sender can impose any length of SRH. If a PCC sets the X flag to 644 zero, then it sets the SRv6 MSD-Type, MSD-Value fields that it can 645 impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV 646 with the X flag and SRv6 MSD-Type, MSD-Value fields both set to zero 647 then it is considered as an error and the PCE MUST respond with a 648 PCErr message (Error-Type=1 "PCEP session establishment failure" and 649 Error-Value=1 "reception of an invalid Open message or a non Open 650 message."). In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV 651 received by the PCE does not correspond to one of the SRv6 MSD types, 652 the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session 653 establishment failure" and Error-Value=1 "reception of an invalid 654 Open message or a non Open message."). 656 Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE- 657 CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the 658 PCC node. However, if a PCE learns these via different means, e.g 659 routing protocols, as specified in: 660 [I-D.ietf-lsr-ospfv3-srv6-extensions]; 661 [I-D.ietf-lsr-isis-srv6-extensions]; [I-D.ietf-idr-bgpls-srv6-ext], 662 then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV. 663 Furthermore, whenever a PCE learns the other advanced SRv6 MSD via 664 different means, it MUST use that value regardless of the values 665 exchanged in the SRv6-PCE-CAPABILITY sub-TLV. 667 Once an SRv6-capable PCEP session is established with a non-zero SRv6 668 MSD value, the corresponding PCE MUST NOT send SRv6 paths with a 669 number of SIDs exceeding that SRv6 MSD value (based on the SRv6 MSD 670 Type). If a PCC needs to modify the SRv6 MSD value, it MUST close 671 the PCEP session and re-establish it with the new value. If a PCEP 672 session is established with a non-zero SRv6 MSD value, and the PCC 673 receives an SRv6 path containing more SIDs than specified in the SRv6 674 MSD value (based on the SRv6 MSD type), the PCC MUST send a PCErr 675 message with Error-Type 10 (Reception of an invalid object) and 676 Error-Value 3 (Unsupported number of Segment ERO subobjects). If a 677 PCEP session is established with an SRv6 MSD value of zero, then the 678 PCC MAY specify an SRv6 MSD for each path computation request that it 679 sends to the PCE, by including a "maximum SID depth" metric object on 680 the request similar to [RFC8664]. 682 The N flag, X flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE- 683 CAPABILITY sub-TLV are meaningful only in the Open message sent from 684 a PCC to a PCE. As such, a PCE MUST set the flags to zero and not 685 include any (MSD-Type,MSD-Value) pair in the SRv6-PCE-CAPABILITY sub- 686 TLV in an outbound message to a PCC. Similarly, a PCC MUST ignore 687 N,X flag and any (MSD-Type,MSD-Value) pair received from a PCE. If a 688 PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open 689 message, it processes only the first sub-TLV received. 691 5.2. ERO Processing 693 The ERO processing remains as per [RFC5440] and [RFC8664]. 695 5.2.1. SRv6 ERO Validation 697 If a PCC does not support the SRv6 PCE Capability and thus cannot 698 recognize the SRv6-ERO or SRv6-RRO subobjects, it will respond 699 according to the rules for a malformed object per [RFC5440]. 701 On receiving an SRv6-ERO, a PCC MUST validate that the Length field, 702 the S bit, the F bit, the T bit, and the NT field are consistent, as 703 follows. 705 * If NT=0, the F bit MUST be 1, the S bit MUST be zero and the 706 Length MUST be 24. 708 * If NT=2, the F bit MUST be zero. If the S bit is 1, the Length 709 MUST be 24, otherwise the Length MUST be 40. 711 * If NT=4, the F bit MUST be zero. If the S bit is 1, the Length 712 MUST be 40, otherwise the Length MUST be 56. 714 * If NT=6, the F bit MUST be zero. If the S bit is 1, the Length 715 MUST be 48, otherwise the Length MUST be 64. 717 * NT types (1,3, and 5) are not valid for SRv6. 719 * If T bit is 1, then S bit MUST be zero. 721 If a PCC finds that the NT field, Length field, S bit, F bit, and T 722 bit are not consistent, it MUST consider the entire ERO invalid and 723 MUST send a PCErr message with Error-Type = 10 ("Reception of an 724 invalid object") and Error-Value = 11 ("Malformed object"). 726 If a PCEP speaker that does not recognize the NT value received in 727 SRv6-ERO subobject, it would behave as per [RFC8664]. 729 In case a PCEP speaker receives the SRv6-ERO subobject, when the PST 730 is not set to 3 (early allocated by IANA) or SRv6-PCE-CAPABILITY sub- 731 TLV was not exchanged, it MUST send a PCErr message with Error-Type = 732 19 ("Invalid Operation") and Error-Value = 19 (early allocated by 733 IANA) ("Attempted SRv6 when the capability was not advertised"). 735 If a PCC receives a list of SRv6 segments, and the number of SRv6 736 segments exceeds the SRv6 MSD that the PCC can impose on the packet 737 (SRH), it MUST send a PCErr message with Error-Type = 10 ("Reception 738 of an invalid object") and Error-Value = 3 ("Unsupported number of 739 SR-ERO subobjects") as per [RFC8664]. 741 When a PCEP speaker detects that all subobjects of ERO are not of 742 type 40 (early allocated by IANA), and if it does not handle such 743 ERO, it MUST send a PCErr message with Error-Type = 10 ("Reception of 744 an invalid object") and Error-Value = 20 ("Inconsistent SIDs in SR- 745 ERO / SR-RRO subobjects") as per [RFC8664]. 747 5.2.2. Interpreting the SRv6-ERO 749 The SRv6-ERO contains a sequence of subobjects. According to 750 [I-D.ietf-spring-segment-routing-policy], each SRv6-ERO subobject in 751 the sequence identifies a segment that the traffic will be directed 752 to, in the order given. That is, the first subobject identifies the 753 first segment the traffic will be directed to, the second SRv6-ERO 754 subobject represents the second segment, and so on. 756 The PCC interprets the SRv6-ERO by converting it to an SRv6 SRH plus 757 a next hop. The PCC sends packets along the segment routed path by 758 prepending the SRH onto the packets and sending the resulting, 759 modified packet to the next hop. 761 5.3. RRO Processing 763 The syntax checking rules that apply to the SRv6-RRO subobject are 764 identical to those of the SRv6-ERO subobject, except as noted below. 766 If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6 767 SID and NAI are absent, it MUST consider the entire RRO invalid and 768 send a PCErr message with Error-Type = 10 ("Reception of an invalid 769 object") and Error-Value = 35 (early allocated by IANA) ("Both SID 770 and NAI are absent in SRv6-RRO subobject"). 772 If a PCE detects that the subobjects of an RRO are a mixture of 773 SRv6-RRO subobjects and subobjects of other types, then it MUST send 774 a PCErr message with Error-Type = 10 ("Reception of an invalid 775 object") and Error-Value = 36 (early allocated by IANA) ("RRO mixes 776 SRv6-RRO subobjects with other subobject types"). 778 6. Security Considerations 780 The security considerations described in [RFC5440], [RFC8231] and 781 [RFC8281], [RFC8664], are applicable to this specification. No 782 additional security measure is required. 784 7. Manageability Considerations 786 All manageability requirements and considerations listed in 787 [RFC5440], [RFC8231], and [RFC8664] apply to PCEP protocol extensions 788 defined in this document. In addition, requirements and 789 considerations listed in this section apply. 791 7.1. Control of Function and Policy 793 A PCEP implementation SHOULD allow the operator to configure the 794 policy based on which it allocates the SIDs. 796 7.2. Information and Data Models 798 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. An 799 implementation SHOULD allow the operator to view the SIDs allocated 800 to the LSP for the SR path. 802 7.3. Liveness Detection and Monitoring 804 Mechanisms defined in this document do not imply any new liveness 805 detection and monitoring requirements in addition to those already 806 listed in [RFC5440]. 808 7.4. Verify Correct Operations 810 Mechanisms defined in this document do not imply any new operation 811 verification requirements in addition to those already listed in 812 [RFC5440], [RFC8231], and [RFC8664] . 814 7.5. Requirements On Other Protocols 816 Mechanisms defined in this document do not imply any new requirements 817 on other protocols. 819 7.6. Impact On Network Operations 821 Mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also apply 822 to PCEP extensions defined in this document. 824 8. Implementation Status 826 [Note to the RFC Editor - remove this section before publication, as 827 well as remove the reference to [RFC7942]. 829 This section records the status of known implementations of the 830 protocol defined by this specification at the time of posting of this 831 Internet-Draft, and is based on a proposal described in [RFC7942]. 832 The description of implementations in this section is intended to 833 assist the IETF in its decision processes in progressing drafts to 834 RFCs. Please note that the listing of any individual implementation 835 here does not imply endorsement by the IETF. Furthermore, no effort 836 has been spent to verify the information presented here that was 837 supplied by IETF contributors. This is not intended as, and must not 838 be construed to be, a catalog of available implementations or their 839 features. Readers are advised to note that other implementations may 840 exist. 842 According to [RFC7942], "this will allow reviewers and working groups 843 to assign due consideration to documents that have the benefit of 844 running code, which may serve as evidence of valuable experimentation 845 and feedback that have made the implemented protocols more mature. 846 It is up to the individual working groups to use this information as 847 they see fit". 849 8.1. Cisco's Commercial Delivery 851 * Organization: Cisco Systems, Inc. 853 * Implementation: IOS-XR PCE and PCC. 855 * Description: Implementation with experimental codepoints. 857 * Maturity Level: Production 859 * Coverage: Partial 861 * Contact: ssidor@cisco.com 863 9. IANA Considerations 865 9.1. PCEP ERO and RRO subobjects 867 This document defines a new subobject type for the PCEP explicit 868 route object (ERO), and a new subobject type for the PCEP record 869 route object (RRO). The code points for subobject types of these 870 objects is maintained in the RSVP parameters registry, under the 871 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to 872 confirm the following early allocations in the RSVP Parameters 873 registry for each of the new subobject types defined in this 874 document. 876 Object Subobject Subobject Type 877 --------------------- -------------------------- ------------------ 878 EXPLICIT_ROUTE SRv6-ERO (PCEP-specific) 40 879 ROUTE_RECORD SRv6-RRO (PCEP-specific) 40 881 9.2. New SRv6-ERO Flag Registry 883 IANA is requested to create a new sub-registry, named "SRv6-ERO Flag 884 Field", within the "Path Computation Element Protocol (PCEP) Numbers" 885 registry to manage the Flag field of the SRv6-ERO subobject. New 886 values are to be assigned by Standards Action [RFC8126]. Each bit 887 should be tracked with the following qualities: 889 * Bit number (counting from bit 0 as the most significant bit) 891 * Capability description 893 * Defining RFC 895 The following values are defined in this document: 897 Bit Description Reference 898 ----- ------------------ -------------- 899 0-7 Unassigned 900 8 SID Verification (V) This document 901 9 SID Structure is This document 902 present (T) 903 10 NAI is absent (F) This document 904 11 SID is absent (S) This document 906 9.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 908 IANA maintains a sub-registry, named "PATH-SETUP-TYPE-CAPABILITY Sub- 909 TLV Type Indicators", within the "Path Computation Element Protocol 910 (PCEP) Numbers" registry to manage the type indicator space for sub- 911 TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA is requested to 912 confirm the following early allocations in the sub-registry: 914 Value Meaning Reference 915 ----- ------- --------- 916 27 SRv6-PCE-CAPABILITY This Document 918 9.4. SRv6 PCE Capability Flags 920 IANA is requested to create a new sub-registry, named "SRv6 921 Capability Flag Field", within the "Path Computation Element Protocol 922 (PCEP) Numbers" registry to manage the Flag field of the SRv6-PCE- 923 CAPABILITY sub-TLV. New values are to be assigned by Standards 924 Action [RFC8126]. Each bit should be tracked with the following 925 qualities: 927 * Bit number (counting from bit 0 as the most significant bit) 929 * Capability description 931 * Defining RFC 933 The following values are defined in this document: 935 Bit Description Reference 937 0-13 Unassigned 938 14 Node or Adjacency This document 939 Identifier (NAI) is 940 supported (N) 941 15 Unlimited Maximum SID This document 942 Depth (X) 944 9.5. New Path Setup Type 946 [RFC8408] created a sub-registry within the "Path Computation Element 947 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 948 IANA is requested to confirm the following early allocations in the 949 sub-registry: 951 Value Description Reference 952 ----- ----------- --------- 953 3 Traffic engineering path is This Document 954 setup using SRv6. 956 9.6. ERROR Objects 958 IANA is requested to confirm the following early allocations in the 959 PCEP-ERROR Object Error Types and Values registry for the following 960 new error-values: 962 Error-Type Meaning 963 ---------- ------- 964 10 Reception of an invalid object 965 Error-value = 34 (Missing 966 PCE-SRv6-CAPABILITY sub-TLV) 967 Error-value = 35 (Both SID and NAI are absent 968 in SRv6-RRO subobject) 969 Error-value = 36 (RRO mixes SRv6-RRO subobjects 970 with other subobject types) 971 Error-value = 37 (Invalid SRv6 SID Structure) 972 19 Invalid Operation 973 Error-value = 19 (Attempted SRv6 when the 974 capability was not advertised) 976 10. Acknowledgements 978 The authors would like to thank Jeff Tantsura, Adrian Farrel, Aijun 979 Wang, Khasanov Boris, and Robert Varga for valuable suggestions. 981 11. References 983 11.1. Normative References 985 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 986 Requirement Levels", BCP 14, RFC 2119, 987 DOI 10.17487/RFC2119, March 1997, 988 . 990 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 991 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 992 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 993 . 995 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 996 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 997 DOI 10.17487/RFC5440, March 2009, 998 . 1000 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 1001 Used to Form Encoding Rules in Various Routing Protocol 1002 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 1003 2009, . 1005 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1006 Writing an IANA Considerations Section in RFCs", BCP 26, 1007 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1008 . 1010 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1011 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1012 May 2017, . 1014 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1015 Computation Element Communication Protocol (PCEP) 1016 Extensions for Stateful PCE", RFC 8231, 1017 DOI 10.17487/RFC8231, September 2017, 1018 . 1020 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1021 Computation Element Communication Protocol (PCEP) 1022 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1023 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1024 . 1026 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1027 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1028 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1029 July 2018, . 1031 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 1032 Hardwick, "Conveying Path Setup Type in PCE Communication 1033 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 1034 July 2018, . 1036 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 1037 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 1038 DOI 10.17487/RFC8491, November 2018, 1039 . 1041 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1042 and J. Hardwick, "Path Computation Element Communication 1043 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1044 DOI 10.17487/RFC8664, December 2019, 1045 . 1047 [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, 1048 D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 1049 (SRv6) Network Programming", RFC 8986, 1050 DOI 10.17487/RFC8986, February 2021, 1051 . 1053 [I-D.ietf-lsr-isis-srv6-extensions] 1054 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 1055 Z. Hu, "IS-IS Extensions to Support Segment Routing over 1056 IPv6 Dataplane", Work in Progress, Internet-Draft, draft- 1057 ietf-lsr-isis-srv6-extensions-18, 20 October 2021, 1058 . 1061 11.2. Informative References 1063 [RFC4657] Ash, J., Ed. and J.L. Le Roux, Ed., "Path Computation 1064 Element (PCE) Communication Protocol Generic 1065 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1066 2006, . 1068 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1069 Code: The Implementation Status Section", BCP 205, 1070 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1071 . 1073 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 1074 Litkowski, S., Horneffer, M., and R. Shakir, "Source 1075 Packet Routing in Networking (SPRING) Problem Statement 1076 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 1077 2016, . 1079 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 1080 Stateful Path Computation Element (PCE)", RFC 8051, 1081 DOI 10.17487/RFC8051, January 2017, 1082 . 1084 [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., 1085 Ed., and M. Townsley, "Use Cases for IPv6 Source Packet 1086 Routing in Networking (SPRING)", RFC 8354, 1087 DOI 10.17487/RFC8354, March 2018, 1088 . 1090 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 1091 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 1092 December 2019, . 1094 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 1095 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 1096 Extensions for Segment Routing", RFC 8667, 1097 DOI 10.17487/RFC8667, December 2019, 1098 . 1100 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 1101 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 1102 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 1103 . 1105 [I-D.ietf-spring-segment-routing-policy] 1106 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1107 P. Mattes, "Segment Routing Policy Architecture", Work in 1108 Progress, Internet-Draft, draft-ietf-spring-segment- 1109 routing-policy-22, 22 March 2022, 1110 . 1113 [I-D.ietf-lsr-ospfv3-srv6-extensions] 1114 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 1115 "OSPFv3 Extensions for SRv6", Work in Progress, Internet- 1116 Draft, draft-ietf-lsr-ospfv3-srv6-extensions-03, 19 1117 November 2021, . 1120 [I-D.ietf-idr-bgpls-srv6-ext] 1121 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 1122 Bernier, D., and B. Decraene, "BGP Link State Extensions 1123 for SRv6", Work in Progress, Internet-Draft, draft-ietf- 1124 idr-bgpls-srv6-ext-09, 10 November 2021, 1125 . 1128 [I-D.ietf-pce-pcep-yang] 1129 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 1130 "A YANG Data Model for Path Computation Element 1131 Communications Protocol (PCEP)", Work in Progress, 1132 Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January 1133 2022, . 1136 Appendix A. Contributor 1138 The following persons contributed to this document: 1140 Dhruv Dhody 1141 Huawei Technologies 1142 Divyashree Techno Park, Whitefield 1143 Bangalore, Karnataka 560066 1144 India 1146 EMail: dhruv.ietf@gmail.com 1148 Huang Wumin 1149 Huawei Technologies 1150 Huawei Building, No. 156 Beiqing Rd. 1151 Beijing 100095 1152 China 1154 Email: huangwumin@huawei.com 1156 Shuping Peng 1157 Huawei Technologies 1158 Huawei Building, No. 156 Beiqing Rd. 1159 Beijing 100095 1160 China 1162 Email: pengshuping@huawei.com 1164 Authors' Addresses 1166 Cheng Li(Editor) 1167 Huawei Technologies 1168 Huawei Campus, No. 156 Beiqing Rd. 1169 Beijing 1170 100095 1171 China 1172 Email: c.l@huawei.com 1174 Mahendra Singh Negi 1175 RtBrick Inc 1176 Bangalore 1177 Karnataka 1178 India 1179 Email: mahend.ietf@gmail.com 1181 Siva Sivabalan 1182 Ciena Corporation 1183 Email: msiva282@gmail.com 1184 Mike Koldychev 1185 Cisco Systems, Inc. 1186 Canada 1187 Email: mkoldych@cisco.com 1189 Prejeeth Kaladharan 1190 RtBrick Inc 1191 Bangalore 1192 Karnataka 1193 India 1194 Email: prejeeth@rtbrick.com 1196 Yongqing Zhu 1197 China Telecom 1198 109 West Zhongshan Ave, Tianhe District 1199 Bangalore 1200 Guangzhou, 1201 P.R. China 1202 Email: zhuyq8@chinatelecom.cn