idnits 2.17.1 draft-barth-pce-segment-routing-policy-cp-03.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 (July 02, 2019) is 1754 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-03 == Outdated reference: A later version (-10) exists of draft-ietf-pce-association-group-09 -- 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 M. Koldychev 3 Internet-Draft S. Sivabalan 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: January 3, 2020 C. Barth 6 Juniper Networks, Inc. 7 C. Li 8 Huawei Technologies 9 July 02, 2019 11 PCEP extension to support Segment Routing Policy Candidate Paths 12 draft-barth-pce-segment-routing-policy-cp-03 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 January 3, 2020. 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 Identifiers TLV . . . . . . . . . . . . . . . . 8 77 5.2. SR Policy Name TLV . . . . . . . . . . . . . . . . . . . 9 78 5.3. SR Policy Candidate Path Identifiers TLV . . . . . . . . 10 79 5.4. SR Policy Candidate Path Preference TLV . . . . . . . . . 11 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 . . 12 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 . . . . . . . . . . . . . . . . . . . . 14 87 7.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 14 88 7.3. SRPAG TLVs . . . . . . . . . . . . . . . . . . . . . . . 14 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 90 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 15 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 93 10.2. Informative References . . . . . . . . . . . . . . . . . 16 94 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 17 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 = TBD6 "Conflicting SRPAG TLV". Policy Identifiers consist of: 277 o Color of SR policy. 279 o End-point of SR policy. 281 o Optionally, the policy name. 283 Candidate Path Identifiers uniquely identify the SR candidate path 284 within the context of an SR policy. Candidate path Identifiers MUST 285 NOT change for a given LSP during its lifetime. Candidate path 286 Identifiers MUST be different for different LSPs within the same 287 SRPAG. When these rules are not satisfied, the PCE MUST send a PCErr 288 message with Error Code = 26 "Association Error", Error Type = TBD6 289 "Conflicting SRPAG TLV". Candidate path Identifiers consist of: 291 o Protocol Origin of candidate path. 293 o Originator of candidate path. 295 o Discriminator of candidate path. 297 Candidate Path Attributes MUST NOT be used to identify the candidate 298 path. Candidate path attributes carry additional information about 299 the candidate path and MAY change during the lifetime of the LSP. 300 Candidate path Attributes consist of: 302 o Preference of candidate path. 304 As described in [RFC8231], an LSP is uniquely identified in PCEP via 305 PLSP-ID. 307 A mapping between the Association Parameters (see Section 2) and 308 Policy Identifiers (the Color and End-point) needs to be maintained. 309 The mapping is left up to the implementation. An implementation MAY 310 choose Association Parameters in such a way that every possible Color 311 and End-point maps to a unique value of Association Parameters, which 312 may require the use of Extended Association ID TLV. Alternatively, 313 an implementation MAY implement a lookup table to generate 314 Association Parameters incrementally as new Color and End-point 315 values are created, which may not require the use of Extended 316 Association ID TLV. 318 As per the processing rules specified in section 5.4 of 319 [I-D.ietf-pce-association-group], if a PCEP speaker does not support 320 the SRPAG association type, it MUST return a PCErr message with 321 Error-Type 26 (Early allocation by IANA) "Association Error" and 322 Error-Value 1 "Association-type is not supported". Please note that 323 the corresponding PCEP session is not reset. 325 5. SR Policy Association Group 327 Two ASSOCIATION object types for IPv4 and IPv6 are defined in 328 [I-D.ietf-pce-association-group]. The ASSOCIATION object includes 329 "Association type" indicating the type of the association group. 330 This document adds a new Association type. 332 Association type = TBD1 "SR Policy Association Type" for SR Policy 333 Association Group (SRPAG). 335 The operator configured Association Range SHOULD NOT be set for this 336 association type and MUST be ignored. 338 SRPAG MUST carry additional TLVs to communicate Association 339 Information. This document specifies four new TLVs to carry 340 Association Information: SRPOLICY-POL-ID TLV, SRPOLICY-POL-NAME TLV, 341 SRPOLICY-CPATH-ID TLV, SRPOLICY-CPATH-PREFERENCE TLV. These four 342 TLVs encode the Policy Identifiers, Policy name, Candidate path 343 Identifiers and Candidate path Preference, respectively. When any of 344 the mandatory TLVs are missing from the SRPAG association object, the 345 PCE MUST send a PCErr message with Error Code = 26 "Association 346 Error", Error Type = TBD7 "Missing mandatory SRPAG TLV". 348 A given LSP MUST belong to at most one SRPAG, since a candidate path 349 cannot belong to multiple SR policies. If a PCEP speaker receives a 350 PCEP message with more than one SRPAG for an LSP, then the PCEP 351 speaker MUST send a PCErr message with Error-Type 26 "Association 352 Error" and Error-Value TBD8 "Multiple SRPAG for one LSP". If the 353 message is a PCRpt message, then the PCEP speaker MUST close the PCEP 354 connection. Closing the PCEP connection is necessary because 355 ignoring PCRpt messages may lead to inconsistent LSP DB state between 356 the two PCEP peers. 358 If the PCEP speaker receives the SRPAG association when the SR 359 capability (as per [I-D.ietf-pce-segment-routing] or 360 [I-D.negi-pce-segment-routing-ipv6]) was not exchanged, the PCEP 361 speaker MUST send a PCErr message with Error-Type 26 "Association 362 Error" and Error-Value TBD9 "Use of SRPAG without SR capability 363 exchange". If the Path Setup Type (PST) of the LSP in SRPAG is not 364 set to SR or SRv6, then the PCEP speaker MUST send a PCErr message 365 with Error-Type 26 "Association Error" and Error-Value TBD10 "non-SR 366 LSP in SRPAG". 368 5.1. SR Policy Identifiers TLV 370 The SRPOLICY-POL-ID TLV is a mandatory TLV for the SRPAG Association. 371 Only one SRPOLICY-POL-ID TLV can be carried and only the first 372 occurrence is processed and any others MUST be ignored. 374 0 1 2 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Type | Length | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Color | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 ~ End-point ~ 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 1: The SRPOLICY-POL-ID TLV format 386 Type: TBD2 for "SRPOLICY-POL-ID" TLV. 388 Length: 8 or 20, depending on length of End-point (IPv4 or IPv6) 390 Color: any unsigned 32-bit number. 392 End-point: can be either IPv4 or IPv6, depending on whether the 393 policy endpoint has IPv4 or IPv6 address. This value may be 394 different from the one contained in the END-POINTS object, or in the 395 LSP IDENTIFIERS TLV of the LSP object. Endpoint is meant to strictly 396 correspond to the endpoint of the SR policy, as it is defined in 397 [I-D.ietf-spring-segment-routing-policy]. 399 5.2. SR Policy Name TLV 401 The SRPOLICY-POL-NAME TLV is an optional TLV for the SRPAG 402 Association. At most one SRPOLICY-POL-NAME TLV can be carried and 403 only the first occurrence is processed and any others MUST be 404 ignored. 406 0 1 2 3 407 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 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | Type | Length | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | 412 ~ Policy Name ~ 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 Figure 2: The SRPOLICY-POL-NAME TLV format 418 Type: TBD3 for "SRPOLICY-POL-NAME" TLV. 420 Length: indicates the total length of the TLV in octets and MUST be 421 greater than 0. The TLV MUST be zero-padded so that the TLV is 422 4-octet aligned. 424 Policy Name: Policy name, as defined in 425 [I-D.ietf-spring-segment-routing-policy]. It SHOULD be a string of 426 printable ASCII characters, without a NULL terminator. 428 5.3. SR Policy Candidate Path Identifiers TLV 430 The SRPOLICY-CPATH-ID TLV is a mandatory TLV for the SRPAG 431 Association. Only one SRPOLICY-CPATH-ID TLV can be carried and only 432 the first occurrence is processed and any others MUST be ignored. 434 0 1 2 3 435 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 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 437 | Type | Length | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Proto. Origin | Reserved | 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Originator ASN | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | | 444 | Originator Address | 445 | | 446 | | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Discriminator | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Figure 3: The SRPOLICY-CPATH-ID TLV format 453 Type: TBD4 for "SRPOLICY-CPATH-ID" TLV. 455 Length: 28. 457 Protocol Origin: 8-bit value that encodes the protocol origin, as 458 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.3. 460 Reserved: MUST be set to zero on transmission and ignored on receipt. 462 Originator ASN: Represented as 4 byte number, part of the originator 463 identifier, as specified in [I-D.ietf-spring-segment-routing-policy] 464 Section 2.4. 466 Originator Address: Represented as 128 bit value where IPv4 address 467 are encoded in lowest 32 bits, part of the originator identifier, as 468 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.4. 470 Discriminator: 32-bit value that encodes the Discriminator of the 471 candidate path. 473 5.4. SR Policy Candidate Path Preference TLV 475 The SRPOLICY-CPATH-PREFERENCE TLV is an optional TLV for the SRPAG 476 Association. Only one SRPOLICY-CPATH-PREFERENCE TLV can be carried 477 and only the first occurrence is processed and any others MUST be 478 ignored. 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Type | Length | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Preference | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 Figure 4: The SRPOLICY-CPATH-PREFERENCE TLV format 490 Type: TBD5 for "SRPOLICY-CPATH-PREFERENCE" TLV. 492 Length: 4. 494 Preference: Numerical preference of the candidate path, as specified 495 in [I-D.ietf-spring-segment-routing-policy] Section 2.7. 497 If the TLV is missing, a default preference of 100 as specified in 498 [I-D.ietf-spring-segment-routing-policy] is used. 500 6. Examples 502 6.1. PCC Initiated SR Policy with single candidate-path 504 PCReq and PCRep messages are exchanged in the following sequence: 506 1. PCC sends PCReq message to the PCE, encoding the SRPAG 507 ASSOCIATION object and TLVs in the PCReq message. 509 2. PCE returns the path in PCRep message, and echoes back the SRPAG 510 object that was used in the computation. 512 PCRpt and PCUpd messages are exchanged in the following sequence: 514 1. PCC sends PCRpt message to the PCE, including the LSP object and 515 the SRPAG ASSOCIATION object. 517 2. PCE computes path, possibly making use of the Association 518 Information from the SRPAG ASSOCIATION object. 520 3. PCE updates the SR policy candidate path's ERO using PCUpd 521 message. 523 6.2. PCC Initiated SR Policy with multiple candidate-paths 525 PCReq and PCRep messages are exchanged using the sequence specified 526 in section 6.1 with individual query for each candidate-path. 528 PCRpt and PCUpd messages are exchanged in the following sequence: 530 1. Step 1: For each candidate path of the SR policy, the PCC 531 generates a different PLSP-ID and symbolic-name and sends 532 multiple PCRpt messages (or one message with multiple LSP 533 objects) to the PCE. Each LSP object is followed by SRPAG 534 ASSOCIATION object with identical Color and Endpoint values. 536 2. Step 2: PCE takes into account that all the LSPs belong to the 537 same SR policy. PCE prioritizes computation for the highest 538 preference LSP and sends PCUpd message(s) back to the PCC. 540 3. Step 3: If a new candidate path is added on the PCC by the 541 operator, then a new PLSP-ID and symbolic name is generated for 542 that candidate path and a new PCRpt is sent to the PCE. 544 4. Step 4: If an existing candidate path is removed from the PCC by 545 the operator, then that PLSP-ID is deleted from the PCE by 546 sending PCRpt with the R-flag in the LSP object set. 548 6.3. PCE Initiated SR Policy with single candidate-path 550 A candidate-path is created using the following steps: 552 1. PCE sends PCInitiate message, as usual containing the SRPAG 553 Association object. PCE needs to generate a symbolic-name for 554 this LSP that will not clash with other symbolic names on the 555 same PCC. 557 2. PCC uses the color, endpoint and preference from the SRPAG object 558 to create a new candidate path. If no SR policy exists to hold 559 the candidate path, then a new SR policy is created to hold the 560 new candidate-path. The Originator of the candidate path is set 561 to be the address of the PCE that is sending the PCInitiate 562 message. 564 3. PCC allocates a locally unique PLSP-ID for the newly created 565 candidate path. This PLSP-ID is sent to the PCE in the PCRpt 566 message. 568 A candidate-path is deleted using the following steps: 570 1. PCE sends PCInitiate message, setting the R-flag in the LSP 571 object. 573 2. PCC uses the PLSP-ID from the LSP object to find the candidate 574 path and delete it. If this is the last candidate path under the 575 SR policy, then the containing SR policy is deleted as well. 577 6.4. PCE Initiated SR Policy with multiple candidate-paths 579 A candidate-path is created using the following steps: 581 1. PCE sends a separate PCInitiate message for every candidate path 582 that it wants to create, or it sends multiple LSP objects within 583 a single PCInitiate message. Each candidate-path must get a 584 unique symbolic-name generated on the PCE. SRPAG object is sent 585 for every LSP in the PCInitiate message. 587 2. PCC creates multiple candidate paths under the same SR policy, 588 identified by Color and Endpoint. PCC generates a unique PLSP-ID 589 for every candidate path. 591 3. PCC allocates a locally unique PLSP-ID for each newly created 592 candidate path. This PLSP-ID is sent to the PCE in the PCRpt 593 message. 595 A candidate path is deleted using the following steps: 597 1. PCE sends PCInitiate message, setting the R-flag in the LSP 598 object. 600 2. PCC uses the PLSP-ID from the LSP object to find the candidate 601 path and delete it. 603 7. IANA Considerations 604 7.1. Association Type 606 This document defines a new association type: SR Policy Association 607 Group (SRPAG). IANA is requested to make the assignment of a new 608 value for the sub-registry "ASSOCIATION Type Field" (request to be 609 created in [I-D.ietf-pce-association-group]), as follows: 611 +----------------------+-------------------------+------------------+ 612 | Association Type | Association Name | Reference | 613 | Value | | | 614 +----------------------+-------------------------+------------------+ 615 | TBD1 | SR Policy Association | This document | 616 +----------------------+-------------------------+------------------+ 618 7.2. PCEP Errors 620 This document defines three new Error-Values within the "Association 621 Error" Error-Type. IANA is requested to allocate new error values 622 within the "PCEP-ERROR Object Error Types and Values" sub-registry of 623 the PCEP Numbers registry, as follows: 625 +-------+----------+-----------------------------+------------------+ 626 | Error | Error | Meaning | Reference | 627 | Type | Value | | | 628 +-------+----------+-----------------------------+------------------+ 629 | 29 | TBD6 | Conflicting SRPAG TLV | This document | 630 +-------+----------+-----------------------------+------------------+ 631 | 29 | TBD7 | Missing mandatory SRPAG TLV | This document | 632 +-------+----------+-----------------------------+------------------+ 633 | 29 | TBD8 | Multiple SRPAG for one LSP | This document | 634 +-------+----------+-----------------------------+------------------+ 635 | 29 | TBD9 | Use of SRPAG without SR | This document | 636 | | | capability exchange | | 637 +-------+----------+-----------------------------+------------------+ 638 | 29 | TBD10 | non-SR LSP in SRPAG | This document | 639 +-------+----------+-----------------------------+------------------+ 641 7.3. SRPAG TLVs 643 This document defines three new TLVs for carrying additional 644 information about SR policy and SR candidate paths. IANA is 645 requested to make the assignment of a new value for the existing 646 "PCEP TLV Type Indicators" registry as follows: 648 +------------+-----------------------------------+------------------+ 649 | TLV Type | TLV Name | Reference | 650 | Value | | | 651 +------------+-----------------------------------+------------------+ 652 | TBD2 | SRPOLICY-POL-ID | This document | 653 +------------+-----------------------------------+------------------+ 654 | TBD3 | SRPOLICY-POL-NAME | This document | 655 +------------+-----------------------------------+------------------+ 656 | TBD4 | SRPOLICY-CPATH-ID | This document | 657 +------------+-----------------------------------+------------------+ 658 | TBD5 | SRPOLICY-CPATH-PREFERENCE | This document | 659 +------------+-----------------------------------+------------------+ 661 8. Security Considerations 663 This document defines one new type for association, which do not add 664 any new security concerns beyond those discussed in [RFC5440], 665 [RFC8231], [I-D.ietf-pce-segment-routing], 666 [I-D.negi-pce-segment-routing-ipv6] and 667 [I-D.ietf-pce-association-group] in itself. 669 The information carried in the SRPAG Association object, as per this 670 document is related to SR Policy. It often reflects information that 671 can also be derived from the SR Database, but association provides a 672 much easier grouping of related LSPs and messages. The SRPAG 673 association could provides an adversary with the opportunity to 674 eavesdrop on the relationship between the LSPs. Thus securing the 675 PCEP session using Transport Layer Security (TLS) [RFC8253], as per 676 the recommendations and best current practices in [RFC7525], is 677 RECOMMENDED. 679 9. Acknowledgement 681 10. References 683 10.1. Normative References 685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 686 Requirement Levels", BCP 14, RFC 2119, 687 DOI 10.17487/RFC2119, March 1997, 688 . 690 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 691 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 692 DOI 10.17487/RFC5440, March 2009, 693 . 695 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 696 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 697 May 2017, . 699 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 700 Computation Element Communication Protocol (PCEP) 701 Extensions for Stateful PCE", RFC 8231, 702 DOI 10.17487/RFC8231, September 2017, 703 . 705 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 706 Computation Element Communication Protocol (PCEP) 707 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 708 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 709 . 711 [I-D.ietf-spring-segment-routing-policy] 712 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 713 bogdanov@google.com, b., and P. Mattes, "Segment Routing 714 Policy Architecture", draft-ietf-spring-segment-routing- 715 policy-03 (work in progress), May 2019. 717 [I-D.ietf-pce-association-group] 718 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 719 Dhody, D., and Y. Tanaka, "PCEP Extensions for 720 Establishing Relationships Between Sets of LSPs", draft- 721 ietf-pce-association-group-09 (work in progress), April 722 2019. 724 [I-D.ietf-pce-segment-routing] 725 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 726 and J. Hardwick, "PCEP Extensions for Segment Routing", 727 draft-ietf-pce-segment-routing-16 (work in progress), 728 March 2019. 730 10.2. Informative References 732 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 733 Element (PCE)-Based Architecture", RFC 4655, 734 DOI 10.17487/RFC4655, August 2006, 735 . 737 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 738 "Recommendations for Secure Use of Transport Layer 739 Security (TLS) and Datagram Transport Layer Security 740 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 741 2015, . 743 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 744 "PCEPS: Usage of TLS to Provide a Secure Transport for the 745 Path Computation Element Communication Protocol (PCEP)", 746 RFC 8253, DOI 10.17487/RFC8253, October 2017, 747 . 749 [I-D.negi-pce-segment-routing-ipv6] 750 Negi, M., Li, C., Sivabalan, S., and P. Kaladharan, "PCEP 751 Extensions for Segment Routing leveraging the IPv6 data 752 plane", draft-negi-pce-segment-routing-ipv6-04 (work in 753 progress), February 2019. 755 Appendix A. Contributors 757 Dhruv Dhody 758 Huawei Technologies 759 Divyashree Techno Park, Whitefield 760 Bangalore, Karnataka 560066 761 India 763 Email: dhruv.ietf@gmail.com 765 Authors' Addresses 767 Mike Koldychev 768 Cisco Systems, Inc. 769 2000 Innovation Drive 770 Kanata, Ontario K2K 3E8 771 Canada 773 Email: mkoldych@cisco.com 775 Siva Sivabalan 776 Cisco Systems, Inc. 777 2000 Innovation Drive 778 Kanata, Ontario K2K 3E8 779 Canada 781 Email: msiva@cisco.com 783 Colby Barth 784 Juniper Networks, Inc. 786 Email: cbarth@juniper.net 787 Cheng Li 788 Huawei Technologies 789 Huawei Campus, No. 156 Beiqing Rd. 790 Beijing 100095 791 China 793 Email: chengli13@huawei.com