idnits 2.17.1 draft-barth-pce-segment-routing-policy-cp-02.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 (March 05, 2019) is 1877 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-02 == Outdated reference: A later version (-10) exists of draft-ietf-pce-association-group-07 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group C. Barth 3 Internet-Draft Juniper Networks, Inc. 4 Intended status: Standards Track M. Koldychev 5 Expires: September 6, 2019 S. Sivabalan 6 Cisco Systems, Inc. 7 C. Li 8 Huawei Technologies 9 March 05, 2019 11 PCEP extension to support Segment Routing Policy Candidate Paths 12 draft-barth-pce-segment-routing-policy-cp-02 14 Abstract 16 This document introduces a mechanism to specify an Segment Routing 17 (SR) policy, as a collection of SR candidate paths. An SR policy is 18 identified by tuple. An SR policy can 19 contain one or more candidate paths where each candidate path is 20 identified in PCEP via an PLSP-ID. This document proposes extension 21 to PCEP to support association among candidate paths of a given SR 22 policy. The mechanism proposed in this document is applicable to 23 both MPLS and IPv6 data planes of SR. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in BCP 30 14 [RFC2119] [RFC8174] when, and only when, they appear in all 31 capitals, as shown here. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on September 6, 2019. 50 Copyright Notice 52 Copyright (c) 2019 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Group Candidate Paths belonging to the same SR policy . . 5 71 3.2. Instantiation of SR policy candidate paths . . . . . . . 5 72 3.3. Avoid computing lower preference candidate paths . . . . 5 73 3.4. Minimal signaling overhead . . . . . . . . . . . . . . . 5 74 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 5. SR Policy Association Group . . . . . . . . . . . . . . . . . 7 76 5.1. SR Policy Association Group Policy Identifiers TLV . . . 8 77 5.2. SR Policy Association Group Candidate Path Identifiers 78 TLV . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 5.3. SR Policy Association Group Candidate Path Attributes TLV 10 80 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6.1. PCC Initiated SR Policy with single candidate-path . . . 11 82 6.2. PCC Initiated SR Policy with multiple candidate-paths . . 11 83 6.3. PCE Initiated SR Policy with single candidate-path . . . 12 84 6.4. PCE Initiated SR Policy with multiple candidate-paths . . 13 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 86 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 13 87 7.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 13 88 7.3. SRPAG TLVs . . . . . . . . . . . . . . . . . . . . . . . 14 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 93 10.2. Informative References . . . . . . . . . . . . . . . . . 16 94 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 16 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 Path Computation Element (PCE) Communication Protocol (PCEP) 100 [RFC5440] enables the communication between a Path Computation Client 101 (PCC) and a Path Control Element (PCE), or between two PCEs based on 102 the PCE architecture [RFC4655]. 104 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 105 of extensions to PCEP to enable active control of Multiprotocol Label 106 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 107 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 108 LSPs under the active stateful PCE model, without the need for local 109 configuration on the PCC, thus allowing for dynamic centralized 110 control of a network. 112 PCEP Extensions for Segment Routing [I-D.ietf-pce-segment-routing] 113 specifies extensions to the Path Computation Element Protocol (PCEP) 114 that allow a stateful PCE to compute and initiate Traffic Engineering 115 (TE) paths, as well as a PCC to request a path subject to certain 116 constraint(s) and optimization criteria in SR networks. 118 PCEP Extensions for Establishing Relationships Between Sets of LSPs 119 [I-D.ietf-pce-association-group] introduces a generic mechanism to 120 create a grouping of LSPs which can then be used to define 121 associations between a set of LSPs and a set of attributes (such as 122 configuration parameters or behaviors) and is equally applicable to 123 stateful PCE (active and passive modes) and stateless PCE. 125 Segment Routing Policy for Traffic Engineering 126 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 127 Policy and approaches to steering traffic into an SR Policy. 129 An SR policy contains one or more candidate paths where one or more 130 such paths can be computed via PCE. This document specifies PCEP 131 extensions to signal additional information to map candidate paths to 132 their SR policies. Each candidate path maps to a unique PLSP-ID in 133 PCEP. By associating multiple candidate paths together, a PCE 134 becomes aware of the hierarchical structure of an SR policy. Thus 135 the PCE can take computation and control decisions about the 136 candidate paths, with the additional knowledge that these candidate 137 paths belong to the same SR policy. This is accomplished via the use 138 of the existing PCEP Association object, by defining a new 139 association type specifically for associating SR candidate paths into 140 a single SR policy. 142 [Editor's Note- Currently it is assumed that each candidate path has 143 only one ERO (SID-List) within the scope of this document. A future 144 update or another document will deal with a way to allow multiple 145 ERO/SID-Lists for a candidate path within PCEP.] 147 2. Terminology 149 The following terminologies are used in this document: 151 Endpoint: The IPv4 or IPv6 endpoint address of the SR policy in 152 question, as described in 153 [I-D.ietf-spring-segment-routing-policy]. 155 Association parameters: As described in 156 [I-D.ietf-pce-association-group], the combination of the mandatory 157 fields Association type, Association ID and Association Source in 158 the ASSOCIATION object uniquely identify the association group. 159 If the optional TLVs - Global Association Source or Extended 160 Association ID are included, then they MUST be included in 161 combination with mandatory fields to uniquely identify the 162 association group. 164 Association information: As described in 165 [I-D.ietf-pce-association-group], the ASSOCIATION object could 166 also include other optional TLVs based on the association types, 167 that provides 'information' related to the association type. 169 PCC: Path Computation Client. Any client application requesting a 170 path computation to be performed by a Path Computation Element. 172 PCE: Path Computation Element. An entity (component, application, 173 or network node) that is capable of computing a network path or 174 route based on a network graph and applying computational 175 constraints. 177 PCEP: Path Computation Element Protocol. 179 3. Motivation 181 The new Association Type (SR Policy Association) and the new TLVs for 182 the ASSOCIATION object, defined in this document, allow a PCEP peer 183 to exchange additional parameters of SR candidate paths and of their 184 parent SR policy. For the SR policy, the parameters are: color and 185 endpoint. For the candidate path, the parameters are: protocol 186 origin, originator, discriminator and preference. 187 [I-D.ietf-spring-segment-routing-policy] describes the concept of SR 188 Policy and these parameters. 190 The motivation for signaling these parameters is summarized in the 191 following subsections. 193 3.1. Group Candidate Paths belonging to the same SR policy 195 Since each candidate path of an SR policy appears as a different LSP 196 (identified via a PLSP-ID) in PCEP, it is useful to group together 197 all the candidate paths that belong to the same SR policy. 198 Furthermore, it is useful for the PCE to have knowledge of the SR 199 candidate path parameters such as color, protocol origin, 200 discriminator, and preference. 202 3.2. Instantiation of SR policy candidate paths 204 A PCE may want to instantiate one or more candidate paths on the PCC, 205 as specified in [RFC8281]. In this scenario, the PCE needs to signal 206 to a PCC tuple using which the PCC can instantiate a candidate 208 path for the SR policy identified. Current PCEP standards (as of the 209 time of this writing) do not provide a way to signal color and 210 preference. Although end-point can be signaled via the PCEP END- 211 POINTS object, this object may not be suitable because the end-point 212 to which the path is computed is not required to be the same IPv4/ 213 IPv6 address as the actual endpoint of the SR policy. Thus, a 214 separate way to specify SR policy's end-point is provided in this 215 document. 217 3.3. Avoid computing lower preference candidate paths 219 When a PCE knows that a given set of candidate paths all belong to 220 the same SR policy, then path computation MAY be done on only the 221 highest preference candidate-path(s). Path computation for lower 222 preference paths is not necessary if one or two higher preference 223 paths are already computed. Since computing their paths will not 224 affect traffic steering, it MAY be postponed until the higher 225 preference paths become invalid, thus saving computation resources on 226 the PCE. 228 3.4. Minimal signaling overhead 230 When an SR policy contains multiple candidate paths computed by a 231 PCE, such candidate paths can be created, updated and deleted 232 independently of each other. This is achieved by making each 233 candidate path correspond to a unique LSP (identified via PLSP-ID). 234 For example, if an SR policy has 4 candidate paths, then if the PCE 235 wants to update one of those candidate paths, only one set of PCUpd 236 and PCRpt messages needs to be exchanged. 238 4. Overview 240 As per [I-D.ietf-pce-association-group], LSPs are placed into an 241 association group. In this document, each LSP corresponds to a 242 candidate path of an SR policy, and the association group corresponds 243 to the SR policy itself. Segment-lists within a candidate path are 244 not represented by different LSPs (and identified via PLSP-IDs). 246 [Editor's Note - The subject of encoding multiple segment lists 247 within a candidate path is left to a future document and is not 248 specified in this document. It is not a good idea to have each 249 segment-list correspond to a different LSP/PLSP-ID, because when the 250 PCC wants to get a path, it must know in advance how many multipaths 251 (i.e., segment-lists) there will be and create that many LSPs/PLSP- 252 IDs. For example, if the PCC supports 32 multipaths, then it must 253 delegate 32 LSPs/PLSP-IDs for every candidate path, which may not be 254 scalable.] 256 A new Association Type is defined in this document, based on the 257 generic ASSOCIATION object. Association type = TBD1 "SR Policy 258 Association Type" for SR Policy Association Group (SRPAG). 260 The SRPAG Association is only meant to be used for SR LSPs and with 261 PCEP peers which advertise SR capability. 263 An Association object of SRPAG group contains TLVs that carry 264 Association Information. The association information can be 265 subdivided into three parts: Policy identifiers, Candidate path 266 identifiers, and Candidate path attributes. 268 Policy Identifiers uniquely identify the SR policy to which a given 269 LSP belongs, within the context of the head-end. Policy Identifiers 270 MUST be the same for all candidate paths in the same SRPAG. Policy 271 Identifiers MUST NOT change for a given LSP during its lifetime. 272 Policy Identifiers MUST be different for different SRPAG 273 associations. When these rules are not satisfied, the PCE MUST send 274 a PCErr message with Error Code = 26 "Association Error", Error Type 275 = TBD5 "Conflicting SRPAG TLV". Policy Identifiers consist of: 277 o Color of SR policy. 279 o End-point of SR policy. 281 Candidate Path Identifiers uniquely identify the SR candidate path 282 within the context of an SR policy. Candidate path Identifiers MUST 283 NOT change for a given LSP during its lifetime. Candidate path 284 Identifiers MUST be different for different LSPs within the same 285 SRPAG. When these rules are not satisfied, the PCE MUST send a PCErr 286 message with Error Code = 26 "Association Error", Error Type = TBD5 287 "Conflicting SRPAG TLV". Candidate path Identifiers consist of: 289 o Protocol Origin of candidate path. 291 o Originator of candidate path. 293 o Discriminator of candidate path. 295 Candidate Path Attributes MUST NOT be used to identify the candidate 296 path. Candidate path attributes carry additional information about 297 the candidate path and MAY change during the lifetime of the LSP. 298 Candidate path Attributes consist of: 300 o Preference of candidate path. 302 As described in [RFC8231], an LSP is uniquely identified in PCEP via 303 PLSP-ID. 305 A mapping between the Association Parameters (see Section 2) and 306 Policy Identifiers (the Color and End-point) needs to be maintained. 307 The mapping is left up to the implementation. An implementation MAY 308 choose Association Parameters in such a way that every possible Color 309 and End-point maps to a unique value of Association Parameters, which 310 may require the use of Extended Association ID TLV. Alternatively, 311 an implementation MAY implement a lookup table to generate 312 Association Parameters incrementally as new Color and End-point 313 values are created, which may not require the use of Extended 314 Association ID TLV. 316 As per the processing rules specified in section 5.4 of 317 [I-D.ietf-pce-association-group], if a PCEP speaker does not support 318 the SRPAG association type, it MUST return a PCErr message with 319 Error-Type 26 (Early allocation by IANA) "Association Error" and 320 Error-Value 1 "Association-type is not supported". Please note that 321 the corresponding PCEP session is not reset. 323 5. SR Policy Association Group 325 Two ASSOCIATION object types for IPv4 and IPv6 are defined in 326 [I-D.ietf-pce-association-group]. The ASSOCIATION object includes 327 "Association type" indicating the type of the association group. 328 This document adds a new Association type. 330 Association type = TBD1 "SR Policy Association Type" for SR Policy 331 Association Group (SRPAG). 333 The operator configured Association Range SHOULD NOT be set for this 334 association type and MUST be ignored. 336 SRPAG MUST carry additional TLVs to communicate Association 337 Information. This document specifies three new TLVs to carry 338 Association Information: SRPAG-POL-ID-TLV, SRPAG-CPATH-ID-TLV, SRPAG- 339 CPATH-ATTR-TLV. These three TLVs encode the Policy Identifiers, 340 Candidate path Identifiers and Candidate path Attributes, 341 respectively. When any of the mandatory TLVs are missing from the 342 SRPAG association object, the PCE MUST send a PCErr message with 343 Error Code = 26 "Association Error", Error Type = TBD6 "Missing 344 mandatory SRPAG TLV". 346 A given LSP MUST belong to at most one SRPAG, since a candidate path 347 cannot belong to multiple SR policies. If a PCEP speaker receives a 348 PCEP message with more than one SRPAG for an LSP, then the PCEP 349 speaker MUST send a PCErr message with Error-Type 26 "Association 350 Error" and Error-Value TBD7 "Multiple SRPAG for one LSP". If the 351 message is a PCRpt message, then the PCEP speaker MUST close the PCEP 352 connection. Closing the PCEP connection is necessary because 353 ignoring PCRpt messages may lead to inconsistent LSP DB state between 354 the two PCEP peers. 356 If the PCEP speaker receives the SRPAG association when the SR 357 capability (as per [I-D.ietf-pce-segment-routing] or 358 [I-D.negi-pce-segment-routing-ipv6]) was not exchanged, the PCEP 359 speaker MUST send a PCErr message with Error-Type 26 "Association 360 Error" and Error-Value TBD8 "Use of SRPAG without SR capability 361 exchange". If the Path Setup Type (PST) of the LSP in SRPAG is not 362 set to SR or SRv6, then the PCEP speaker MUST send a PCErr message 363 with Error-Type 26 "Association Error" and Error-Value TBD9 "non-SR 364 LSP in SRPAG". 366 5.1. SR Policy Association Group Policy Identifiers TLV 368 The SRPOLICY-POL-ID TLV is a mandatory TLV for the SRPAG Association. 369 Only one SRPOLICY-POL-ID TLV can be carried and only the first 370 occurrence is processed and any others MUST be ignored. 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type | Length | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Color | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 ~ End-point ~ 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 Figure 1: The SRPOLICY-POL-ID TLV format 384 Type: TBD2 for "SRPOLICY-POL-ID" TLV. 386 Length: 8 or 20, depending on length of End-point (IPv4 or IPv6) 388 Color: any unsigned 32-bit number. 390 End-point: can be either IPv4 or IPv6, depending on whether the 391 policy endpoint has IPv4 or IPv6 address. This value may be 392 different from the one contained in the END-POINTS object, or in the 393 LSP IDENTIFIERS TLV of the LSP object. Endpoint is meant to strictly 394 correspond to the endpoint of the SR policy, as it is defined in 395 [I-D.ietf-spring-segment-routing-policy]. 397 5.2. SR Policy Association Group Candidate Path Identifiers TLV 399 The SRPOLICY-CPATH-ID TLV is a mandatory TLV for the SRPAG 400 Association. Only one SRPOLICY-CPATH-ID TLV can be carried and only 401 the first occurrence is processed and any others MUST be ignored. 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type | Length | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Proto. Origin | Reserved | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Originator ASN | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | 413 | Originator Address | 414 | | 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Discriminator | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 Figure 2: The SRPOLICY-CPATH-ID TLV format 422 Type: TBD3 for "SRPOLICY-CPATH-ID" TLV. 424 Length: 28. 426 Protocol Origin: 8-bit value that encodes the protocol origin, as 427 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.3. 429 Reserved: MUST be set to zero on transmission and ignored on receipt. 431 Originator ASN: Represented as 4 byte number, part of the originator 432 identifier, as specified in [I-D.ietf-spring-segment-routing-policy] 433 Section 2.4. 435 Originator Address: Represented as 128 bit value where IPv4 address 436 are encoded in lowest 32 bits, part of the originator identifier, as 437 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.4. 439 Discriminator: 32-bit value that encodes the Discriminator of the 440 candidate path. 442 5.3. SR Policy Association Group Candidate Path Attributes TLV 444 The SRPOLICY-CPATH-ATTR TLV is an optional TLV for the SRPAG 445 Association. Only one SRPOLICY-CPATH-ATTR TLV can be carried and 446 only the first occurrence is processed and any others MUST be 447 ignored. 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type | Length | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Preference | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 3: The SRPOLICY-CPATH-ATTR TLV format 459 Type: TBD4 for "SRPOLICY-CPATH-ATTR" TLV. 461 Length: 4. 463 Preference: Numerical preference of the candidate path, as specified 464 in [I-D.ietf-spring-segment-routing-policy] Section 2.7. 466 If the TLV is missing, a default preference of 100 as specified in 467 [I-D.ietf-spring-segment-routing-policy] is used. 469 6. Examples 471 6.1. PCC Initiated SR Policy with single candidate-path 473 PCReq and PCRep messages are exchanged in the following sequence: 475 1. PCC sends PCReq message to the PCE, encoding the SRPAG 476 ASSOCIATION object and TLVs in the PCReq message. 478 2. PCE returns the path in PCRep message, and echoes back the SRPAG 479 object that was used in the computation. 481 PCRpt and PCUpd messages are exchanged in the following sequence: 483 1. PCC sends PCRpt message to the PCE, including the LSP object and 484 the SRPAG ASSOCIATION object. 486 2. PCE computes path, possibly making use of the Association 487 Information from the SRPAG ASSOCIATION object. 489 3. PCE updates the SR policy candidate path's ERO using PCUpd 490 message. 492 6.2. PCC Initiated SR Policy with multiple candidate-paths 494 PCReq and PCRep messages are exchanged using the sequence specified 495 in section 6.1 with individual query for each candidate-path. 497 PCRpt and PCUpd messages are exchanged in the following sequence: 499 1. Step 1: For each candidate path of the SR policy, the PCC 500 generates a different PLSP-ID and symbolic-name and sends 501 multiple PCRpt messages (or one message with multiple LSP 502 objects) to the PCE. Each LSP object is followed by SRPAG 503 ASSOCIATION object with identical Color and Endpoint values. 505 2. Step 2: PCE takes into account that all the LSPs belong to the 506 same SR policy. PCE prioritizes computation for the highest 507 preference LSP and sends PCUpd message(s) back to the PCC. 509 3. Step 3: If a new candidate path is added on the PCC by the 510 operator, then a new PLSP-ID and symbolic name is generated for 511 that candidate path and a new PCRpt is sent to the PCE. 513 4. Step 4: If an existing candidate path is removed from the PCC by 514 the operator, then that PLSP-ID is deleted from the PCE by 515 sending PCRpt with the R-flag in the LSP object set. 517 6.3. PCE Initiated SR Policy with single candidate-path 519 A candidate-path is created using the following steps: 521 1. PCE sends PCInitiate message, as usual containing the SRPAG 522 Association object. PCE needs to generate a symbolic-name for 523 this LSP that will not clash with other symbolic names on the 524 same PCC. 526 2. PCC uses the color, endpoint and preference from the SRPAG object 527 to create a new candidate path. If no SR policy exists to hold 528 the candidate path, then a new SR policy is created to hold the 529 new candidate-path. The Originator of the candidate path is set 530 to be the address of the PCE that is sending the PCInitiate 531 message. 533 3. PCC allocates a locally unique PLSP-ID for the newly created 534 candidate path. This PLSP-ID is sent to the PCE in the PCRpt 535 message. 537 A candidate-path is deleted using the following steps: 539 1. PCE sends PCInitiate message, setting the R-flag in the LSP 540 object. 542 2. PCC uses the PLSP-ID from the LSP object to find the candidate 543 path and delete it. If this is the last candidate path under the 544 SR policy, then the containing SR policy is deleted as well. 546 6.4. PCE Initiated SR Policy with multiple candidate-paths 548 A candidate-path is created using the following steps: 550 1. PCE sends a separate PCInitiate message for every candidate path 551 that it wants to create, or it sends multiple LSP objects within 552 a single PCInitiate message. Each candidate-path must get a 553 unique symbolic-name generated on the PCE. SRPAG object is sent 554 for every LSP in the PCInitiate message. 556 2. PCC creates multiple candidate paths under the same SR policy, 557 identified by Color and Endpoint. PCC generates a unique PLSP-ID 558 for every candidate path. 560 3. PCC allocates a locally unique PLSP-ID for each newly created 561 candidate path. This PLSP-ID is sent to the PCE in the PCRpt 562 message. 564 A candidate path is deleted using the following steps: 566 1. PCE sends PCInitiate message, setting the R-flag in the LSP 567 object. 569 2. PCC uses the PLSP-ID from the LSP object to find the candidate 570 path and delete it. 572 7. IANA Considerations 574 7.1. Association Type 576 This document defines a new association type: SR Policy Association 577 Group (SRPAG). IANA is requested to make the assignment of a new 578 value for the sub-registry "ASSOCIATION Type Field" (request to be 579 created in [I-D.ietf-pce-association-group]), as follows: 581 +----------------------+-------------------------+------------------+ 582 | Association Type | Association Name | Reference | 583 | Value | | | 584 +----------------------+-------------------------+------------------+ 585 | TBD1 | SR Policy Association | This document | 586 +----------------------+-------------------------+------------------+ 588 7.2. PCEP Errors 590 This document defines three new Error-Values within the "Association 591 Error" Error-Type. IANA is requested to allocate new error values 592 within the "PCEP-ERROR Object Error Types and Values" sub-registry of 593 the PCEP Numbers registry, as follows: 595 +-------+----------+-----------------------------+------------------+ 596 | Error | Error | Meaning | Reference | 597 | Type | Value | | | 598 +-------+----------+-----------------------------+------------------+ 599 | 29 | TBD5 | Conflicting SRPAG TLV | This document | 600 +-------+----------+-----------------------------+------------------+ 601 | 29 | TBD6 | Missing mandatory SRPAG TLV | This document | 602 +-------+----------+-----------------------------+------------------+ 603 | 29 | TBD7 | Multiple SRPAG for one LSP | This document | 604 +-------+----------+-----------------------------+------------------+ 605 | 29 | TBD8 | Use of SRPAG without SR | This document | 606 | | | capability exchange | | 607 +-------+----------+-----------------------------+------------------+ 608 | 29 | TBD9 | non-SR LSP in SRPAG | This document | 609 +-------+----------+-----------------------------+------------------+ 611 7.3. SRPAG TLVs 613 This document defines three new TLVs for carrying additional 614 information about SR policy and SR candidate paths. IANA is 615 requested to make the assignment of a new value for the existing 616 "PCEP TLV Type Indicators" registry as follows: 618 +------------+-----------------------------------+------------------+ 619 | TLV Type | TLV Name | Reference | 620 | Value | | | 621 +------------+-----------------------------------+------------------+ 622 | TBD2 | SRPOLICY-POL-ID | This document | 623 +------------+-----------------------------------+------------------+ 624 | TBD3 | SRPOLICY-CPATH-ID | This document | 625 +------------+-----------------------------------+------------------+ 626 | TBD4 | SRPOLICY-CPATH-ATTR | This document | 627 +------------+-----------------------------------+------------------+ 629 8. Security Considerations 631 This document defines one new type for association, which do not add 632 any new security concerns beyond those discussed in [RFC5440], 633 [RFC8231], [I-D.ietf-pce-segment-routing], 634 [I-D.negi-pce-segment-routing-ipv6] and 635 [I-D.ietf-pce-association-group] in itself. 637 The information carried in the SRPAG Association object, as per this 638 document is related to SR Policy. It often reflects information that 639 can also be derived from the SR Database, but association provides a 640 much easier grouping of related LSPs and messages. The SRPAG 641 association could provides an adversary with the opportunity to 642 eavesdrop on the relationship between the LSPs. Thus securing the 643 PCEP session using Transport Layer Security (TLS) [RFC8253], as per 644 the recommendations and best current practices in [RFC7525], is 645 RECOMMENDED. 647 9. Acknowledgement 649 10. References 651 10.1. Normative References 653 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 654 Requirement Levels", BCP 14, RFC 2119, 655 DOI 10.17487/RFC2119, March 1997, 656 . 658 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 659 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 660 DOI 10.17487/RFC5440, March 2009, 661 . 663 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 664 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 665 May 2017, . 667 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 668 Computation Element Communication Protocol (PCEP) 669 Extensions for Stateful PCE", RFC 8231, 670 DOI 10.17487/RFC8231, September 2017, 671 . 673 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 674 Computation Element Communication Protocol (PCEP) 675 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 676 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 677 . 679 [I-D.ietf-spring-segment-routing-policy] 680 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 681 bogdanov@google.com, b., and P. Mattes, "Segment Routing 682 Policy Architecture", draft-ietf-spring-segment-routing- 683 policy-02 (work in progress), October 2018. 685 [I-D.ietf-pce-association-group] 686 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 687 Dhody, D., and Y. Tanaka, "PCEP Extensions for 688 Establishing Relationships Between Sets of LSPs", draft- 689 ietf-pce-association-group-07 (work in progress), December 690 2018. 692 [I-D.ietf-pce-segment-routing] 693 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 694 and J. Hardwick, "PCEP Extensions for Segment Routing", 695 draft-ietf-pce-segment-routing-16 (work in progress), 696 March 2019. 698 10.2. Informative References 700 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 701 Element (PCE)-Based Architecture", RFC 4655, 702 DOI 10.17487/RFC4655, August 2006, 703 . 705 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 706 "Recommendations for Secure Use of Transport Layer 707 Security (TLS) and Datagram Transport Layer Security 708 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 709 2015, . 711 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 712 "PCEPS: Usage of TLS to Provide a Secure Transport for the 713 Path Computation Element Communication Protocol (PCEP)", 714 RFC 8253, DOI 10.17487/RFC8253, October 2017, 715 . 717 [I-D.negi-pce-segment-routing-ipv6] 718 Negi, M., Li, C., Sivabalan, S., and P. Kaladharan, "PCEP 719 Extensions for Segment Routing leveraging the IPv6 data 720 plane", draft-negi-pce-segment-routing-ipv6-04 (work in 721 progress), February 2019. 723 Appendix A. Contributors 725 Dhruv Dhody 726 Huawei Technologies 727 Divyashree Techno Park, Whitefield 728 Bangalore, Karnataka 560066 729 India 731 Email: dhruv.ietf@gmail.com 733 Authors' Addresses 735 Colby Barth 736 Juniper Networks, Inc. 738 Email: cbarth@juniper.net 740 Mike Koldychev 741 Cisco Systems, Inc. 742 2000 Innovation Drive 743 Kanata, Ontario K2K 3E8 744 Canada 746 Email: mkoldych@cisco.com 748 Siva Sivabalan 749 Cisco Systems, Inc. 750 2000 Innovation Drive 751 Kanata, Ontario K2K 3E8 752 Canada 754 Email: msiva@cisco.com 756 Cheng Li 757 Huawei Technologies 758 Huawei Campus, No. 156 Beiqing Rd. 759 Beijing 100095 760 China 762 Email: chengli13@huawei.com