idnits 2.17.00 (12 Aug 2021) /tmp/idnits8663/draft-ietf-pce-segment-routing-policy-cp-06.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 (October 2021) is 218 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 (-22) exists of draft-ietf-spring-segment-routing-policy-13 == Outdated reference: A later version (-17) exists of draft-ietf-idr-segment-routing-te-policy-13 == Outdated reference: A later version (-05) exists of draft-koldychev-pce-operational-04 == Outdated reference: A later version (-13) exists of draft-ietf-pce-segment-routing-ipv6-09 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group M. Koldychev 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track S. Sivabalan 5 Expires: 25 April 2022 Ciena Corporation 6 C. Barth 7 Juniper Networks, Inc. 8 S. Peng 9 Huawei Technologies 10 H. Bidgoli 11 Nokia 12 October 2021 14 PCEP extension to support Segment Routing Policy Candidate Paths 15 draft-ietf-pce-segment-routing-policy-cp-06 17 Abstract 19 This document introduces a mechanism to specify a Segment Routing 20 (SR) policy, as a collection of SR candidate paths. An SR policy is 21 identified by tuple. An SR policy can 22 contain one or more candidate paths where each candidate path is 23 identified in PCEP by its uniquely assigned PLSP-ID. This document 24 proposes extension to PCEP to support association among candidate 25 paths of a given SR policy. The mechanism proposed in this document 26 is applicable to both MPLS and IPv6 data planes of SR. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 32 "OPTIONAL" in this document are to be interpreted as described in BCP 33 14 [RFC2119] [RFC8174] when, and only when, they appear in all 34 capitals, as shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on 4 April 2022. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 60 license-info) in effect on the date of publication of this document. 61 Please review these documents carefully, as they describe your rights 62 and restrictions with respect to this document. Code Components 63 extracted from this document must include Simplified BSD License text 64 as described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Simplified BSD License. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.1. Group Candidate Paths belonging to the same SR policy . . 5 73 3.2. Instantiation of SR policy candidate paths . . . . . . . 5 74 3.3. Avoid computing lower preference candidate paths . . . . 5 75 3.4. Minimal signaling overhead . . . . . . . . . . . . . . . 6 76 4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6 77 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 78 4.1.1. SR Policy Identifiers . . . . . . . . . . . . . . . . 7 79 4.1.2. SR Policy Candidate Path Identifiers . . . . . . . . 7 80 4.1.3. SR Policy Candidate Path Attributes . . . . . . . . . 7 81 4.2. Multiple Optimization Objectives and Constraints . . . . 8 82 5. SR Policy Association . . . . . . . . . . . . . . . . . . . . 8 83 5.1. Association Parameters . . . . . . . . . . . . . . . . . 8 84 5.2. Association Information . . . . . . . . . . . . . . . . . 10 85 5.2.1. SR Policy Name TLV . . . . . . . . . . . . . . . . . 10 86 5.2.2. SR Policy Candidate Path Identifiers TLV . . . . . . 11 87 5.2.3. SR Policy Candidate Path Name TLV . . . . . . . . . . 12 88 5.2.4. SR Policy Candidate Path Preference TLV . . . . . . . 12 89 6. Generic Mechanisms . . . . . . . . . . . . . . . . . . . . . 13 90 6.1. Computation Priority TLV . . . . . . . . . . . . . . . . 13 91 6.2. Explicit Null Label Policy (ENLP) TLV . . . . . . . . . . 13 92 6.3. Invalidation TLV . . . . . . . . . . . . . . . . . . . . 14 93 6.4. Specified-BSID-only . . . . . . . . . . . . . . . . . . . 15 95 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 96 7.1. PCC Initiated SR Policy with single candidate-path . . . 15 97 7.2. PCC Initiated SR Policy with multiple candidate-paths . . 16 98 7.3. PCE Initiated SR Policy with single candidate-path . . . 16 99 7.4. PCE Initiated SR Policy with multiple candidate-paths . . 17 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 101 8.1. Association Type . . . . . . . . . . . . . . . . . . . . 17 102 8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 18 103 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 18 104 8.4. TE-PATH-BINDING TLV Flag field . . . . . . . . . . . . . 19 105 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 106 9.1. Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . 20 107 9.2. Juniper . . . . . . . . . . . . . . . . . . . . . . . . . 20 108 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 109 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 111 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 112 12.2. Informative References . . . . . . . . . . . . . . . . . 22 113 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 23 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 116 1. Introduction 118 Path Computation Element (PCE) Communication Protocol (PCEP) 119 [RFC5440] enables the communication between a Path Computation Client 120 (PCC) and a Path Computation Element (PCE), or between two PCEs based 121 on the PCE architecture [RFC4655]. 123 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 124 of extensions to PCEP to enable active control of Multiprotocol Label 125 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 126 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 127 LSPs under the active stateful PCE model, without the need for local 128 configuration on the PCC, thus allowing for dynamic centralized 129 control of a network. 131 PCEP Extensions for Segment Routing [RFC8664] specifies extensions to 132 the Path Computation Element Protocol (PCEP) that allow a stateful 133 PCE to compute and initiate Traffic Engineering (TE) paths, as well 134 as a PCC to request a path subject to certain constraint(s) and 135 optimization criteria in SR networks. 137 PCEP Extensions for Establishing Relationships Between Sets of LSPs 138 [RFC8697] introduces a generic mechanism to create a grouping of LSPs 139 which can then be used to define associations between a set of LSPs 140 and a set of attributes (such as configuration parameters or 141 behaviors) and is equally applicable to stateful PCE (active and 142 passive modes) and stateless PCE. 144 Segment Routing Policy for Traffic Engineering 145 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 146 Policy and approaches to steering traffic into an SR Policy. 148 An SR Policy contains one or more SR Policy Candidate Paths where one 149 or more such paths can be computed via PCE. This document specifies 150 PCEP extensions to signal additional information to map candidate 151 paths to their SR policies. Each candidate path maps to a unique 152 PLSP-ID in PCEP. By associating multiple candidate paths together, a 153 PCE becomes aware of the hierarchical structure of an SR policy. 154 Thus the PCE can take computation and control decisions about the 155 candidate paths, with the additional knowledge that these candidate 156 paths belong to the same SR policy. This is accomplished via the use 157 of the existing PCEP Association object, by defining a new 158 association type specifically for associating SR candidate paths into 159 a single SR policy. 161 2. Terminology 163 The following terminologies are used in this document: 165 Endpoint: The IPv4 or IPv6 endpoint address of the SR policy in 166 question, as described in 167 [I-D.ietf-spring-segment-routing-policy]. 169 Association Parameters: As described in [RFC8697], the combination 170 of the mandatory fields Association Type, Association ID and 171 Association Source in the ASSOCIATION object uniquely identify the 172 association group. If the optional TLVs - Global Association 173 Source or Extended Association ID are included, then they MUST be 174 included in combination with mandatory fields to uniquely identify 175 the association group. 177 Association Information: As described in [RFC8697], the ASSOCIATION 178 object could also include other TLVs based on the association 179 types, that provides non-key information. 181 SRPAG: SR Policy Association Group. 183 SRPAT: SR Policy Association Type. 185 SRPAT ASSOCIATION: ASSOCIATION object of type SR Policy Association. 187 PCC: Path Computation Client. Any client application requesting a 188 path computation to be performed by a Path Computation Element. 190 PCE: Path Computation Element. An entity (component, application, 191 or network node) that is capable of computing a network path or 192 route based on a network graph and applying computational 193 constraints. 195 PCEP: Path Computation Element Protocol. 197 PCEP Tunnel: The entity identified by the PLSP-ID, as per 198 [I-D.koldychev-pce-operational]. 200 3. Motivation 202 The SR Policy Association and its TLVs, defined in this document, 203 allow PCEP speakers to exchange additional information about SR 204 Policy Candidate Paths and their container SR Policy. 206 3.1. Group Candidate Paths belonging to the same SR policy 208 Since each SR Policy Candidate Path appears as a different Tunnel 209 (identified via a PLSP-ID) in PCEP, it is useful to group together 210 all the SR Policy Candidate Paths that belong to the same SR Policy. 211 Furthermore, it is useful for the PCE to have knowledge of the SR 212 Policy related information such as color, endpoint, protocol origin, 213 discriminator, and preference. 215 3.2. Instantiation of SR policy candidate paths 217 A PCE needs to instantiate one or more SR Policy Candidate Paths on 218 the PCC, as specified in [RFC8281]. Each SR Policy Candidate Path is 219 identified by the tuple . This draft provides a mechanism to 221 signal this information in PCEP. 223 3.3. Avoid computing lower preference candidate paths 225 When a PCE knows that a given set of SR Policy Candidate Paths all 226 belong to the same SR Policy, then path computation MAY be done on 227 only the highest preference candidate-path(s). Path computation for 228 lower preference paths is not necessary if one or two higher 229 preference paths are already computed. Since computing their paths 230 will not affect traffic steering, it MAY be postponed until the 231 higher preference paths become invalid. 233 3.4. Minimal signaling overhead 235 When an SR Policy contains multiple SR Policy Candidate Paths 236 computed by a PCE, such candidate paths can be created, updated and 237 deleted independently of each other. This is achieved by making each 238 SR Policy Candidate Path correspond to a unique Tunnel (identified 239 via PLSP-ID). For example, if an SR Policy has 4 SR Policy Candidate 240 Paths, then if the PCE wants to update one of those, only one set of 241 PCUpd and PCRpt messages needs to be exchanged. 243 4. Procedure 245 4.1. Overview 247 As per [RFC8697], LSPs are placed into an association group. As per 248 [I-D.koldychev-pce-operational], LSPs are contained in PCEP Tunnels 249 and a PCEP Tunnel is contained in an Association if all of its LSPs 250 are in that Association. PCEP Tunnels naturally map to SR Policy 251 Candidate Paths and PCEP Associations naturally map to SR Policies. 253 The mapping between PCEP Associations and SR Policies is always one- 254 to-one. However, the mapping between PCEP Tunnels and SR Policy 255 Candidate Paths may be either one-to-one, or many-to-one, see 256 Section 4.2. 258 Each SR Policy Candidate Path contains one or more Segment Lists. 259 The subject of encoding multiple Segment Lists within an SR Policy 260 Candidate Path is described in [I-D.koldychev-pce-multipath]. 262 This document defines a new Association Type called "SR Policy 263 Association", of value 6 based on the generic ASSOCIATION object. 264 The new Association Type is also called "SRPAT", for "SR Policy 265 Association Type". We say "SRPAT ASSOCIATION" to mean "ASSOCIATION 266 object of type SR Policy Association". The group of LSPs that are 267 part of the SR Policy Association is called "SRPAG", for "SR Policy 268 Association Group". 270 As per the processing rules specified in section 6.4 of [RFC8697], if 271 a PCEP speaker does not support the SRPAT, it MUST return a PCErr 272 message with Error-Type = 26 "Association Error", Error-Value = 1 273 "Association-type is not supported". 275 A given LSP MUST belong to at most one SRPAG, since an SR Policy 276 Candidate Path cannot belong to multiple SR Policies. If a PCEP 277 speaker receives a PCEP message with more than one SRPAT ASSOCIATION 278 for the same LSP, then the PCEP speaker MUST send a PCErr message 279 with Error-Type = 26 "Association Error", Error-Value = 7 "Cannot 280 join the association group". 282 An SRPAT ASSOCIATION carries three pieces of information: SR Policy 283 Identifiers, SR Policy Candidate Path Identifiers, and SR Policy 284 Candidate Path Attributes. 286 4.1.1. SR Policy Identifiers 288 SR Policy Identifiers uniquely identify the SR policy within the 289 context of the headend. SR Policy Identifiers MUST be the same for 290 all SR Policy Candidate Paths in the same SRPAG. SR Policy 291 Identifiers MUST NOT change for a given SR Policy Candidate Path 292 during its lifetime. SR Policy Identifiers MUST be different for 293 different SRPAGs. SR Policy Identifiers consist of: 295 * Headend router where the SR Policy originates. 297 * Color of SR Policy. 299 * Endpoint of SR Policy. 301 4.1.2. SR Policy Candidate Path Identifiers 303 SR Policy Candidate Path Identifiers uniquely identify the SR Policy 304 Candidate Path within the context of an SR Policy. SR Policy 305 Candidate Path Identifiers MUST NOT change for a given LSP during its 306 lifetime. SR Policy Candidate Path Identifiers MUST be different for 307 different LSPs within the same SRPAG. When these rules are not 308 satisfied, the PCE MUST send a PCErr message with Error-Type = 26 309 "Association Error", Error Value = TBD8 "SR Policy Candidate Path 310 Identifiers Mismatch". SR Policy Candidate Path Identifiers consist 311 of: 313 * Protocol Origin. 315 * Originator. 317 * Discriminator. 319 4.1.3. SR Policy Candidate Path Attributes 321 SR Policy Candidate Path Attributes carry non-key information about 322 the candidate path and MAY change during the lifetime of the LSP. SR 323 Policy Candidate Path Attributes consist of: 325 * Preference. 327 * Optionally, the SR Policy Candidate Path name. 329 * Optionally, the SR Policy name. 331 4.2. Multiple Optimization Objectives and Constraints 333 In certain scenarios, it is desired for each SR Policy Candidate Path 334 to contain multiple sub-candidate paths, each of which has a 335 different optimization objective and constraints. Traffic is then 336 sent ECMP or UCMP among these sub-candidate paths. 338 This is represented in PCEP by a many-to-one mapping between PCEP 339 Tunnels and SR Policy Candidate Paths. This means that multiple PCEP 340 Tunnels are allocated for each SR Policy Candidate Path. Each PCEP 341 Tunnel has its own optimization objective and constraints. When a 342 single SR Policy Candidate Path contains multiple PCEP Tunnels, each 343 of these PCEP Tunnels MUST have identical values of Candidate Path 344 Identifiers, as encoded in SRPOLICY-CPATH-ID TLV, see Section 5.2.2. 346 5. SR Policy Association 348 Two ASSOCIATION object types for IPv4 and IPv6 are defined in 349 [RFC8697]. The ASSOCIATION object includes "Association Type" 350 indicating the type of the association group. This document adds a 351 new Association Type (6) "SR Policy Association". This Association 352 Type is dynamic in nature, thus operator-configured Association Range 353 MUST NOT be set for this Association type and MUST be ignored. 355 5.1. Association Parameters 357 As per [I-D.ietf-spring-segment-routing-policy], an SR Policy is 358 identified through the tuple . the headend 359 is encoded as the Association Source in the ASSOCIATION object and 360 the color and endpoint are encoded as part of Extended Association ID 361 TLV. 363 The Association Parameters (see Section 2) consist of: 365 * Association Type: set to 6 "SR Policy Association". 367 * Association Source (IPv4/IPv6): set to the headend IP address. 369 * Association ID (16-bit): set to "1". 371 * Extended Association ID TLV: encodes the Color and Endpoint of the 372 SR Policy. 374 The Association Source MUST be set to the headend value of the SR 375 Policy, as defined in [I-D.ietf-spring-segment-routing-policy] 376 Section 2.1. If the PCC receives a PCInit message for a non-existent 377 SR Policy, where the Association Source is set not to the headend 378 value but to some globally unique IP address that the PCC owns, then 379 the PCC SHOULD accept the PCInit message and create the SR Policy 380 Association with the Association Source that was sent in the PCInit 381 message. 383 The 16-bit Association ID field in the ASSOCIATION object MUST be set 384 to the value of "1". 386 The Extended Association ID TLV MUST be included and it MUST be in 387 the following format: 389 0 1 2 3 390 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Type = 31 | Length = 8 or 20 | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Color | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 ~ Endpoint ~ 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 399 Figure 1: Extended Association ID TLV format 401 Type: Extended Association ID TLV, type = 31. 403 Length: Either 8 or 20, depending on whether IPv4 or IPv6 address is 404 encoded in the Endpoint. 406 Color: SR Policy color value. 408 Endpoint: can be either IPv4 or IPv6, depending on whether the policy 409 endpoint is IPv4 or IPv6. This value MAY be different from the one 410 contained in the END-POINTS object, or in the LSP IDENTIFIERS TLV of 411 the LSP object. This value is part of the tuple 412 that identifies the SR Policy on a given headend. 414 If the PCEP speaker receives an SRPAT ASSOCIATION whose Association 415 Parameters do not follow the above specification, then the PCEP 416 speaker MUST send PCErr message with Error-Type = 26 "Association 417 Error", Error-Value = TBD7 "SR Policy Identifiers Mismatch". 419 The purpose of choosing the Association Parameters in this way is to 420 guarantee that there is no possibility of a race condition when 421 multiple PCEP speakers want to create the same SR Policy at the same 422 time. By adhering to this format, all PCEP speakers come up with the 423 same Association Parameters independently of each other. Thus, there 424 is no chance that different PCEP speakers will come up with different 425 Association Parameters for the same SR Policy. 427 5.2. Association Information 429 The SRPAT ASSOCIATION contains the following TLVs: 431 * SRPOLICY-POL-NAME TLV: (optional) encodes SR Policy Name string. 433 * SRPOLICY-CPATH-ID TLV: (mandatory) encodes SR Policy Candidate 434 Path Identifiers. 436 * SRPOLICY-CPATH-NAME TLV: (optional) encodes SR Policy Candidate 437 Path string name. 439 * SRPOLICY-CPATH-PREFERENCE TLV: (optional) encodes SR Policy 440 Candidate Path preference value. 442 Of these new TLVs, SRPOLICY-CPATH-ID TLV is mandatory. When a 443 mandatory TLV is missing from the SRPAT ASSOCIATION object, the PCE 444 MUST send a PCErr message with Error-Type = 6 "Mandatory Object 445 Missing", Error-Value = TBD6 "Missing Mandatory TLV". 447 5.2.1. SR Policy Name TLV 449 The SRPOLICY-POL-NAME TLV is an optional TLV for the SRPAT 450 ASSOCIATION. At most one SRPOLICY-POL-NAME TLV SHOULD be encoded by 451 the sender and only the first occurrence is processed and any others 452 MUST be ignored. 454 0 1 2 3 455 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 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | Type | Length | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | | 460 ~ SR Policy Name ~ 461 | | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 Figure 2: The SRPOLICY-POL-NAME TLV format 466 Type: 56 for "SRPOLICY-POL-NAME" TLV. 468 Length: indicates the length of the value portion of the TLV in 469 octets and MUST be greater than 0. The TLV MUST be zero-padded so 470 that the TLV is 4-octet aligned. 472 SR Policy Name: SR Policy name, as defined in 473 [I-D.ietf-spring-segment-routing-policy]. It SHOULD be a string of 474 printable ASCII characters, without a NULL terminator. 476 5.2.2. SR Policy Candidate Path Identifiers TLV 478 The SRPOLICY-CPATH-ID TLV is a mandatory TLV for the SRPAT 479 ASSOCIATION. Only one SRPOLICY-CPATH-ID TLV SHOULD be encoded by the 480 sender and only the first occurrence is processed and any others MUST 481 be ignored. 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Type | Length | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Proto. Origin | MBZ | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | Originator ASN | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 | | 493 | Originator Address | 494 | | 495 | | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Discriminator | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 Figure 3: The SRPOLICY-CPATH-ID TLV format 502 Type: 57 for "SRPOLICY-CPATH-ID" TLV. 504 Length: 28. 506 Protocol Origin: 8-bit value that encodes the protocol origin, as 507 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.3. 508 Note that in PCInit messages, the Protocol Origin is always set to 509 "PCEP". 511 Originator ASN: Represented as 4 byte number, part of the originator 512 identifier, as specified in [I-D.ietf-spring-segment-routing-policy] 513 Section 2.4. 515 Originator Address: Represented as 128 bit value where IPv4 address 516 are encoded in lowest 32 bits, part of the originator identifier, as 517 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.4. 519 Discriminator: 32-bit value that encodes the Discriminator of the 520 candidate path. 522 5.2.3. SR Policy Candidate Path Name TLV 524 The SRPOLICY-CPATH-NAME TLV is an optional TLV for the SRPAT 525 ASSOCIATION. At most one SRPOLICY-CPATH-NAME TLV SHOULD be encoded 526 by the sender and only the first occurrence is processed and any 527 others MUST be ignored. 529 0 1 2 3 530 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 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | Type | Length | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | | 535 ~ SR Policy Candidate Path Name ~ 536 | | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 Figure 4: The SRPOLICY-CPATH-NAME TLV format 541 Type: 58 for "SRPOLICY-CPATH-NAME" TLV. 543 Length: indicates the length of the value portion of the TLV in 544 octets and MUST be greater than 0. The TLV MUST be zero-padded so 545 that the TLV is 4-octet aligned. 547 SR Policy Candidate Path Name: SR Policy Candidate Path Name, as 548 defined in [I-D.ietf-spring-segment-routing-policy]. It SHOULD be a 549 string of printable ASCII characters, without a NULL terminator. 551 5.2.4. SR Policy Candidate Path Preference TLV 553 The SRPOLICY-CPATH-PREFERENCE TLV is an optional TLV for the SRPAT 554 ASSOCIATION. Only one SRPOLICY-CPATH-PREFERENCE TLV SHOULD be 555 encoded by the sender and only the first occurrence is processed and 556 any others MUST be ignored. 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Type | Length | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Preference | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 5: The SRPOLICY-CPATH-PREFERENCE TLV format 568 Type: 59 for "SRPOLICY-CPATH-PREFERENCE" TLV. 570 Length: 4. 572 Preference: Numerical preference of the candidate path, as specified 573 in Section 2.7 of [I-D.ietf-spring-segment-routing-policy]. 575 If the TLV is missing, a default Preference value of 100 is used, as 576 specified in Section 2.7 of [I-D.ietf-spring-segment-routing-policy]. 578 6. Generic Mechanisms 580 This section describes various mechanisms that are standardized for 581 SR Policies in [I-D.ietf-spring-segment-routing-policy], but are 582 equally applicable to other tunnel types, such as RSVP-TE tunnels. 583 Hence this section does not make use of the SRPAT ASSOCIATION. 585 6.1. Computation Priority TLV 587 The COMPUTATION-PRIORITY TLV is an optional TLV for the LSP object. 588 It is used to signal the numerical computation priority, as specified 589 in Section 2.12 of [I-D.ietf-spring-segment-routing-policy]. If the 590 TLV is absent from the LSP object, a default Priority value of 128 is 591 used. 593 0 1 2 3 594 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 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Type | Length | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | Priority | MBZ | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Figure 6: The COMPUTATION-PRIORITY TLV format 603 Type: TBD1 for "COMPUTATION-PRIORITY" TLV. 605 Length: 4. 607 Priority: Numerical priority with which this LSP is to be recomputed 608 by the PCE upon topology change. 610 6.2. Explicit Null Label Policy (ENLP) TLV 612 The ENLP TLV is an optional TLV for the LSP object. It is used to 613 implement the "Explicit Null Label Policy", as specified in 614 Section 2.4.5 of [I-D.ietf-idr-segment-routing-te-policy]. 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Type | Length | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | ENLP | MBZ | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 Figure 7: The Explicit Null Label Policy (ENLP) TLV format 626 Type: TBD2 for "ENLP" TLV. 628 Length: 4. 630 ENLP (Explicit NULL Label Policy): same values as in Section 2.4.5 of 631 [I-D.ietf-idr-segment-routing-te-policy]. 633 6.3. Invalidation TLV 635 The INVALIDATION TLV is an optional TLV for the LSP object. It is 636 used to specify LSP behavior when the LSP is operationally down, in 637 particular to facilitate the "Drop upon invalid" behavior, specified 638 in Section 8.2 of [I-D.ietf-spring-segment-routing-policy]. 640 0 1 2 3 641 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 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Type | Length | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Config | State | MBZ | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Figure 8: The INVALIDATION TLV format 650 Type: TBD3 for "INVALIDATION" TLV. 652 Length: 4. 654 Config: specifies the action to take when the LSP becomes invalid: 656 * 0: (default) bring down the LSP and forward traffic somewhere else 657 (i.e., IGP, etc.). 659 * 1: drop traffic when the LSP is invalid. 661 * 2-255: Reserved. 663 State: specifies the current state of the LSP: 665 * 0: (default) traffic is not being dropped. 667 * 1: traffic is being dropped, due to LSP being down and "Drop upon 668 invalid" being set. 670 * 2-255: Reserved. 672 The "State" field only has meaning when sent from PCC to the PCE in 673 PCRpt messages, it is set to 0 when sent from PCE to PCC. The 674 "Config" field is valid in both directions on the PCEP session, i.e., 675 from PCC in PCRpt and from PCE in PCUpd and PCInit messages. 677 6.4. Specified-BSID-only 679 Specified-BSID-only functionality is defined in Section 6.2.3 of 680 [I-D.ietf-spring-segment-routing-policy]. When specified-BSID-only 681 is enabled for a particular binding SID, it means that the given 682 binding SID is required to be allocated and programmed for the LSP to 683 be operationally up. If the binding SID cannot be allocated or 684 programmed for some reason, then the LSP must stay down. 686 To signal specified-BSID-only, a new bit: S (Specified-BSID-only) is 687 allocated in the "TE-PATH-BINDING TLV Flag field" of the TE-PATH- 688 BINDING TLV. When this bit is set for a particular BSID, it means 689 that the BSID follows the Specified-BSID-only behavior. It is 690 possible to have a mix of BSIDs for the same LSP: some with S=1 and 691 some with S=0. 693 7. Examples 695 7.1. PCC Initiated SR Policy with single candidate-path 697 PCReq and PCRep messages are exchanged in the following sequence: 699 1. PCC sends PCReq message to the PCE, encoding the SRPAT 700 ASSOCIATION and TLVs in the PCReq message. 702 2. PCE returns the path in PCRep message, and echoes back the SRPAT 703 ASSOCIATION. 705 PCRpt and PCUpd messages are exchanged in the following sequence: 707 1. PCC sends PCRpt message to the PCE, including the LSP object and 708 the SRPAT ASSOCIATION. 710 2. PCE computes path, possibly making use of the Association 711 Information from the SRPAT ASSOCIATION. 713 3. PCE updates the SR policy candidate path's ERO using PCUpd 714 message. 716 7.2. PCC Initiated SR Policy with multiple candidate-paths 718 PCRpt and PCUpd messages are exchanged in the following sequence: 720 1. For each candidate path of the SR Policy, the PCC generates a 721 different PLSP-ID and symbolic-name and sends multiple PCRpt 722 messages (or one message with multiple LSP objects) to the PCE. 723 Each LSP object is followed by SRPAT ASSOCIATION with identical 724 Color and Endpoint values. The Association Source is set to the 725 IP address of the PCC and the Association ID is set to a number 726 that PCC locally chose to represent the SR Policy. 728 2. PCE takes into account that all the LSPs belong to the same SR 729 policy. PCE prioritizes computation for the highest preference 730 LSP and sends PCUpd message(s) back to the PCC. 732 3. If a new candidate path is added on the PCC by the operator, then 733 a new PLSP-ID and symbolic name is generated for that candidate 734 path and a new PCRpt is sent to the PCE. 736 4. If an existing candidate path is removed from the PCC by the 737 operator, then that PLSP-ID is deleted from the PCE by sending 738 PCRpt with the R-flag in the LSP object set. 740 7.3. PCE Initiated SR Policy with single candidate-path 742 A candidate-path is created using the following steps: 744 1. PCE sends PCInitiate message, containing the SRPAT ASSOCIATION. 745 The Association Source and the Association ID are set as 746 described in Section 5.1. 748 2. PCC uses the color, endpoint and preference from the SRPAT 749 ASSOCIATION to create a new candidate path. If no SR policy 750 exists to hold the candidate path, then a new SR policy is 751 created to hold the new candidate-path. The Originator of the 752 candidate path is set to be the address of the PCE that is 753 sending the PCInitiate message. 755 3. PCC sends a PCRpt message back to the PCE to report the newly 756 created Candidate Path. The PCRpt message contains the SRPAT 757 ASSOCIATION. 759 A candidate-path is deleted using the following steps: 761 1. PCE sends PCInitiate message, setting the R-flag in the LSP 762 object. 764 2. PCC uses the PLSP-ID from the LSP object to find the candidate 765 path and delete it. If this is the last candidate path under the 766 SR policy, then the containing SR policy is deleted as well. 768 7.4. PCE Initiated SR Policy with multiple candidate-paths 770 A candidate-path is created using the following steps: 772 1. PCE sends a separate PCInitiate message for every candidate path 773 that it wants to create, or it sends multiple LSP objects within 774 a single PCInitiate message. The SRPAT ASSOCIATION is sent for 775 every LSP in the PCInitiate message. The Association Source and 776 the Association ID are set as described in Section 5.1. 778 2. PCC creates multiple candidate paths under the same SR policy, 779 identified by Color and Endpoint. 781 3. PCC sends a PCRpt message back to the PCE to report the newly 782 created Candidate Path. The PCRpt message contains the SRPAT 783 ASSOCIATION. The Association Source and the Association ID are 784 set as described in Section 5.1. 786 A candidate path is deleted using the following steps: 788 1. PCE sends PCInitiate message, setting the R-flag in the LSP 789 object. 791 2. PCC uses the PLSP-ID from the LSP object to find the candidate 792 path and delete it. 794 8. IANA Considerations 796 8.1. Association Type 798 This document defines a new association type: SR Policy Association. 799 IANA is requested to make the following codepoint assignment in the 800 "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path 801 Computation Element Protocol (PCEP) Numbers" registry: 803 +-----------+-------------------------------------------+-----------+ 804 | Type | Name | Reference | 805 +-----------+-------------------------------------------+-----------+ 806 | 6 | SR Policy Association | This.I-D | 807 +-----------+-------------------------------------------+-----------+ 809 8.2. PCEP TLV Type Indicators 811 This document defines four new TLVs for carrying additional 812 information about SR policy and SR candidate paths. IANA is 813 requested to make the assignment of a new value for the existing 814 "PCEP TLV Type Indicators" registry as follows: 816 +-----------+-------------------------------------------+-----------+ 817 | Value | Description | Reference | 818 +-----------+-------------------------------------------+-----------+ 819 | 56 | SRPOLICY-POL-NAME | This.I-D | 820 +-----------+-------------------------------------------+-----------+ 821 | 57 | SRPOLICY-CPATH-ID | This.I-D | 822 +-----------+-------------------------------------------+-----------+ 823 | 58 | SRPOLICY-CPATH-NAME | This.I-D | 824 +-----------+-------------------------------------------+-----------+ 825 | 59 | SRPOLICY-CPATH-PREFERENCE | This.I-D | 826 +-----------+-------------------------------------------+-----------+ 827 | TBD1 | COMPUTATION-PRIORITY | This.I-D | 828 +-----------+-------------------------------------------+-----------+ 829 | TBD2 | EXPLICIT-NULL-LABEL-POLICY | This.I-D | 830 +-----------+-------------------------------------------+-----------+ 831 | TBD3 | INVALIDATION | This.I-D | 832 +-----------+-------------------------------------------+-----------+ 834 8.3. PCEP Errors 836 This document defines one new Error-Value within the "Mandatory 837 Object Missing" Error-Type and two new Error-Values within the 838 "Association Error" Error-Type. IANA is requested to allocate new 839 error values within the "PCEP-ERROR Object Error Types and Values" 840 sub-registry of the PCEP Numbers registry, as follows: 842 +------------+------------------+-----------------------+-----------+ 843 | Error-Type | Meaning | Error-value | Reference | 844 +------------+------------------+-----------------------+-----------+ 845 | 6 | Mandatory Object | | [RFC5440] | 846 | | Missing | | | 847 +------------+------------------+-----------------------+-----------+ 848 | | | TBD6: SR Policy | This.I-D | 849 | | | Missing Mandatory TLV | | 850 +------------+------------------+-----------------------+-----------+ 851 | 26 | Association | | [RFC8697] | 852 | | Error | | | 853 +------------+------------------+-----------------------+-----------+ 854 | | | TBD7: SR Policy | This.I-D | 855 | | | Identifers Mismatch | | 856 +------------+------------------+-----------------------+-----------+ 857 | | | TBD8: SR Policy | This.I-D | 858 | | | Candidate Path | | 859 | | | Identifiers Mismatch | | 860 +------------+------------------+-----------------------+-----------+ 862 8.4. TE-PATH-BINDING TLV Flag field 864 IANA is requested to allocate new bit within the "TE-PATH-BINDING TLV 865 Flag field" sub-registry of the PCEP Numbers registry, as follows: 867 +------------+------------------------------------------+-----------+ 868 | Bit position | Description | Reference | 869 +--------------+----------------------------------------+-----------+ 870 | 1 | Specified-BSID-only | This.I-D | 871 +--------------+----------------------------------------+-----------+ 873 9. Implementation Status 875 [Note to the RFC Editor - remove this section before publication, as 876 well as remove the reference to RFC 7942.] 878 This section records the status of known implementations of the 879 protocol defined by this specification at the time of posting of this 880 Internet-Draft, and is based on a proposal described in [RFC7942]. 881 The description of implementations in this section is intended to 882 assist the IETF in its decision processes in progressing drafts to 883 RFCs. Please note that the listing of any individual implementation 884 here does not imply endorsement by the IETF. Furthermore, no effort 885 has been spent to verify the information presented here that was 886 supplied by IETF contributors. This is not intended as, and must not 887 be construed to be, a catalog of available implementations or their 888 features. Readers are advised to note that other implementations may 889 exist. 891 According to [RFC7942], "this will allow reviewers and working groups 892 to assign due consideration to documents that have the benefit of 893 running code, which may serve as evidence of valuable experimentation 894 and feedback that have made the implemented protocols more mature. 895 It is up to the individual working groups to use this information as 896 they see fit". 898 9.1. Cisco 900 * Organization: Cisco Systems 902 * Implementation: IOS-XR PCC and PCE. 904 * Description: An experimental code-point is currently used. 906 * Maturity Level: Proof of concept. 908 * Coverage: Full. 910 * Contact: mkoldych@cisco.com 912 9.2. Juniper 914 * Organization: Juniper Networks 916 * Implementation: Head-end and controller. 918 * Description: An experimental code-point is currently used. 920 * Maturity Level: Proof of concept. 922 * Coverage: Partial. 924 * Contact: cbarth@juniper.net 926 10. Security Considerations 928 This document defines one new type for association, which do not add 929 any new security concerns beyond those discussed in [RFC5440], 930 [RFC8231], [RFC8664], [I-D.ietf-pce-segment-routing-ipv6] and 931 [RFC8697] in itself. 933 The information carried in the SRPAT ASSOCIATION, as per this 934 document is related to SR Policy. It often reflects information that 935 can also be derived from the SR Database, but association provides a 936 much easier grouping of related LSPs and messages. The SRPAT 937 ASSOCIATION could provide an adversary with the opportunity to 938 eavesdrop on the relationship between the LSPs. Thus securing the 939 PCEP session using Transport Layer Security (TLS) [RFC8253], as per 940 the recommendations and best current practices in [RFC7525], is 941 RECOMMENDED. 943 11. Acknowledgement 945 Would like to thank Stephane Litkowski, Praveen Kumar and Tom Petch 946 for review comments. 948 12. References 950 12.1. Normative References 952 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 953 Requirement Levels", BCP 14, RFC 2119, 954 DOI 10.17487/RFC2119, March 1997, 955 . 957 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 958 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 959 DOI 10.17487/RFC5440, March 2009, 960 . 962 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 963 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 964 May 2017, . 966 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 967 Computation Element Communication Protocol (PCEP) 968 Extensions for Stateful PCE", RFC 8231, 969 DOI 10.17487/RFC8231, September 2017, 970 . 972 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 973 Computation Element Communication Protocol (PCEP) 974 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 975 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 976 . 978 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 979 Code: The Implementation Status Section", BCP 205, 980 RFC 7942, DOI 10.17487/RFC7942, July 2016, 981 . 983 [I-D.ietf-spring-segment-routing-policy] 984 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 985 P. Mattes, "Segment Routing Policy Architecture", Work in 986 Progress, Internet-Draft, draft-ietf-spring-segment- 987 routing-policy-13, 28 May 2021, 988 . 991 [I-D.ietf-idr-segment-routing-te-policy] 992 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 993 Rosen, E., Jain, D., and S. Lin, "Advertising Segment 994 Routing Policies in BGP", Work in Progress, Internet- 995 Draft, draft-ietf-idr-segment-routing-te-policy-13, 7 June 996 2021, . 999 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 1000 Dhody, D., and Y. Tanaka, "Path Computation Element 1001 Communication Protocol (PCEP) Extensions for Establishing 1002 Relationships between Sets of Label Switched Paths 1003 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 1004 . 1006 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1007 and J. Hardwick, "Path Computation Element Communication 1008 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1009 DOI 10.17487/RFC8664, December 2019, 1010 . 1012 [I-D.koldychev-pce-operational] 1013 Koldychev, M., Sivabalan, S., Peng, S., Achaval, D., and 1014 H. Kotni, "PCEP Operational Clarification", Work in 1015 Progress, Internet-Draft, draft-koldychev-pce-operational- 1016 04, 19 August 2021, . 1019 [I-D.koldychev-pce-multipath] 1020 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 1021 Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for 1022 Signaling Multipath Information", Work in Progress, 1023 Internet-Draft, draft-koldychev-pce-multipath-05, 16 1024 February 2021, . 1027 12.2. Informative References 1029 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1030 Computation Element (PCE)-Based Architecture", RFC 4655, 1031 DOI 10.17487/RFC4655, August 2006, 1032 . 1034 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1035 "Recommendations for Secure Use of Transport Layer 1036 Security (TLS) and Datagram Transport Layer Security 1037 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1038 2015, . 1040 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1041 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1042 Path Computation Element Communication Protocol (PCEP)", 1043 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1044 . 1046 [I-D.ietf-pce-segment-routing-ipv6] 1047 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 1048 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 1049 Routing leveraging the IPv6 data plane", Work in Progress, 1050 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-09, 27 1051 May 2021, . 1054 Appendix A. Contributors 1056 Dhruv Dhody 1057 Huawei Technologies 1058 Divyashree Techno Park, Whitefield 1059 Bangalore, Karnataka 560066 1060 India 1062 Email: dhruv.ietf@gmail.com 1064 Cheng Li 1065 Huawei Technologies 1066 Huawei Campus, No. 156 Beiqing Rd. 1067 Beijing, 10095 1068 China 1070 Email: chengli13@huawei.com 1072 Samuel Sidor 1073 Cisco Systems, Inc. 1074 Eurovea Central 3. 1075 Pribinova 10 1076 811 09 Bratislava 1077 Slovakia 1079 Email: ssidor@cisco.com 1081 Authors' Addresses 1083 Mike Koldychev 1084 Cisco Systems, Inc. 1085 2000 Innovation Drive 1086 Kanata Ontario K2K 3E8 1087 Canada 1089 Email: mkoldych@cisco.com 1091 Siva Sivabalan 1092 Ciena Corporation 1093 385 Terry Fox Dr. 1094 Kanata Ontario K2K 0L1 1095 Canada 1097 Email: ssivabal@ciena.com 1099 Colby Barth 1100 Juniper Networks, Inc. 1102 Email: cbarth@juniper.net 1104 Shuping Peng 1105 Huawei Technologies 1106 Huawei Campus, No. 156 Beiqing Rd. 1107 Beijing 1108 100095 1109 China 1111 Email: pengshuping@huawei.com 1113 Hooman Bidgoli 1114 Nokia 1116 Email: hooman.bidgoli@nokia.com