idnits 2.17.1 draft-ietf-pce-segment-routing-ipv6-08.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 (November 24, 2020) is 1242 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-11 == Outdated reference: A later version (-28) exists of draft-ietf-spring-srv6-network-programming-24 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-09 == Outdated reference: A later version (-15) exists of draft-ietf-lsr-ospfv3-srv6-extensions-01 == Outdated reference: A later version (-14) exists of draft-ietf-idr-bgpls-srv6-ext-05 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: May 28, 2021 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 November 24, 2020 16 PCEP Extensions for Segment Routing leveraging the IPv6 data plane 17 draft-ietf-pce-segment-routing-ipv6-08 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 May 28, 2021. 65 Copyright Notice 67 Copyright (c) 2020 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 72 (https://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with respect 75 to this document. Code Components extracted from this document must 76 include Simplified BSD License text as described in Section 4.e of 77 the Trust Legal Provisions and are provided without warranty as 78 described in the Simplified BSD License. 80 Table of Contents 82 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 83 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 84 3. Overview of PCEP Operation in SRv6 Networks . . . . . . . . . 5 85 3.1. Operation Overview . . . . . . . . . . . . . . . . . . . 6 86 3.2. SRv6-Specific PCEP Message Extensions . . . . . . . . . . 6 87 4. Object Formats . . . . . . . . . . . . . . . . . . . . . . . 7 88 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 7 89 4.1.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 7 90 4.2. The RP/SRP Object . . . . . . . . . . . . . . . . . . . . 8 91 4.3. ERO . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 92 4.3.1. SRv6-ERO Subobject . . . . . . . . . . . . . . . . . 9 93 4.3.1.1. SID Structure . . . . . . . . . . . . . . . . . . 11 94 4.4. RRO . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 4.4.1. SRv6-RRO Subobject . . . . . . . . . . . . . . . . . 12 97 5. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 13 98 5.1. Exchanging the SRv6 Capability . . . . . . . . . . . . . 13 99 5.2. ERO Processing . . . . . . . . . . . . . . . . . . . . . 15 100 5.2.1. SRv6 ERO Validation . . . . . . . . . . . . . . . . . 15 101 5.2.2. Interpreting the SRv6-ERO . . . . . . . . . . . . . . 16 102 5.3. RRO Processing . . . . . . . . . . . . . . . . . . . . . 16 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 105 7.1. PCEP ERO and RRO subobjects . . . . . . . . . . . . . . . 17 106 7.2. New SRv6-ERO Flag Registry . . . . . . . . . . . . . . . 17 107 7.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators . . . 18 108 7.4. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 18 109 7.5. New Path Setup Type . . . . . . . . . . . . . . . . . . . 18 110 7.6. ERROR Objects . . . . . . . . . . . . . . . . . . . . . . 19 111 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 112 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 113 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 114 9.2. Informative References . . . . . . . . . . . . . . . . . 21 115 Appendix A. Contributor . . . . . . . . . . . . . . . . . . . . 23 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 118 1. Introduction 120 As per [RFC8402], with Segment Routing (SR), a node steers a packet 121 through an ordered list of instructions, called segments. A segment 122 can represent any instruction, topological or service-based. A 123 segment can have a semantic local to an SR node or global within an 124 SR domain. SR allows to enforce a flow through any path and service 125 chain while maintaining per-flow state only at the ingress node of 126 the SR domain. Segments can be derived from different components: 127 IGP, BGP, Services, Contexts, Locater, etc. The list of segment 128 forming the path is called the Segment List and is encoded in the 129 packet header. Segment Routing can be applied to the IPv6 130 architecture with the Segment Routing Header (SRH) [RFC8754]. A 131 segment is encoded as an IPv6 address. An ordered list of segments 132 is encoded as an ordered list of IPv6 addresses in the routing 133 header. The active segment is indicated by the Destination Address 134 of the packet. Upon completion of a segment, a pointer in the new 135 routing header is incremented and indicates the next segment. 137 Segment Routing use cases are described in [RFC7855] and [RFC8354]. 138 Segment Routing protocol extensions are defined in [RFC8667], and 139 [RFC8666]. 141 As per [RFC8754], an SRv6 Segment is a 128-bit value. "SRv6 SID" or 142 simply "SID" are often used as a shorter reference for "SRv6 143 Segment". Further details are in an illustration provided in 144 [I-D.ietf-spring-srv6-network-programming]. 146 The SR architecture can be applied to the MPLS forwarding plane 147 without any change, in which case an SR path corresponds to an MPLS 148 Label Switching Path (LSP). The SR is applied to IPV6 forwarding 149 plane using SRH. A SR path can be derived from an IGP Shortest Path 150 Tree (SPT), but SR-TE paths may not follow IGP SPT. Such paths may 151 be chosen by a suitable network planning tool, or a PCE and 152 provisioned on the ingress node. 154 [RFC5440] describes Path Computation Element communication Protocol 155 (PCEP) for communication between a Path Computation Client (PCC) and 156 a Path Computation Element (PCE) or between a pair of PCEs. A PCE or 157 a PCC operating as a PCE (in hierarchical PCE environment) computes 158 paths for MPLS Traffic Engineering LSPs (MPLS-TE LSPs) based on 159 various constraints and optimization criteria. [RFC8231] specifies 160 extensions to PCEP that allow a stateful PCE to compute and recommend 161 network paths in compliance with [RFC4657] and defines objects and 162 TLVs for MPLS-TE LSPs. Stateful PCEP extensions provide 163 synchronization of LSP state between a PCC and a PCE or between a 164 pair of PCEs, delegation of LSP control, reporting of LSP state from 165 a PCC to a PCE, controlling the setup and path routing of an LSP from 166 a PCE to a PCC. Stateful PCEP extensions are intended for an 167 operational model in which LSPs are configured on the PCC, and 168 control over them is delegated to the PCE. 170 A mechanism to dynamically initiate LSPs on a PCC based on the 171 requests from a stateful PCE or a controller using stateful PCE is 172 specified in [RFC8281]. As per [RFC8664], it is possible to use a 173 stateful PCE for computing one or more SR-TE paths taking into 174 account various constraints and objective functions. Once a path is 175 chosen, the stateful PCE can initiate an SR-TE path on a PCC using 176 PCEP extensions specified in [RFC8281] using the SR specific PCEP 177 extensions specified in [RFC8664]. [RFC8664] specifies PCEP 178 extensions for supporting a SR-TE LSP for MPLS data plane. This 179 document extends [RFC8664] to support SR for IPv6 data plane. 180 Additionally, using procedures described in this document, a PCC can 181 request an SRv6 path from either stateful or a stateless PCE. This 182 specification relies on the PATH-SETUP-TYPE TLV and procedures 183 specified in [RFC8408]. 185 This specification provides a mechanism for a network controller 186 (acting as a PCE) to instantiate candidate paths for an SR Policy 187 onto a head-end node (acting as a PCC) using PCEP. For more 188 information on the SR Policy Architecture, see 189 [I-D.ietf-spring-segment-routing-policy]. 191 2. Terminology 193 This document uses the following terms defined in [RFC5440]: PCC, 194 PCE, PCEP Peer. 196 This document uses the following terms defined in [RFC8051]: Stateful 197 PCE, Delegation. 199 The message formats in this document are specified using Routing 200 Backus-Naur Format (RBNF) encoding as specified in [RFC5511]. 202 NAI: Node or Adjacency Identifier. 204 PCC: Path Computation Client. 206 PCE: Path Computation Element. 208 PCEP: Path Computation Element Protocol. 210 SR: Segment Routing. 212 SID: Segment Identifier. 214 SRv6: Segment Routing for IPv6 forwarding plane. 216 SRH: IPv6 Segment Routing Header. 218 SR Path: IPv6 Segment List (List of IPv6 SIDs representing a path in 219 IPv6 SR domain) 221 Further, note that the term LSP used in the PCEP specifications, 222 would be equivalent to a SRv6 Path (represented as a list of SRv6 223 segments) in the context of supporting SRv6 in PCEP. 225 3. Overview of PCEP Operation in SRv6 Networks 227 Basic operations for PCEP speakers is as per [RFC8664]. SRv6 Paths 228 computed by a PCE can be represented as an ordered list of SRv6 229 segments of 128-bit value. "SRv6 SID" or simply "SID" are often used 230 as a shorter reference for "SRv6 Segment" in this document. 232 [RFC8664] defined a new Explicit Route Object (ERO) subobject denoted 233 by "SR-ERO subobject" capable of carrying a SID as well as the 234 identity of the node/adjacency represented by the SID. SR-capable 235 PCEP speakers should be able to generate and/or process such ERO 236 subobject. An ERO containing SR-ERO subobjects can be included in 237 the PCEP Path Computation Reply (PCRep) message defined in [RFC5440], 238 the PCEP LSP Initiate Request message (PCInitiate) defined in 240 [RFC8281], as well as in the PCEP LSP Update Request (PCUpd) and PCEP 241 LSP State Report (PCRpt) messages defined in defined in [RFC8231]. 243 This document define new subobjects "SRv6-ERO" and "SRv6-RRO" in ERO 244 and RRO respectively to carry SRv6 SID (IPv6 Address). SRv6-capable 245 PCEP speakers MUST be able to generate and/or process this. 247 When a PCEP session between a PCC and a PCE is established, both PCEP 248 speakers exchange their capabilities to indicate their ability to 249 support SRv6 specific functionality. 251 In summary, this document: 253 o Defines a new PCEP capability for SRv6. 255 o Defines a new subobject SRv6-ERO in ERO. 257 o Defines a new subobject SRv6-RRO in RRO. 259 o Defines a new path setup type carried in the PATH-SETUP-TYPE TLV 260 and the PATH-SETUP-TYPE-CAPABILITY TLV. 262 3.1. Operation Overview 264 In SR networks, an ingress node of an SR path appends all outgoing 265 packets with an SR header consisting of a list of SIDs (IPv6 Prefix 266 in case of SRv6). The header has all necessary information to guide 267 the packets from the ingress node to the egress node of the path, and 268 hence there is no need for any signaling protocol. 270 For IPv6 in control plane with MPLS data-plane, mechanism remains 271 same as [RFC8664] 273 This document describes extensions to SR path for IPv6 data plane. 274 SRv6 Path (i.e. ERO) consists of an ordered set of SRv6 SIDs(see 275 details in Figure 2). 277 A PCC or PCE indicates its ability to support SRv6 during the PCEP 278 session Initialization Phase via a new SRv6-PCE-CAPABILITY sub-TLV 279 (see details in Section 4.1.1). 281 3.2. SRv6-Specific PCEP Message Extensions 283 As defined in [RFC5440], a PCEP message consists of a common header 284 followed by a variable length body made up of mandatory and/or 285 optional objects. This document does not require any changes in the 286 format of PCReq and PCRep messages specified in [RFC5440], PCInitiate 287 message specified in [RFC8281], and PCRpt and PCUpd messages 288 specified in [RFC8231]. However, PCEP messages pertaining to SRv6 289 MUST include PATH-SETUP-TYPE TLV in the RP or SRP object to clearly 290 identify that SRv6 is intended. 292 4. Object Formats 294 4.1. The OPEN Object 296 4.1.1. The SRv6 PCE Capability sub-TLV 298 This document defines a new Path Setup Type (PST) [RFC8408] for SRv6, 299 as follows: 301 o PST = TBD2: Path is setup using SRv6. 303 A PCEP speaker MUST indicate its support of the function described in 304 this document by sending a PATH-SETUP-TYPE-CAPABILITY TLV in the OPEN 305 object with this new PST included in the PST list. 307 This document also defines the SRv6-PCE-CAPABILITY sub-TLV. PCEP 308 speakers use this sub-TLV to exchange information about their SRv6 309 capability. If a PCEP speaker includes PST=TBD2 in the PST List of 310 the PATH-SETUP-TYPE-CAPABILITY TLV then it MUST also include the 311 SRv6-PCE-CAPABILITY sub-TLV inside the PATH-SETUP-TYPE-CAPABILITY 312 TLV. 314 The format of the SRv6-PCE-CAPABILITY sub-TLV is shown in the 315 following figure: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type=TBD1 | Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Reserved | Flags |N|X| 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | MSD-Type | MSD-Value | MSD-Type | MSD-Value | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 // ... // 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | MSD-Type | MSD-Value | Padding | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 1: SRv6-PCE-CAPABILITY sub-TLV format 333 The code point for the TLV type (TBD1) is to be defined by IANA. The 334 TLV length is variable. 336 The value comprises of - 338 Reserved: 2 octet, this field MUST be set to 0 on transmission, 339 and ignored on receipt. 341 Flags: 2 octet, two bits are currently assigned in this document. 343 N bit: A PCC sets this flag bit to 1 to indicate that it is 344 capable of resolving a Node or Adjacency Identifier (NAI) to a 345 SRv6-SID. 347 X bit: A PCC sets this bit to 1 to indicate that it does not 348 impose any limit on MSD (irrespective of the MSD-Type). 350 Unassigned bits MUST be set to 0 and ignored on receipt. 352 A pair of (MSD-Type, MSD-Value): Where MSD-Type (1 octet) is as 353 per the IGP MSD Type registry created by [RFC8491] and populated 354 with SRv6 MSD types as per [I-D.ietf-lsr-isis-srv6-extensions]; 355 MSD-Value (1 octet) is as per [RFC8491]. 357 This sub-TLV format is compliant with the PCEP TLV format defined in 358 [RFC5440]. That is, the sub-TLV is composed of 2 octets for the 359 type, 2 octets specifying the length, and a Value field. The Type 360 field when set to TBD1 identifies the SRv6-PCE-CAPABILITY sub-TLV and 361 the presence of the sub-TLV indicates the support for the SRv6 paths 362 in PCEP. The Length field defines the length of the value portion in 363 octets. The TLV is padded to 4-octet alignment, and padding is not 364 included in the Length field. The number of (MSD-Type,MSD-Value) 365 pairs can be determined from the Length field of the TLV. 367 4.2. The RP/SRP Object 369 In order to indicate the SRv6 path, RP or SRP object MUST include the 370 PATH-SETUP-TYPE TLV specified in [RFC8408]. This document defines a 371 new Path Setup Type (PST=TBD2) for SRv6. 373 The LSP-IDENTIFIERS TLV MAY be present for the above PST type. 375 4.3. ERO 377 In order to support SRv6, new subobject "SRv6-ERO" is defined in ERO. 379 4.3.1. SRv6-ERO Subobject 381 An SRv6-ERO subobject is formatted as shown in the following figure. 383 0 1 2 3 384 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 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 |L| Type=TBD3 | Length | NT | Flags |V|T|F|S| 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Reserved | Endpoint Behavior | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | | 391 | SRv6 SID (optional) | 392 | (128-bit) | 393 | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 // NAI (variable, optional) // 396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 | SID Structure (optional) | 398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 Figure 2: SRv6-ERO Subobject Format 402 The fields in the SRv6-ERO Subobject are as follows: 404 The 'L' Flag: Indicates whether the subobject represents a loose-hop 405 (see [RFC3209]). If this flag is set to zero, a PCC MUST NOT 406 overwrite the SID value present in the SRv6-ERO subobject. 407 Otherwise, a PCC MAY expand or replace one or more SID values in the 408 received SRv6-ERO based on its local policy. 410 Type: indicates the content of the subobject, i.e. when the field is 411 set to TBD3, the suboject is a SRv6-ERO subobject representing a SRv6 412 SID. 414 Length: Contains the total length of the subobject in octets. The 415 Length MUST be at least 24, and MUST be a multiple of 4. An SRv6-ERO 416 subobject MUST contain at least one of a SRv6-SID or an NAI. The S 417 and F bit in the Flags field indicates whether the SRv6-SID or NAI 418 fields are absent. 420 NAI Type (NT): Indicates the type and format of the NAI contained in 421 the object body, if any is present. If the F bit is set to zero (see 422 below) then the NT field has no meaning and MUST be ignored by the 423 receiver. This document reuses NT types defined in [RFC8664]: 425 If NT value is 0, the NAI MUST NOT be included. 427 When NT value is 2, the NAI is as per the 'IPv6 Node ID' format 428 defined in [RFC8664], which specifies an IPv6 address. This is 429 used to identify the owner of the SRv6 Identifier. This is 430 optional, as the LOC (the locater portion) of the SRv6 SID serves 431 a similar purpose (when present). 433 When NT value is 4, the NAI is as per the 'IPv6 Adjacency' format 434 defined in [RFC8664], which specify a pair of IPv6 addresses. 435 This is used to identify the IPv6 Adjacency and used with the SRv6 436 Adj-SID. 438 When NT value is 6, the NAI is as per the 'link-local IPv6 439 addresses' format defined in [RFC8664], which specify a pair of 440 (global IPv6 address, interface ID) tuples. It is used to 441 identify the IPv6 Adjacency and used with the SRv6 Adj-SID. 443 SR-MPLS specific NT types are not valid in SRv6-ERO. 445 Flags: Used to carry additional information pertaining to the 446 SRv6-SID. This document defines the following flag bits. The other 447 bits MUST be set to zero by the sender and MUST be ignored by the 448 receiver. 450 o S: When this bit is set to 1, the SRv6-SID value in the subobject 451 body is absent. In this case, the PCC is responsible for choosing 452 the SRv6-SID value, e.g., by looking up in the SR-DB using the NAI 453 which, in this case, MUST be present in the subobject. If the S 454 bit is set to 1 then F bit MUST be set to zero. 456 o F: When this bit is set to 1, the NAI value in the subobject body 457 is absent. The F bit MUST be set to 1 if NT=0, and otherwise MUST 458 be set to zero. The S and F bits MUST NOT both be set to 1. 460 o T: When this bit is set to 1, the SID Structure value in the 461 subobject body is present. The T bit MUST be set to 0 when S bit 462 is set to 1. If the T bit is set when the S bit is set, the T bit 463 MUST be ignored. Thus, the T bit indicates the presence of an 464 optional 8-byte SID Structure when SRv6 SID is included. The SID 465 Structure is defined in Section 4.3.1.1. 467 o V: The "SID verification" bit usage is as per Section 5.1 of 468 [I-D.ietf-spring-segment-routing-policy]. 470 [Editor's Note: Need to check if another flag - A flag for the SR 471 Algorithm is required.] 472 Reserved: MUST be set to zero while sending and ignored on receipt. 474 Endpoint Behavior: A 16 bit field representing the behavior 475 associated with the SRv6 SIDs. This information is optional and 476 plays no role in the fields in SRH imposed on the packet. It could 477 be used for maintainability and diagnostic purpose. If behavior is 478 not known, 0 is used. The list of Endpoint behavior are defined in 479 [I-D.ietf-spring-srv6-network-programming]. 481 SRv6 SID: SRv6 Identifier is the 128 bit IPv6 addresses representing 482 the SRv6 segment. 484 NAI: The NAI associated with the SRv6-SID. The NAI's format depends 485 on the value in the NT field, and is described in [RFC8664]. 487 At least one of the SRv6-SID or the NAI MUST be included in the 488 SRv6-ERO subobject, and both MAY be included. 490 4.3.1.1. SID Structure 492 The SID Structure is an optional part of the SR-ERO subobject, as 493 described in Section 4.3.1. It is formatted as shown in the 494 following figure. 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | LB Length | LN Length | Fun. Length | Arg. Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Reserved | Flags | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 Figure 3: SID Structure Format 506 where: 508 LB Length: 1 octet. SRv6 SID Locator Block length in bits. 510 LN Length: 1 octet. SRv6 SID Locator Node length in bits. 512 Fun. Length: 1 octet. SRv6 SID Function length in bits. 514 Arg. Length: 1 octet. SRv6 SID Arguments length in bits. 516 The sum of all four sizes in the SID Structure must be lower or equal 517 to 128 bits. If the sum of all four sizes advertised in the SID 518 Structure is larger than 128 bits, the corresponding SRv6 SID MUST be 519 considered as an Error. A PCErr message with Error-Type = 10 520 ("Reception of an invalid object") and Error-Value = TBD ("Invalid 521 SRv6 SID Structure"). 523 Reserved: MUST be set to zero while sending and ignored on receipt. 525 Flags: Currentky no flags are defined. Unassigned bits must be set 526 to zero while sending and ignored on receipt. 528 The SRv6 SID Structure TLV provides the detailed encoding information 529 of an SRv6 SID, which is useful in the use cases that require to know 530 the SRv6 SID structure. When a PCEP speaker receives the SRv6 SID 531 and its structure information, the SRv6 SID can be parsed based on 532 the SRv6 SID Structure TLV and/or possible local policies. The 533 cunsumers of SRv6 SID structure MAY be other use cases, and the 534 processing and usage of SRv6 SID structure TLV are different based on 535 use cases. This is out of the scope of this document, and will be 536 described in other documents. 538 4.4. RRO 540 In order to support SRv6, new subobject "SRv6-RRO" is defined in RRO. 542 4.4.1. SRv6-RRO Subobject 544 A PCC reports an SRv6 path to a PCE by sending a PCRpt message, per 545 [RFC8231]. The RRO on this message represents the SID list that was 546 applied by the PCC, that is, the actual path taken. The procedures 547 of [RFC8664] with respect to the RRO apply equally to this 548 specification without change. 550 An RRO contains one or more subobjects called "SRv6-RRO subobjects" 551 whose format is shown below: 553 0 1 2 3 554 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 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Type=TBD4 | Length | NT | Flags |V|T|F|S| 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | Reserved | Endpoint Behavior | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | | 561 | SRv6 SID | 562 | (128-bit) | 563 | | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 // NAI (variable) // 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | SID Structure (optional) | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Figure 4: SRv6-RRO Subobject Format 572 The format of the SRv6-RRO subobject is the same as that of the 573 SRv6-ERO subobject, but without the L flag. 575 The V flag has no meaning in the SRv6-RRO and is ignored on receipt 576 at the PCE. 578 Ordering of SRv6-RRO subobjects by PCC in PCRpt message remains as 579 per [RFC8664]. 581 5. Procedures 583 5.1. Exchanging the SRv6 Capability 585 A PCC indicates that it is capable of supporting the head-end 586 functions for SRv6 by including the SRv6-PCE-CAPABILITY sub-TLV in 587 the Open message that it sends to a PCE. A PCE indicates that it is 588 capable of computing SRv6 paths by including the SRv6-PCE-CAPABILITY 589 sub-TLV in the Open message that it sends to a PCC. 591 If a PCEP speaker receives a PATH-SETUP-TYPE-CAPABILITY TLV with a 592 PST list containing PST=TBD2, but the SRv6-PCE-CAPABILITY sub-TLV is 593 absent, then the PCEP speaker MUST send a PCErr message with Error- 594 Type 10 (Reception of an invalid object) and Error-Value TBD5 (to be 595 assigned by IANA) (Missing PCE-SRv6-CAPABILITY sub-TLV) and MUST then 596 close the PCEP session. If a PCEP speaker receives a PATH-SETUP- 597 TYPE-CAPABILITY TLV with a SRv6-PCE-CAPABILITY sub-TLV, but the PST 598 list does not contain PST=TBD2, then the PCEP speaker MUST ignore the 599 SRv6-PCE-CAPABILITY sub-TLV. 601 The number of SRv6 SIDs that can be imposed on a packet depends on 602 the PCC's IPv6 data plane's capability. If a PCC sets the X flag to 603 1 then the MSD is not used and MUST NOT be included. If a PCE 604 receives an SRv6-PCE-CAPABILITY sub-TLV with the X flag set to 1 then 605 it MUST ignore any MSD-Type, MSD-Value fields and MUST assume that 606 the sender can impose any length of SRH. If a PCC sets the X flag to 607 zero, then it sets the SRv6 MSD-Type, MSD-Value fields that it can 608 impose on a packet. If a PCE receives an SRv6-PCE-CAPABILITY sub-TLV 609 with the X flag and SRv6 MSD-Type, MSD-Value fields both set to zero 610 then it is considered as an error and the PCE MUST respond with a 611 PCErr message (Error-Type=1 "PCEP session establishment failure" and 612 Error-Value=1 "reception of an invalid Open message or a non Open 613 message."). In case the MSD-Type in SRv6-PCE-CAPABILITY sub-TLV 614 received by the PCE does not correspond to one of the SRv6 MSD types, 615 the PCE MUST respond with a PCErr message (Error-Type=1 "PCEP session 616 establishment failure" and Error-Value=1 "reception of an invalid 617 Open message or a non Open message."). 619 Note that the MSD-Type, MSD-Value exchanged via the SRv6-PCE- 620 CAPABILITY sub-TLV indicates the SRv6 SID imposition limit for the 621 PCC node. However, if a PCE learns these via different means, e.g 622 routing protocols, as specified in: 623 [I-D.ietf-lsr-ospfv3-srv6-extensions]; 624 [I-D.ietf-lsr-isis-srv6-extensions]; [I-D.ietf-idr-bgpls-srv6-ext], 625 then it ignores the values in the SRv6-PCE-CAPABILITY sub-TLV. 626 Furthermore, whenever a PCE learns the other advanced SRv6 MSD via 627 different means, it MUST use that value regardless of the values 628 exchanged in the SRv6-PCE-CAPABILITY sub-TLV. 630 Once an SRv6-capable PCEP session is established with a non-zero SRv6 631 MSD value, the corresponding PCE MUST NOT send SRv6 paths with a 632 number of SIDs exceeding that SRv6 MSD value (based on the SRv6 MSD 633 Type). If a PCC needs to modify the SRv6 MSD value, it MUST close 634 the PCEP session and re-establish it with the new value. If a PCEP 635 session is established with a non-zero SRv6 MSD value, and the PCC 636 receives an SRv6 path containing more SIDs than specified in the SRv6 637 MSD value (based on the SRv6 MSD type), the PCC MUST send a PCErr 638 message with Error-Type 10 (Reception of an invalid object) and 639 Error-Value 3 (Unsupported number of Segment ERO subobjects). If a 640 PCEP session is established with an SRv6 MSD value of zero, then the 641 PCC MAY specify an SRv6 MSD for each path computation request that it 642 sends to the PCE, by including a "maximum SID depth" metric object on 643 the request similar to [RFC8664]. 645 The N flag, X flag and (MSD-Type,MSD-Value) pair inside the SRv6-PCE- 646 CAPABILITY sub-TLV are meaningful only in the Open message sent from 647 a PCC to a PCE. As such, a PCE MUST set the flags to zero and not 648 include any (MSD-Type,MSD-Value) pair in the SRv6-PCE-CAPABILITY sub- 649 TLV in an outbound message to a PCC. Similarly, a PCC MUST ignore 650 N,X flag and any (MSD-Type,MSD-Value) pair received from a PCE. If a 651 PCE receives multiple SRv6-PCE-CAPABILITY sub-TLVs in an Open 652 message, it processes only the first sub-TLV received. 654 5.2. ERO Processing 656 The ERO processing remains as per [RFC5440] and [RFC8664]. 658 5.2.1. SRv6 ERO Validation 660 If a PCC does not support the SRv6 PCE Capability and thus cannot 661 recognize the SRv6-ERO or SRv6-RRO subobjects, it will respond 662 according to the rules for a malformed object per [RFC5440]. 664 On receiving an SRv6-ERO, a PCC MUST validate that the Length field, 665 the S bit, the F bit, the T bit, and the NT field are consistent, as 666 follows. 668 o If NT=0, the F bit MUST be 1, the S bit MUST be zero and the 669 Length MUST be 24. 671 o If NT=2, the F bit MUST be zero. If the S bit is 1, the Length 672 MUST be 24, otherwise the Length MUST be 40. 674 o If NT=4, the F bit MUST be zero. If the S bit is 1, the Length 675 MUST be 40, otherwise the Length MUST be 56. 677 o If NT=6, the F bit MUST be zero. If the S bit is 1, the Length 678 MUST be 48, otherwise the Length MUST be 64. 680 o NT types (1,3, and 5) are not valid for SRv6. 682 o If T bit is 1, then S bit MUST be zero. 684 If a PCC finds that the NT field, Length field, S bit, F bit, and T 685 bit are not consistent, it MUST consider the entire ERO invalid and 686 MUST send a PCErr message with Error-Type = 10 ("Reception of an 687 invalid object") and Error-Value = 11 ("Malformed object"). 689 If a PCEP speaker that does not recognize the NT value received in 690 SRv6-ERO subobject, it would behave as per [RFC8664]. 692 In case a PCEP speaker receives the SRv6-ERO subobject, when the PST 693 is not set to TBD2 or SRv6-PCE-CAPABILITY sub-TLV was not exchanged, 694 it MUST send a PCErr message with Error-Type = 19 ("Invalid 695 Operation") and Error-Value = TBD5 ("Attempted SRv6 when the 696 capability was not advertised"). 698 If a PCC receives a list of SRv6 segments, and the number of SRv6 699 segments exceeds the SRv6 MSD that the PCC can impose on the packet 700 (SRH), it MUST send a PCErr message with Error-Type = 10 ("Reception 701 of an invalid object") and Error-Value = TBD ("Unsupported number of 702 Segment ERO subobjects") as per [RFC8664]. 704 When a PCEP speaker detects that all subobjects of ERO are not of 705 type TBD3, and if it does not handle such ERO, it MUST send a PCErr 706 message with Error-Type = 10 ("Reception of an invalid object") and 707 Error-Value = TBD ("Non-identical ERO subobjects")as per [RFC8664]. 709 5.2.2. Interpreting the SRv6-ERO 711 The SRv6-ERO contains a sequence of subobjects. According to 712 [I-D.ietf-spring-segment-routing-policy], each SRv6-ERO subobject in 713 the sequence identifies a segment that the traffic will be directed 714 to, in the order given. That is, the first subobject identifies the 715 first segment the traffic will be directed to, the second SRv6-ERO 716 subobject represents the second segment, and so on. 718 The PCC interprets the SRv6-ERO by converting it to an SRv6 SRH plus 719 a next hop. The PCC sends packets along the segment routed path by 720 prepending the SRH onto the packets and sending the resulting, 721 modified packet to the next hop. 723 5.3. RRO Processing 725 The syntax checking rules that apply to the SRv6-RRO subobject are 726 identical to those of the SRv6-ERO subobject, except as noted below. 728 If a PCEP speaker receives an SRv6-RRO subobject in which both SRv6 729 SID and NAI are absent, it MUST consider the entire RRO invalid and 730 send a PCErr message with Error-Type = 10 ("Reception of an invalid 731 object") and Error-Value = TBD6 ("Both SID and NAI are absent in 732 SRv6-RRO subobject"). 734 If a PCE detects that the subobjects of an RRO are a mixture of 735 SRv6-RRO subobjects and subobjects of other types, then it MUST send 736 a PCErr message with Error-Type = 10 ("Reception of an invalid 737 object") and Error-Value = TBD7 ("RRO mixes SRv6-RRO subobjects with 738 other subobject types"). 740 6. Security Considerations 742 The security considerations described in [RFC5440], [RFC8231] and 743 [RFC8281], [RFC8664], are applicable to this specification. No 744 additional security measure is required. 746 7. IANA Considerations 748 7.1. PCEP ERO and RRO subobjects 750 This document defines a new subobject type for the PCEP explicit 751 route object (ERO), and a new subobject type for the PCEP record 752 route object (RRO). The code points for subobject types of these 753 objects is maintained in the RSVP parameters registry, under the 754 EXPLICIT_ROUTE and ROUTE_RECORD objects. IANA is requested to 755 allocate code-points in the RSVP Parameters registry for each of the 756 new subobject types defined in this document. 758 Object Subobject Subobject Type 759 --------------------- -------------------------- ------------------ 760 EXPLICIT_ROUTE SRv6-ERO (PCEP-specific) TBD3 761 ROUTE_RECORD SRv6-RRO (PCEP-specific) TBD4 763 7.2. New SRv6-ERO Flag Registry 765 IANA is requested to create a new sub-registry, named "SRv6-ERO Flag 766 Field", within the "Path Computation Element Protocol (PCEP) Numbers" 767 registry to manage the Flag field of the SRv6-ERO subobject. New 768 values are to be assigned by Standards Action [RFC8126]. Each bit 769 should be tracked with the following qualities: 771 o Bit number (counting from bit 0 as the most significant bit) 773 o Capability description 775 o Defining RFC 777 The following values are defined in this document: 779 Bit Description Reference 780 ----- ------------------ -------------- 781 0-7 Unassigned 782 8 SID Verification (V) This document 783 9 SID Structure is This document 784 present (T) 785 10 NAI is absent (F) This document 786 11 SID is absent (S) This document 788 7.3. PATH-SETUP-TYPE-CAPABILITY Sub-TLV Type Indicators 790 IANA maintains a sub-registry, named "PATH-SETUP-TYPE-CAPABILITY Sub- 791 TLV Type Indicators", within the "Path Computation Element Protocol 792 (PCEP) Numbers" registry to manage the type indicator space for sub- 793 TLVs of the PATH-SETUP-TYPE-CAPABILITY TLV. IANA is requested to 794 make the following assignment: 796 Value Meaning Reference 797 ----- ------- --------- 798 TBD1 SRv6-PCE-CAPABILITY This Document 800 7.4. SRv6 PCE Capability Flags 802 IANA is requested to create a new sub-registry, named "SRv6 803 Capability Flag Field", within the "Path Computation Element Protocol 804 (PCEP) Numbers" registry to manage the Flag field of the SRv6-PCE- 805 CAPABILITY sub-TLV. New values are to be assigned by Standards 806 Action [RFC8126]. Each bit should be tracked with the following 807 qualities: 809 o Bit number (counting from bit 0 as the most significant bit) 811 o Capability description 813 o Defining RFC 815 The following values are defined in this document: 817 Bit Description Reference 819 0-13 Unassigned 820 14 Node or Adjacency This document 821 Identifier (NAI) is 822 supported (N) 823 15 Unlimited Maximum SID This document 824 Depth (X) 826 7.5. New Path Setup Type 828 [RFC8408] created a sub-registry within the "Path Computation Element 829 Protocol (PCEP) Numbers" registry called "PCEP Path Setup Types". 830 IANA is requested to allocate a new code point within this registry, 831 as follows: 833 Value Description Reference 834 ----- ----------- --------- 835 TBD2 Traffic engineering path is This Document 836 setup using SRv6. 838 7.6. ERROR Objects 840 IANA is requested to allocate code-points in the PCEP-ERROR Object 841 Error Types and Values registry for the following new error-values: 843 Error-Type Meaning 844 ---------- ------- 845 10 Reception of an invalid object 846 Error-value = TBD5 (Missing 847 PCE-SRv6-CAPABILITY sub-TLV) 848 Error-value = TBD6 (Both SID and NAI are absent 849 in SRv6-RRO subobject) 850 Error-value = TBD7 (RRO mixes SRv6-RRO subobjects 851 with other subobject types) 852 Error-value = TBD8 (Invalid SRv6 SID Structure) 853 19 Invalid Operation 854 Error-value = TBD5 (Attempted SRv6 when the 855 capability was not advertised) 857 8. Acknowledgements 859 The authors would like to thank Jeff Tentsura, Adrian Farrel, Aijun 860 Wang and Khasanov Boris for valuable suggestions. 862 9. References 864 9.1. Normative References 866 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 867 Requirement Levels", BCP 14, RFC 2119, 868 DOI 10.17487/RFC2119, March 1997, 869 . 871 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 872 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 873 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 874 . 876 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 877 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 878 DOI 10.17487/RFC5440, March 2009, 879 . 881 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 882 Used to Form Encoding Rules in Various Routing Protocol 883 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 884 2009, . 886 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 887 Writing an IANA Considerations Section in RFCs", BCP 26, 888 RFC 8126, DOI 10.17487/RFC8126, June 2017, 889 . 891 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 892 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 893 May 2017, . 895 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 896 Computation Element Communication Protocol (PCEP) 897 Extensions for Stateful PCE", RFC 8231, 898 DOI 10.17487/RFC8231, September 2017, 899 . 901 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 902 Computation Element Communication Protocol (PCEP) 903 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 904 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 905 . 907 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 908 Decraene, B., Litkowski, S., and R. Shakir, "Segment 909 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 910 July 2018, . 912 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 913 Hardwick, "Conveying Path Setup Type in PCE Communication 914 Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, 915 July 2018, . 917 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 918 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 919 DOI 10.17487/RFC8491, November 2018, 920 . 922 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 923 and J. Hardwick, "Path Computation Element Communication 924 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 925 DOI 10.17487/RFC8664, December 2019, 926 . 928 [I-D.ietf-lsr-isis-srv6-extensions] 929 Psenak, P., Filsfils, C., Bashandy, A., Decraene, B., and 930 Z. Hu, "IS-IS Extension to Support Segment Routing over 931 IPv6 Dataplane", draft-ietf-lsr-isis-srv6-extensions-11 932 (work in progress), October 2020. 934 [I-D.ietf-spring-srv6-network-programming] 935 Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., 936 Matsushima, S., and Z. Li, "SRv6 Network Programming", 937 draft-ietf-spring-srv6-network-programming-24 (work in 938 progress), October 2020. 940 9.2. Informative References 942 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 943 Element (PCE) Communication Protocol Generic 944 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 945 2006, . 947 [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., 948 Litkowski, S., Horneffer, M., and R. Shakir, "Source 949 Packet Routing in Networking (SPRING) Problem Statement 950 and Requirements", RFC 7855, DOI 10.17487/RFC7855, May 951 2016, . 953 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 954 Stateful Path Computation Element (PCE)", RFC 8051, 955 DOI 10.17487/RFC8051, January 2017, 956 . 958 [RFC8354] Brzozowski, J., Leddy, J., Filsfils, C., Maglione, R., 959 Ed., and M. Townsley, "Use Cases for IPv6 Source Packet 960 Routing in Networking (SPRING)", RFC 8354, 961 DOI 10.17487/RFC8354, March 2018, 962 . 964 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 965 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 966 December 2019, . 968 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 969 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 970 Extensions for Segment Routing", RFC 8667, 971 DOI 10.17487/RFC8667, December 2019, 972 . 974 [RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J., 975 Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header 976 (SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020, 977 . 979 [I-D.ietf-spring-segment-routing-policy] 980 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 981 P. Mattes, "Segment Routing Policy Architecture", draft- 982 ietf-spring-segment-routing-policy-09 (work in progress), 983 November 2020. 985 [I-D.ietf-lsr-ospfv3-srv6-extensions] 986 Li, Z., Hu, Z., Cheng, D., Talaulikar, K., and P. Psenak, 987 "OSPFv3 Extensions for SRv6", draft-ietf-lsr- 988 ospfv3-srv6-extensions-01 (work in progress), August 2020. 990 [I-D.ietf-idr-bgpls-srv6-ext] 991 Dawra, G., Filsfils, C., Talaulikar, K., Chen, M., 992 daniel.bernier@bell.ca, d., and B. Decraene, "BGP Link 993 State Extensions for SRv6", draft-ietf-idr-bgpls- 994 srv6-ext-05 (work in progress), November 2020. 996 Appendix A. Contributor 998 The following persons contributed to this document: 1000 Dhruv Dhody 1001 Huawei Technologies 1002 Divyashree Techno Park, Whitefield 1003 Bangalore, Karnataka 560066 1004 India 1006 EMail: dhruv.ietf@gmail.com 1008 Huang Wumin 1009 Huawei Technologies 1010 Huawei Building, No. 156 Beiqing Rd. 1011 Beijing 100095 1012 China 1014 Email: huangwumin@huawei.com 1016 Shuping Peng 1017 Huawei Technologies 1018 Huawei Building, No. 156 Beiqing Rd. 1019 Beijing 100095 1020 China 1022 Email: pengshuping@huawei.com 1024 Authors' Addresses 1026 Cheng Li(Editor) 1027 Huawei Technologies 1028 Huawei Campus, No. 156 Beiqing Rd. 1029 Beijing 100095 1030 China 1032 EMail: c.l@huawei.com 1034 Mahendra Singh Negi 1035 RtBrick Inc 1036 Bangalore, Karnataka 1037 India 1039 EMail: mahend.ietf@gmail.com 1040 Siva Sivabalan 1041 Ciena Corporation 1043 EMail: msiva282@gmail.com 1045 Mike Koldychev 1046 Cisco Systems, Inc. 1047 Canada 1049 EMail: mkoldych@cisco.com 1051 Prejeeth Kaladharan 1052 RtBrick Inc 1053 Bangalore, Karnataka 1054 India 1056 EMail: prejeeth@rtbrick.com 1058 Yongqing Zhu 1059 China Telecom 1060 109 West Zhongshan Ave, Tianhe District 1061 Bangalore, Guangzhou 1062 P.R. China 1064 EMail: zhuyq8@chinatelecom.cn