idnits 2.17.1 draft-ietf-pce-segment-routing-policy-cp-07.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 (April 2022) is 740 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 (-26) exists of draft-ietf-idr-segment-routing-te-policy-17 == Outdated reference: A later version (-07) exists of draft-koldychev-pce-operational-05 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-13 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: 21 October 2022 Ciena Corporation 6 C. Barth 7 Juniper Networks, Inc. 8 S. Peng 9 Huawei Technologies 10 H. Bidgoli 11 Nokia 12 April 2022 14 PCEP extension to support Segment Routing Policy Candidate Paths 15 draft-ietf-pce-segment-routing-policy-cp-07 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 3 October 2022. 53 Copyright Notice 55 Copyright (c) 2022 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 Revised BSD License text as 64 described in Section 4.e of the Trust Legal Provisions and are 65 provided without warranty as described in the Revised 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 7.1. PCC Initiated SR Policy with single candidate-path . . . 16 97 7.2. PCC Initiated SR Policy with multiple candidate-paths . . 16 98 7.3. PCE Initiated SR Policy with single candidate-path . . . 17 99 7.4. PCE Initiated SR Policy with multiple candidate-paths . . 17 100 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 101 8.1. Association Type . . . . . . . . . . . . . . . . . . . . 18 102 8.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 18 103 8.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . 21 109 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 111 12.1. Normative References . . . . . . . . . . . . . . . . . . 21 112 12.2. Informative References . . . . . . . . . . . . . . . . . 23 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 control traffic streering into the LSP during the time when 637 the LSP is operationally down/invalid. In the context of SR Policy, 638 this TLV facilitate the "Drop upon invalid" behavior, specified in 639 Section 8.2 of [I-D.ietf-spring-segment-routing-policy]. Normally, 640 if the LSP is down/invalid then traffic that is originally destined 641 for that LSP is steered somewhere else, such as via IGP or via 642 another LSP. The "Drop upon invalid" behavior specifies that such 643 traffic MUST NOT be re-routed and has to be dropped at the head-end. 644 While in the "Drop upon invalid" state, the LSP operational state is 645 "UP", as indicated by the O-flag in the LSP object. However the ERO 646 object is empty, indicating that traffic is being dropped. 648 In addition to the above, this TLV can also be used by the PCC to 649 report to the PCE various reasons for LSP being invalidated. 650 Invalidation reasons are represented by a set of flags. 652 0 1 2 3 4 5 6 7 653 +-+-+-+-+-+-+-+-+ 654 | |V|P|F|U| 655 +-+-+-+-+-+-+-+-+ 657 Figure 8: Invalidation Reasons Flags 659 * U: Unknown - does not fit into any other categories below. 661 * P: Path computation failure - no path was computed for the LSP. 663 * F: First-hop resolution failure - head-end first hop resolution 664 has failed. 666 * V: Verification failure - OAM/PM/BFD path verification has 667 indicated a breakage. 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Type | Length | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Inval Reason | Drop Upon | MBZ | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 Figure 9: The INVALIDATION TLV format 679 Type: TBD3 for "INVALIDATION" TLV. 681 Length: 4. 683 Inval Reason: contains "Invalidation Reasons Flags" which encode the 684 reason(s) why the LSP is currently invalidated. This field can be 685 set to non-zero values only by the PCC, it MUST be set to 0 by the 686 PCE and ignored by the PCC. 688 Drop Upon: contains "Invalidation Reasons Flags" for conditions that 689 SHOULD cause the LSP to drop traffic. This field can be set to non- 690 zero values by both PCC and PCE. This field MAY be set to all 1's 691 (0xFF) to indicate that the LSP is to go into Drop upon invalid state 692 for any reason. I.e., when the PCE does not wish to distinguish any 693 reason for LSP invalidation and just simply wants it to always "Drop 694 upon invalid" for any reason. 696 6.4. Specified-BSID-only 698 Specified-BSID-only functionality is defined in Section 6.2.3 of 699 [I-D.ietf-spring-segment-routing-policy]. When specified-BSID-only 700 is enabled for a particular binding SID, it means that the given 701 binding SID is required to be allocated and programmed for the LSP to 702 be operationally up. If the binding SID cannot be allocated or 703 programmed for some reason, then the LSP must stay down. 705 To signal specified-BSID-only, a new bit: S (Specified-BSID-only) is 706 allocated in the "TE-PATH-BINDING TLV Flag field" of the TE-PATH- 707 BINDING TLV. When this bit is set for a particular BSID, it means 708 that the BSID follows the Specified-BSID-only behavior. It is 709 possible to have a mix of BSIDs for the same LSP: some with S=1 and 710 some with S=0. 712 7. Examples 714 7.1. PCC Initiated SR Policy with single candidate-path 716 PCReq and PCRep messages are exchanged in the following sequence: 718 1. PCC sends PCReq message to the PCE, encoding the SRPAT 719 ASSOCIATION and TLVs in the PCReq message. 721 2. PCE returns the path in PCRep message, and echoes back the SRPAT 722 ASSOCIATION. 724 PCRpt and PCUpd messages are exchanged in the following sequence: 726 1. PCC sends PCRpt message to the PCE, including the LSP object and 727 the SRPAT ASSOCIATION. 729 2. PCE computes path, possibly making use of the Association 730 Information from the SRPAT ASSOCIATION. 732 3. PCE updates the SR policy candidate path's ERO using PCUpd 733 message. 735 7.2. PCC Initiated SR Policy with multiple candidate-paths 737 PCRpt and PCUpd messages are exchanged in the following sequence: 739 1. For each candidate path of the SR Policy, the PCC generates a 740 different PLSP-ID and symbolic-name and sends multiple PCRpt 741 messages (or one message with multiple LSP objects) to the PCE. 742 Each LSP object is followed by SRPAT ASSOCIATION with identical 743 Color and Endpoint values. The Association Source is set to the 744 IP address of the PCC and the Association ID is set to a number 745 that PCC locally chose to represent the SR Policy. 747 2. PCE takes into account that all the LSPs belong to the same SR 748 policy. PCE prioritizes computation for the highest preference 749 LSP and sends PCUpd message(s) back to the PCC. 751 3. If a new candidate path is added on the PCC by the operator, then 752 a new PLSP-ID and symbolic name is generated for that candidate 753 path and a new PCRpt is sent to the PCE. 755 4. If an existing candidate path is removed from the PCC by the 756 operator, then that PLSP-ID is deleted from the PCE by sending 757 PCRpt with the R-flag in the LSP object set. 759 7.3. PCE Initiated SR Policy with single candidate-path 761 A candidate-path is created using the following steps: 763 1. PCE sends PCInitiate message, containing the SRPAT ASSOCIATION. 764 The Association Source and the Association ID are set as 765 described in Section 5.1. 767 2. PCC uses the color, endpoint and preference from the SRPAT 768 ASSOCIATION to create a new candidate path. If no SR policy 769 exists to hold the candidate path, then a new SR policy is 770 created to hold the new candidate-path. The Originator of the 771 candidate path is set to be the address of the PCE that is 772 sending the PCInitiate message. 774 3. PCC sends a PCRpt message back to the PCE to report the newly 775 created Candidate Path. The PCRpt message contains the SRPAT 776 ASSOCIATION. 778 A candidate-path is deleted using the following steps: 780 1. PCE sends PCInitiate message, setting the R-flag in the LSP 781 object. 783 2. PCC uses the PLSP-ID from the LSP object to find the candidate 784 path and delete it. If this is the last candidate path under the 785 SR policy, then the containing SR policy is deleted as well. 787 7.4. PCE Initiated SR Policy with multiple candidate-paths 789 A candidate-path is created using the following steps: 791 1. PCE SHOULD send a separate PCInitiate message for every candidate 792 path that it wants to create, or it MAY send multiple LSP objects 793 within a single PCInitiate message. The SRPAT ASSOCIATION is 794 sent for every LSP in the PCInitiate message. The Association 795 Source and the Association ID are set as described in 796 Section 5.1. 798 2. PCC creates multiple candidate paths under the same SR policy, 799 identified by Color and Endpoint. 801 3. PCC sends a PCRpt message back to the PCE to report the newly 802 created Candidate Path. The PCRpt message contains the SRPAT 803 ASSOCIATION. The Association Source and the Association ID are 804 set as described in Section 5.1. 806 A candidate path is deleted using the following steps: 808 1. PCE sends PCInitiate message, setting the R-flag in the LSP 809 object. 811 2. PCC uses the PLSP-ID from the LSP object to find the candidate 812 path and delete it. 814 8. IANA Considerations 816 8.1. Association Type 818 This document defines a new association type: SR Policy Association. 819 IANA is requested to make the following codepoint assignment in the 820 "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path 821 Computation Element Protocol (PCEP) Numbers" registry: 823 +-----------+-------------------------------------------+-----------+ 824 | Type | Name | Reference | 825 +-----------+-------------------------------------------+-----------+ 826 | 6 | SR Policy Association | This.I-D | 827 +-----------+-------------------------------------------+-----------+ 829 8.2. PCEP TLV Type Indicators 831 This document defines four new TLVs for carrying additional 832 information about SR policy and SR candidate paths. IANA is 833 requested to make the assignment of a new value for the existing 834 "PCEP TLV Type Indicators" registry as follows: 836 +-----------+-------------------------------------------+-----------+ 837 | Value | Description | Reference | 838 +-----------+-------------------------------------------+-----------+ 839 | 56 | SRPOLICY-POL-NAME | This.I-D | 840 +-----------+-------------------------------------------+-----------+ 841 | 57 | SRPOLICY-CPATH-ID | This.I-D | 842 +-----------+-------------------------------------------+-----------+ 843 | 58 | SRPOLICY-CPATH-NAME | This.I-D | 844 +-----------+-------------------------------------------+-----------+ 845 | 59 | SRPOLICY-CPATH-PREFERENCE | This.I-D | 846 +-----------+-------------------------------------------+-----------+ 847 | TBD1 | COMPUTATION-PRIORITY | This.I-D | 848 +-----------+-------------------------------------------+-----------+ 849 | TBD2 | EXPLICIT-NULL-LABEL-POLICY | This.I-D | 850 +-----------+-------------------------------------------+-----------+ 851 | TBD3 | INVALIDATION | This.I-D | 852 +-----------+-------------------------------------------+-----------+ 854 8.3. PCEP Errors 856 This document defines one new Error-Value within the "Mandatory 857 Object Missing" Error-Type and two new Error-Values within the 858 "Association Error" Error-Type. IANA is requested to allocate new 859 error values within the "PCEP-ERROR Object Error Types and Values" 860 sub-registry of the PCEP Numbers registry, as follows: 862 +------------+------------------+-----------------------+-----------+ 863 | Error-Type | Meaning | Error-value | Reference | 864 +------------+------------------+-----------------------+-----------+ 865 | 6 | Mandatory Object | | [RFC5440] | 866 | | Missing | | | 867 +------------+------------------+-----------------------+-----------+ 868 | | | TBD6: SR Policy | This.I-D | 869 | | | Missing Mandatory TLV | | 870 +------------+------------------+-----------------------+-----------+ 871 | 26 | Association | | [RFC8697] | 872 | | Error | | | 873 +------------+------------------+-----------------------+-----------+ 874 | | | TBD7: SR Policy | This.I-D | 875 | | | Identifers Mismatch | | 876 +------------+------------------+-----------------------+-----------+ 877 | | | TBD8: SR Policy | This.I-D | 878 | | | Candidate Path | | 879 | | | Identifiers Mismatch | | 880 +------------+------------------+-----------------------+-----------+ 882 8.4. TE-PATH-BINDING TLV Flag field 884 IANA is requested to allocate new bit within the "TE-PATH-BINDING TLV 885 Flag field" sub-registry of the PCEP Numbers registry, as follows: 887 +------------+------------------------------------------+-----------+ 888 | Bit position | Description | Reference | 889 +--------------+----------------------------------------+-----------+ 890 | 1 | Specified-BSID-only | This.I-D | 891 +--------------+----------------------------------------+-----------+ 893 9. Implementation Status 895 [Note to the RFC Editor - remove this section before publication, as 896 well as remove the reference to RFC 7942.] 898 This section records the status of known implementations of the 899 protocol defined by this specification at the time of posting of this 900 Internet-Draft, and is based on a proposal described in [RFC7942]. 901 The description of implementations in this section is intended to 902 assist the IETF in its decision processes in progressing drafts to 903 RFCs. Please note that the listing of any individual implementation 904 here does not imply endorsement by the IETF. Furthermore, no effort 905 has been spent to verify the information presented here that was 906 supplied by IETF contributors. This is not intended as, and must not 907 be construed to be, a catalog of available implementations or their 908 features. Readers are advised to note that other implementations may 909 exist. 911 According to [RFC7942], "this will allow reviewers and working groups 912 to assign due consideration to documents that have the benefit of 913 running code, which may serve as evidence of valuable experimentation 914 and feedback that have made the implemented protocols more mature. 915 It is up to the individual working groups to use this information as 916 they see fit". 918 9.1. Cisco 920 * Organization: Cisco Systems 922 * Implementation: IOS-XR PCC and PCE. 924 * Description: An experimental code-point is currently used. 926 * Maturity Level: Proof of concept. 928 * Coverage: Full. 930 * Contact: mkoldych@cisco.com 932 9.2. Juniper 934 * Organization: Juniper Networks 936 * Implementation: Head-end and controller. 938 * Description: An experimental code-point is currently used. 940 * Maturity Level: Proof of concept. 942 * Coverage: Partial. 944 * Contact: cbarth@juniper.net 946 10. Security Considerations 948 This document defines one new type for association, which do not add 949 any new security concerns beyond those discussed in [RFC5440], 950 [RFC8231], [RFC8664], [I-D.ietf-pce-segment-routing-ipv6] and 951 [RFC8697] in itself. 953 The information carried in the SRPAT ASSOCIATION, as per this 954 document is related to SR Policy. It often reflects information that 955 can also be derived from the SR Database, but association provides a 956 much easier grouping of related LSPs and messages. The SRPAT 957 ASSOCIATION could provide an adversary with the opportunity to 958 eavesdrop on the relationship between the LSPs. Thus securing the 959 PCEP session using Transport Layer Security (TLS) [RFC8253], as per 960 the recommendations and best current practices in [RFC7525], is 961 RECOMMENDED. 963 11. Acknowledgement 965 Would like to thank Stephane Litkowski, Boris Khasanov, Praveen Kumar 966 and Tom Petch for review and suggestions. 968 12. References 970 12.1. Normative References 972 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 973 Requirement Levels", BCP 14, RFC 2119, 974 DOI 10.17487/RFC2119, March 1997, 975 . 977 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 978 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 979 DOI 10.17487/RFC5440, March 2009, 980 . 982 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 983 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 984 May 2017, . 986 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 987 Computation Element Communication Protocol (PCEP) 988 Extensions for Stateful PCE", RFC 8231, 989 DOI 10.17487/RFC8231, September 2017, 990 . 992 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 993 Computation Element Communication Protocol (PCEP) 994 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 995 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 996 . 998 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 999 Code: The Implementation Status Section", BCP 205, 1000 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1001 . 1003 [I-D.ietf-spring-segment-routing-policy] 1004 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 1005 P. Mattes, "Segment Routing Policy Architecture", Work in 1006 Progress, Internet-Draft, draft-ietf-spring-segment- 1007 routing-policy-22, 22 March 2022, 1008 . 1011 [I-D.ietf-idr-segment-routing-te-policy] 1012 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 1013 Jain, D., and S. Lin, "Advertising Segment Routing 1014 Policies in BGP", Work in Progress, Internet-Draft, draft- 1015 ietf-idr-segment-routing-te-policy-17, 14 April 2022, 1016 . 1019 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 1020 Dhody, D., and Y. Tanaka, "Path Computation Element 1021 Communication Protocol (PCEP) Extensions for Establishing 1022 Relationships between Sets of Label Switched Paths 1023 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 1024 . 1026 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1027 and J. Hardwick, "Path Computation Element Communication 1028 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1029 DOI 10.17487/RFC8664, December 2019, 1030 . 1032 [I-D.koldychev-pce-operational] 1033 Koldychev, M., Sivabalan, S., Peng, S., Achaval, D., and 1034 H. Kotni, "PCEP Operational Clarification", Work in 1035 Progress, Internet-Draft, draft-koldychev-pce-operational- 1036 05, 19 February 2022, . 1039 [I-D.koldychev-pce-multipath] 1040 Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P., 1041 Bidgoli, H., Yadav, B., and S. Peng, "PCEP Extensions for 1042 Signaling Multipath Information", Work in Progress, 1043 Internet-Draft, draft-koldychev-pce-multipath-05, 16 1044 February 2021, . 1047 12.2. Informative References 1049 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1050 Computation Element (PCE)-Based Architecture", RFC 4655, 1051 DOI 10.17487/RFC4655, August 2006, 1052 . 1054 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1055 "Recommendations for Secure Use of Transport Layer 1056 Security (TLS) and Datagram Transport Layer Security 1057 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1058 2015, . 1060 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 1061 "PCEPS: Usage of TLS to Provide a Secure Transport for the 1062 Path Computation Element Communication Protocol (PCEP)", 1063 RFC 8253, DOI 10.17487/RFC8253, October 2017, 1064 . 1066 [I-D.ietf-pce-segment-routing-ipv6] 1067 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 1068 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 1069 Routing leveraging the IPv6 data plane", Work in Progress, 1070 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-13, 1 1071 April 2022, . 1074 Appendix A. Contributors 1075 Dhruv Dhody 1076 Huawei Technologies 1077 Divyashree Techno Park, Whitefield 1078 Bangalore, Karnataka 560066 1079 India 1081 Email: dhruv.ietf@gmail.com 1083 Cheng Li 1084 Huawei Technologies 1085 Huawei Campus, No. 156 Beiqing Rd. 1086 Beijing, 10095 1087 China 1089 Email: chengli13@huawei.com 1091 Samuel Sidor 1092 Cisco Systems, Inc. 1093 Eurovea Central 3. 1094 Pribinova 10 1095 811 09 Bratislava 1096 Slovakia 1098 Email: ssidor@cisco.com 1100 Authors' Addresses 1102 Mike Koldychev 1103 Cisco Systems, Inc. 1104 2000 Innovation Drive 1105 Kanata Ontario K2K 3E8 1106 Canada 1107 Email: mkoldych@cisco.com 1109 Siva Sivabalan 1110 Ciena Corporation 1111 385 Terry Fox Dr. 1112 Kanata Ontario K2K 0L1 1113 Canada 1114 Email: ssivabal@ciena.com 1116 Colby Barth 1117 Juniper Networks, Inc. 1118 Email: cbarth@juniper.net 1119 Shuping Peng 1120 Huawei Technologies 1121 Huawei Campus, No. 156 Beiqing Rd. 1122 Beijing 1123 100095 1124 China 1125 Email: pengshuping@huawei.com 1127 Hooman Bidgoli 1128 Nokia 1129 Email: hooman.bidgoli@nokia.com