idnits 2.17.1 draft-barth-pce-segment-routing-policy-cp-05.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 (May 04, 2020) is 1424 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-06 == Outdated reference: A later version (-07) exists of draft-koldychev-pce-operational-01 -- 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: November 5, 2020 C. Barth 6 Juniper Networks, Inc. 7 C. Li 8 Huawei Technologies 9 H. Bidgoli 10 Nokia 11 May 04, 2020 13 PCEP extension to support Segment Routing Policy Candidate Paths 14 draft-barth-pce-segment-routing-policy-cp-05 16 Abstract 18 This document introduces a mechanism to specify a Segment Routing 19 (SR) policy, as a collection of SR candidate paths. An SR policy is 20 identified by tuple. An SR policy can 21 contain one or more candidate paths where each candidate path is 22 identified in PCEP via an PLSP-ID. This document proposes extension 23 to PCEP to support association among candidate paths of a given SR 24 policy. The mechanism proposed in this document is applicable to 25 both MPLS and IPv6 data planes of SR. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 31 "OPTIONAL" in this document are to be interpreted as described in BCP 32 14 [RFC2119] [RFC8174] when, and only when, they appear in all 33 capitals, as shown here. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at https://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on November 5, 2020. 51 Copyright Notice 53 Copyright (c) 2020 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (https://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Group Candidate Paths belonging to the same SR policy . . 5 72 3.2. Instantiation of SR policy candidate paths . . . . . . . 5 73 3.3. Avoid computing lower preference candidate paths . . . . 5 74 3.4. Minimal signaling overhead . . . . . . . . . . . . . . . 5 75 4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 77 4.2. Choice of Association Parameters . . . . . . . . . . . . 7 78 4.3. Multiple Optimization Objectives and Constraints . . . . 8 79 5. SR Policy Association Group . . . . . . . . . . . . . . . . . 8 80 5.1. SR Policy Identifiers TLV . . . . . . . . . . . . . . . . 9 81 5.2. SR Policy Name TLV . . . . . . . . . . . . . . . . . . . 10 82 5.3. SR Policy Candidate Path Identifiers TLV . . . . . . . . 10 83 5.4. SR Policy Candidate Path Preference TLV . . . . . . . . . 11 84 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 6.1. PCC Initiated SR Policy with single candidate-path . . . 12 86 6.2. PCC Initiated SR Policy with multiple candidate-paths . . 12 87 6.3. PCE Initiated SR Policy with single candidate-path . . . 13 88 6.4. PCE Initiated SR Policy with multiple candidate-paths . . 14 89 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 90 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 14 91 7.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 15 92 7.3. SRPAG TLVs . . . . . . . . . . . . . . . . . . . . . . . 15 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 94 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 97 10.2. Informative References . . . . . . . . . . . . . . . . . 17 98 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 18 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 101 1. Introduction 103 Path Computation Element (PCE) Communication Protocol (PCEP) 104 [RFC5440] enables the communication between a Path Computation Client 105 (PCC) and a Path Control Element (PCE), or between two PCEs based on 106 the PCE architecture [RFC4655]. 108 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 109 of extensions to PCEP to enable active control of Multiprotocol Label 110 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 111 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 112 LSPs under the active stateful PCE model, without the need for local 113 configuration on the PCC, thus allowing for dynamic centralized 114 control of a network. 116 PCEP Extensions for Segment Routing [I-D.ietf-pce-segment-routing] 117 specifies extensions to the Path Computation Element Protocol (PCEP) 118 that allow a stateful PCE to compute and initiate Traffic Engineering 119 (TE) paths, as well as a PCC to request a path subject to certain 120 constraint(s) and optimization criteria in SR networks. 122 PCEP Extensions for Establishing Relationships Between Sets of LSPs 123 [I-D.ietf-pce-association-group] introduces a generic mechanism to 124 create a grouping of LSPs which can then be used to define 125 associations between a set of LSPs and a set of attributes (such as 126 configuration parameters or behaviors) and is equally applicable to 127 stateful PCE (active and passive modes) and stateless PCE. 129 Segment Routing Policy for Traffic Engineering 130 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 131 Policy and approaches to steering traffic into an SR Policy. 133 An SR policy contains one or more candidate paths where one or more 134 such paths can be computed via PCE. This document specifies PCEP 135 extensions to signal additional information to map candidate paths to 136 their SR policies. Each candidate path maps to a unique PLSP-ID in 137 PCEP. By associating multiple candidate paths together, a PCE 138 becomes aware of the hierarchical structure of an SR policy. Thus 139 the PCE can take computation and control decisions about the 140 candidate paths, with the additional knowledge that these candidate 141 paths belong to the same SR policy. This is accomplished via the use 142 of the existing PCEP Association object, by defining a new 143 association type specifically for associating SR candidate paths into 144 a single SR policy. 146 [Editor's Note- Currently it is assumed that each candidate path has 147 only one ERO (SID-List) within the scope of this document. A future 148 update or another document will deal with a way to allow multiple 149 ERO/SID-Lists for a candidate path within PCEP.] 151 2. Terminology 153 The following terminologies are used in this document: 155 Endpoint: The IPv4 or IPv6 endpoint address of the SR policy in 156 question, as described in 157 [I-D.ietf-spring-segment-routing-policy]. 159 Association parameters: As described in 160 [I-D.ietf-pce-association-group], the combination of the mandatory 161 fields Association type, Association ID and Association Source in 162 the ASSOCIATION object uniquely identify the association group. 163 If the optional TLVs - Global Association Source or Extended 164 Association ID are included, then they MUST be included in 165 combination with mandatory fields to uniquely identify the 166 association group. 168 Association information: As described in 169 [I-D.ietf-pce-association-group], the ASSOCIATION object could 170 also include other optional TLVs based on the association types, 171 that provides 'information' related to the association type. 173 PCC: Path Computation Client. Any client application requesting a 174 path computation to be performed by a Path Computation Element. 176 PCE: Path Computation Element. An entity (component, application, 177 or network node) that is capable of computing a network path or 178 route based on a network graph and applying computational 179 constraints. 181 PCEP: Path Computation Element Protocol. 183 PCEP Tunnel: The entity identified by the PLSP-ID, as per 184 [I-D.koldychev-pce-operational]. 186 3. Motivation 188 The new Association Type (SR Policy Association) and the new TLVs for 189 the ASSOCIATION object, defined in this document, allow a PCEP peer 190 to exchange additional parameters of SR candidate paths and of their 191 parent SR policy. For the SR policy, the parameters are: color and 192 endpoint. For the candidate path, the parameters are: protocol 193 origin, originator, discriminator and preference. 195 [I-D.ietf-spring-segment-routing-policy] describes the concept of SR 196 Policy and these parameters. 198 The motivation for signaling these parameters is summarized in the 199 following subsections. 201 3.1. Group Candidate Paths belonging to the same SR policy 203 Since each candidate path of an SR policy appears as a different LSP 204 (identified via a PLSP-ID) in PCEP, it is useful to group together 205 all the candidate paths that belong to the same SR policy. 206 Furthermore, it is useful for the PCE to have knowledge of the SR 207 candidate path parameters such as color, protocol origin, 208 discriminator, and preference. 210 3.2. Instantiation of SR policy candidate paths 212 A PCE may want to instantiate one or more candidate paths on the PCC, 213 as specified in [RFC8281]. In this scenario, the PCE needs to signal 214 to a PCC tuple using which the PCC can instantiate a candidate 216 path for the SR policy identified. Current PCEP standards (as of the 217 time of this writing) do not provide a way to signal color and 218 preference. Although end-point can be signaled via the PCEP END- 219 POINTS object, this object may not be suitable because the end-point 220 to which the path is computed is not required to be the same IPv4/ 221 IPv6 address as the actual endpoint of the SR policy. Thus, a 222 separate way to specify SR policy's end-point is provided in this 223 document. 225 3.3. Avoid computing lower preference candidate paths 227 When a PCE knows that a given set of candidate paths all belong to 228 the same SR policy, then path computation MAY be done on only the 229 highest preference candidate-path(s). Path computation for lower 230 preference paths is not necessary if one or two higher preference 231 paths are already computed. Since computing their paths will not 232 affect traffic steering, it MAY be postponed until the higher 233 preference paths become invalid, thus saving computation resources on 234 the PCE. 236 3.4. Minimal signaling overhead 238 When an SR policy contains multiple candidate paths computed by a 239 PCE, such candidate paths can be created, updated and deleted 240 independently of each other. This is achieved by making each 241 candidate path correspond to a unique LSP (identified via PLSP-ID). 242 For example, if an SR policy has 4 candidate paths, then if the PCE 243 wants to update one of those candidate paths, only one set of PCUpd 244 and PCRpt messages needs to be exchanged. 246 4. Procedure 248 4.1. Overview 250 As per [I-D.ietf-pce-association-group], LSPs are placed into an 251 association group. As per [I-D.koldychev-pce-operational], LSPs are 252 contained in PCEP Tunnels and a PCEP Tunnel is contained in an 253 Association if all of its LSPs are in that Association. 255 PCEP Tunnels naturally map to SR Candidate Paths and PCEP 256 Associations naturally map to SR Policies. Definition of these 257 mappings is the central purpose of this document. 259 The mapping between PCEP Associations and SR Policies is always one- 260 to-one. However, the mapping between PCEP Tunnels and SR Candidate 261 Paths may be either one-to-one, or many-to-one. The mapping is one- 262 to-one when the SR Candidate Path has only a single constraint and 263 optimization objective. The mapping is many-to-one when the SR 264 Candidate Path has multiple constraints and optimization objectives. 265 For more details on multiple optimization objectives and constraints, 266 see Section 4.3. 268 [Editor's Note - Segment-lists within a candidate path are not 269 represented by different PCEP Tunnels. The subject of encoding 270 multiple segment lists within a candidate path is left to a future 271 document and is not specified in this document. It is not a good 272 idea to have each segment-list correspond to a different Tunnel, 273 because when the PCC wants to get a path, it must know in advance how 274 many multipaths (i.e., segment-lists) there will be and create that 275 many Tunnels. For example, if the PCC supports 32 multipaths, then 276 it must delegate 32 Tunnels for every candidate path, which may not 277 be scalable.] 279 A new Association Type is defined in this document, based on the 280 generic ASSOCIATION object. Association type = TBD1 "SR Policy 281 Association Type" for SR Policy Association Group (SRPAG). The SRPAG 282 Association is only meant to be used for SR LSPs and with PCEP peers 283 which advertise SR capability. 285 An Association object of SRPAG group contains TLVs that carry 286 Association Information. The association information can be 287 subdivided into three parts: Policy identifiers, Candidate path 288 identifiers, and Candidate path attributes. 290 Policy Identifiers uniquely identify the SR policy to which a given 291 LSP belongs, within the context of the head-end. Policy Identifiers 292 MUST be the same for all candidate paths in the same SRPAG. Policy 293 Identifiers MUST NOT change for a given LSP during its lifetime. 294 Policy Identifiers MUST be different for different SRPAG 295 associations. When these rules are not satisfied, the PCE MUST send 296 a PCErr message with Error Code = 26 "Association Error", Error Type 297 = TBD6 "Conflicting SRPAG TLV". Policy Identifiers consist of: 299 o Color of SR policy. 301 o End-point of SR policy. 303 o Optionally, the policy name. 305 Candidate Path Identifiers uniquely identify the SR candidate path 306 within the context of an SR policy. Candidate path Identifiers MUST 307 NOT change for a given LSP during its lifetime. Candidate path 308 Identifiers MUST be different for different LSPs within the same 309 SRPAG. When these rules are not satisfied, the PCE MUST send a PCErr 310 message with Error Code = 26 "Association Error", Error Type = TBD6 311 "Conflicting SRPAG TLV". Candidate path Identifiers consist of: 313 o Protocol Origin of candidate path. 315 o Originator of candidate path. 317 o Discriminator of candidate path. 319 Candidate Path Attributes MUST NOT be used to identify the candidate 320 path. Candidate path attributes carry additional information about 321 the candidate path and MAY change during the lifetime of the LSP. 322 Candidate path Attributes consist of: 324 o Preference of candidate path. 326 As per the processing rules specified in section 5.4 of 327 [I-D.ietf-pce-association-group], if a PCEP speaker does not support 328 the SRPAG association type, it MUST return a PCErr message with 329 Error-Type 26 (Early allocation by IANA) "Association Error" and 330 Error-Value 1 "Association-type is not supported". Please note that 331 the corresponding PCEP session is not reset. 333 4.2. Choice of Association Parameters 335 The Association Parameters (see Section 2) uniquely identify the 336 Association. In this section, we describe how these are to be set. 338 The Association Source MUST be set to the PCC's address. This 339 applies for both PCC-initiated and PCE-initiated candidate paths. 340 The reasoning for this is that if different PCEs could set their own 341 Association Source, then the candidate paths instantiated by 342 different PCEs would by definition be in different PCEP Associations, 343 which contradicts our requirement that the SR Policy is represented 344 by an Association. 346 The Association ID MUST be chosen by the PCC when the SR policy is 347 allocated. In PCRpt messages from the PCC, the Association ID MUST 348 be set to the unique value that was allocated by the PCC at the time 349 of policy creation. In PCInit messages from the PCE, the Association 350 ID MUST be set to the reserved value 0xFFFF, which indicates that the 351 PCE is asking the PCC to choose an ID value. The PCE MUST NOT send 352 the Extended Association ID TLV in the PCInit messages. 354 If the PCC receives a PCInit message with Association Source not 355 equal to the PCCs address, or with Association ID not equal to 356 0xFFFF, or with Extended Association ID TLV present, the PCC SHOULD 357 ignore the given ASSOCIATION object. 359 4.3. Multiple Optimization Objectives and Constraints 361 In certain scenarios, it is desired for each SR Candidate Path to 362 contain multiple sub-candidate paths, each of which has a different 363 optimization objective and constraints. Traffic is then sent ECMP or 364 UCMP among these sub-candidate paths. 366 This is represented in PCEP by a many-to-one mapping between PCEP 367 Tunnels and SR Candidate Paths. This means that multiple PCEP 368 Tunnels are allocated for each SR Candidate Path. Each PCEP Tunnel 369 has its own optimization objective and constraints. When a single SR 370 Candidate Path contains multiple PCEP Tunnels, each of these PCEP 371 Tunnels MUST have identical values of Candidate Path Identifiers, as 372 encoded in SRPOLICY-CPATH-ID TLV, see Section 5.3. 374 5. SR Policy Association Group 376 Two ASSOCIATION object types for IPv4 and IPv6 are defined in 377 [I-D.ietf-pce-association-group]. The ASSOCIATION object includes 378 "Association type" indicating the type of the association group. 379 This document adds a new Association type. 381 Association type = TBD1 "SR Policy Association Type" for SR Policy 382 Association Group (SRPAG). 384 The operator configured Association Range SHOULD NOT be set for this 385 association type and MUST be ignored. 387 SRPAG MUST carry additional TLVs to communicate Association 388 Information. This document specifies four new TLVs to carry 389 Association Information: SRPOLICY-POL-ID TLV, SRPOLICY-POL-NAME TLV, 390 SRPOLICY-CPATH-ID TLV, SRPOLICY-CPATH-PREFERENCE TLV. These four 391 TLVs encode the Policy Identifiers, Policy name, Candidate path 392 Identifiers and Candidate path Preference, respectively. When any of 393 the mandatory TLVs are missing from the SRPAG association object, the 394 PCE MUST send a PCErr message with Error Code = 26 "Association 395 Error", Error Type = TBD7 "Missing mandatory SRPAG TLV". 397 A given LSP MUST belong to at most one SRPAG, since a candidate path 398 cannot belong to multiple SR policies. If a PCEP speaker receives a 399 PCEP message with more than one SRPAG for an LSP, then the PCEP 400 speaker MUST send a PCErr message with Error-Type 26 "Association 401 Error" and Error-Value TBD8 "Multiple SRPAG for one LSP". If the 402 message is a PCRpt message, then the PCEP speaker MUST close the PCEP 403 connection. Closing the PCEP connection is necessary because 404 ignoring PCRpt messages may lead to inconsistent LSP DB state between 405 the two PCEP peers. 407 If the PCEP speaker receives the SRPAG association when the SR 408 capability (as per [I-D.ietf-pce-segment-routing] or 409 [I-D.negi-pce-segment-routing-ipv6]) was not exchanged, the PCEP 410 speaker MUST send a PCErr message with Error-Type 26 "Association 411 Error" and Error-Value TBD9 "Use of SRPAG without SR capability 412 exchange". If the Path Setup Type (PST) of the LSP in SRPAG is not 413 set to SR or SRv6, then the PCEP speaker MUST send a PCErr message 414 with Error-Type 26 "Association Error" and Error-Value TBD10 "non-SR 415 LSP in SRPAG". 417 5.1. SR Policy Identifiers TLV 419 The SRPOLICY-POL-ID TLV is a mandatory TLV for the SRPAG Association. 420 Only one SRPOLICY-POL-ID TLV can be carried and only the first 421 occurrence is processed and any others MUST be ignored. 423 0 1 2 3 424 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 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Type | Length | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 | Color | 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 ~ End-point ~ 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 Figure 1: The SRPOLICY-POL-ID TLV format 435 Type: TBD2 for "SRPOLICY-POL-ID" TLV. 437 Length: 8 or 20, depending on length of End-point (IPv4 or IPv6) 439 Color: any unsigned 32-bit number. 441 End-point: can be either IPv4 or IPv6, depending on whether the 442 policy endpoint has IPv4 or IPv6 address. This value may be 443 different from the one contained in the END-POINTS object, or in the 444 LSP IDENTIFIERS TLV of the LSP object. Endpoint is meant to strictly 445 correspond to the endpoint of the SR policy, as it is defined in 446 [I-D.ietf-spring-segment-routing-policy]. 448 5.2. SR Policy Name TLV 450 The SRPOLICY-POL-NAME TLV is an optional TLV for the SRPAG 451 Association. At most one SRPOLICY-POL-NAME TLV can be carried and 452 only the first occurrence is processed and any others MUST be 453 ignored. 455 0 1 2 3 456 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 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 | Type | Length | 459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 460 | | 461 ~ Policy Name ~ 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 Figure 2: The SRPOLICY-POL-NAME TLV format 467 Type: TBD3 for "SRPOLICY-POL-NAME" TLV. 469 Length: indicates the total length of the TLV in octets and MUST be 470 greater than 0. The TLV MUST be zero-padded so that the TLV is 471 4-octet aligned. 473 Policy Name: Policy name, as defined in 474 [I-D.ietf-spring-segment-routing-policy]. It SHOULD be a string of 475 printable ASCII characters, without a NULL terminator. 477 5.3. SR Policy Candidate Path Identifiers TLV 479 The SRPOLICY-CPATH-ID TLV is a mandatory TLV for the SRPAG 480 Association. Only one SRPOLICY-CPATH-ID TLV can be carried and only 481 the first occurrence is processed and any others MUST 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 | Reserved | 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: TBD4 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. 509 Reserved: MUST be set to zero on transmission and ignored on receipt. 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.4. SR Policy Candidate Path Preference TLV 524 The SRPOLICY-CPATH-PREFERENCE TLV is an optional TLV for the SRPAG 525 Association. Only one SRPOLICY-CPATH-PREFERENCE TLV can be carried 526 and only the first occurrence is processed and any others MUST be 527 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 | Preference | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 Figure 4: The SRPOLICY-CPATH-PREFERENCE TLV format 539 Type: TBD5 for "SRPOLICY-CPATH-PREFERENCE" TLV. 541 Length: 4. 543 Preference: Numerical preference of the candidate path, as specified 544 in [I-D.ietf-spring-segment-routing-policy] Section 2.7. 546 If the TLV is missing, a default preference of 100 as specified in 547 [I-D.ietf-spring-segment-routing-policy] is used. 549 6. Examples 551 6.1. PCC Initiated SR Policy with single candidate-path 553 PCReq and PCRep messages are exchanged in the following sequence: 555 1. PCC sends PCReq message to the PCE, encoding the SRPAG 556 ASSOCIATION object and TLVs in the PCReq message. 558 2. PCE returns the path in PCRep message, and echoes back the SRPAG 559 object that was used in the computation. 561 PCRpt and PCUpd messages are exchanged in the following sequence: 563 1. PCC sends PCRpt message to the PCE, including the LSP object and 564 the SRPAG ASSOCIATION object. 566 2. PCE computes path, possibly making use of the Association 567 Information from the SRPAG ASSOCIATION object. 569 3. PCE updates the SR policy candidate path's ERO using PCUpd 570 message. 572 6.2. PCC Initiated SR Policy with multiple candidate-paths 574 PCRpt and PCUpd messages are exchanged in the following sequence: 576 1. For each candidate path of the SR Policy, the PCC generates a 577 different PLSP-ID and symbolic-name and sends multiple PCRpt 578 messages (or one message with multiple LSP objects) to the PCE. 579 Each LSP object is followed by SRPAG ASSOCIATION object with 580 identical Color and Endpoint values. The Association Source is 581 set to the IP address of the PCC and the Association ID is set to 582 a number that PCC locally chose to represent the SR Policy. 584 2. PCE takes into account that all the LSPs belong to the same SR 585 policy. PCE prioritizes computation for the highest preference 586 LSP and sends PCUpd message(s) back to the PCC. 588 3. If a new candidate path is added on the PCC by the operator, then 589 a new PLSP-ID and symbolic name is generated for that candidate 590 path and a new PCRpt is sent to the PCE. 592 4. If an existing candidate path is removed from the PCC by the 593 operator, then that PLSP-ID is deleted from the PCE by sending 594 PCRpt with the R-flag in the LSP object set. 596 6.3. PCE Initiated SR Policy with single candidate-path 598 A candidate-path is created using the following steps: 600 1. PCE sends PCInitiate message, containing the SRPAG Association 601 object. The Association Source is set to the IP address of the 602 PCC and the Association ID is set to 0xFFFF, as described in 603 Section 4.2. 605 2. PCC uses the color, endpoint and preference from the SRPAG object 606 to create a new candidate path. If no SR policy exists to hold 607 the candidate path, then a new SR policy is created to hold the 608 new candidate-path. The Originator of the candidate path is set 609 to be the address of the PCE that is sending the PCInitiate 610 message. 612 3. PCC sends a PCRpt message back to the PCE to report the newly 613 created Candidate Path. The PCRpt message contains the SRPAG 614 Association object. The Association Source is set to the IP 615 address of the PCC and the Association ID is set to a number that 616 PCC locally chose to represent the SR Policy. 618 A candidate-path is deleted using the following steps: 620 1. PCE sends PCInitiate message, setting the R-flag in the LSP 621 object. 623 2. PCC uses the PLSP-ID from the LSP object to find the candidate 624 path and delete it. If this is the last candidate path under the 625 SR policy, then the containing SR policy is deleted as well. 627 6.4. PCE Initiated SR Policy with multiple candidate-paths 629 A candidate-path is created using the following steps: 631 1. PCE sends a separate PCInitiate message for every candidate path 632 that it wants to create, or it sends multiple LSP objects within 633 a single PCInitiate message. The SRPAG Association object is 634 sent for every LSP in the PCInitiate message. The Association 635 Source is set to the IP address of the PCC and the Association ID 636 is set to 0xFFFF, as described in Section 4.2. 638 2. PCC creates multiple candidate paths under the same SR policy, 639 identified by Color and Endpoint. 641 3. PCC sends a PCRpt message back to the PCE to report the newly 642 created Candidate Path. The PCRpt message contains the SRPAG 643 Association object. The Association Source is set to the IP 644 address of the PCC and the Association ID is set to a number that 645 PCC locally chose to represent the SR Policy. 647 A candidate path is deleted using the following steps: 649 1. PCE sends PCInitiate message, setting the R-flag in the LSP 650 object. 652 2. PCC uses the PLSP-ID from the LSP object to find the candidate 653 path and delete it. 655 7. IANA Considerations 657 7.1. Association Type 659 This document defines a new association type: SR Policy Association 660 Group (SRPAG). IANA is requested to make the assignment of a new 661 value for the sub-registry "ASSOCIATION Type Field" (request to be 662 created in [I-D.ietf-pce-association-group]), as follows: 664 +----------------------+-------------------------+------------------+ 665 | Association Type | Association Name | Reference | 666 | Value | | | 667 +----------------------+-------------------------+------------------+ 668 | TBD1 | SR Policy Association | This document | 669 +----------------------+-------------------------+------------------+ 671 7.2. PCEP Errors 673 This document defines three new Error-Values within the "Association 674 Error" Error-Type. IANA is requested to allocate new error values 675 within the "PCEP-ERROR Object Error Types and Values" sub-registry of 676 the PCEP Numbers registry, as follows: 678 +-------+----------+-----------------------------+------------------+ 679 | Error | Error | Meaning | Reference | 680 | Type | Value | | | 681 +-------+----------+-----------------------------+------------------+ 682 | 29 | TBD6 | Conflicting SRPAG TLV | This document | 683 +-------+----------+-----------------------------+------------------+ 684 | 29 | TBD7 | Missing mandatory SRPAG TLV | This document | 685 +-------+----------+-----------------------------+------------------+ 686 | 29 | TBD8 | Multiple SRPAG for one LSP | This document | 687 +-------+----------+-----------------------------+------------------+ 688 | 29 | TBD9 | Use of SRPAG without SR | This document | 689 | | | capability exchange | | 690 +-------+----------+-----------------------------+------------------+ 691 | 29 | TBD10 | non-SR LSP in SRPAG | This document | 692 +-------+----------+-----------------------------+------------------+ 694 7.3. SRPAG TLVs 696 This document defines three new TLVs for carrying additional 697 information about SR policy and SR candidate paths. IANA is 698 requested to make the assignment of a new value for the existing 699 "PCEP TLV Type Indicators" registry as follows: 701 +------------+-----------------------------------+------------------+ 702 | TLV Type | TLV Name | Reference | 703 | Value | | | 704 +------------+-----------------------------------+------------------+ 705 | TBD2 | SRPOLICY-POL-ID | This document | 706 +------------+-----------------------------------+------------------+ 707 | TBD3 | SRPOLICY-POL-NAME | This document | 708 +------------+-----------------------------------+------------------+ 709 | TBD4 | SRPOLICY-CPATH-ID | This document | 710 +------------+-----------------------------------+------------------+ 711 | TBD5 | SRPOLICY-CPATH-PREFERENCE | This document | 712 +------------+-----------------------------------+------------------+ 714 8. Security Considerations 716 This document defines one new type for association, which do not add 717 any new security concerns beyond those discussed in [RFC5440], 718 [RFC8231], [I-D.ietf-pce-segment-routing], 719 [I-D.negi-pce-segment-routing-ipv6] and 720 [I-D.ietf-pce-association-group] in itself. 722 The information carried in the SRPAG Association object, as per this 723 document is related to SR Policy. It often reflects information that 724 can also be derived from the SR Database, but association provides a 725 much easier grouping of related LSPs and messages. The SRPAG 726 association could provides an adversary with the opportunity to 727 eavesdrop on the relationship between the LSPs. Thus securing the 728 PCEP session using Transport Layer Security (TLS) [RFC8253], as per 729 the recommendations and best current practices in [RFC7525], is 730 RECOMMENDED. 732 9. Acknowledgement 734 10. References 736 10.1. Normative References 738 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 739 Requirement Levels", BCP 14, RFC 2119, 740 DOI 10.17487/RFC2119, March 1997, 741 . 743 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 744 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 745 DOI 10.17487/RFC5440, March 2009, 746 . 748 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 749 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 750 May 2017, . 752 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 753 Computation Element Communication Protocol (PCEP) 754 Extensions for Stateful PCE", RFC 8231, 755 DOI 10.17487/RFC8231, September 2017, 756 . 758 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 759 Computation Element Communication Protocol (PCEP) 760 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 761 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 762 . 764 [I-D.ietf-spring-segment-routing-policy] 765 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 766 P. Mattes, "Segment Routing Policy Architecture", draft- 767 ietf-spring-segment-routing-policy-06 (work in progress), 768 December 2019. 770 [I-D.ietf-pce-association-group] 771 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 772 Dhody, D., and Y. Tanaka, "Path Computation Element 773 Communication Protocol (PCEP) Extensions for Establishing 774 Relationships Between Sets of Label Switched Paths 775 (LSPs)", draft-ietf-pce-association-group-10 (work in 776 progress), August 2019. 778 [I-D.ietf-pce-segment-routing] 779 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 780 and J. Hardwick, "PCEP Extensions for Segment Routing", 781 draft-ietf-pce-segment-routing-16 (work in progress), 782 March 2019. 784 [I-D.koldychev-pce-operational] 785 Koldychev, M., Sivabalan, S., Negi, M., Achaval, D., and 786 H. Kotni, "PCEP Operational Clarification", draft- 787 koldychev-pce-operational-01 (work in progress), February 788 2020. 790 10.2. Informative References 792 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 793 Element (PCE)-Based Architecture", RFC 4655, 794 DOI 10.17487/RFC4655, August 2006, 795 . 797 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 798 "Recommendations for Secure Use of Transport Layer 799 Security (TLS) and Datagram Transport Layer Security 800 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 801 2015, . 803 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 804 "PCEPS: Usage of TLS to Provide a Secure Transport for the 805 Path Computation Element Communication Protocol (PCEP)", 806 RFC 8253, DOI 10.17487/RFC8253, October 2017, 807 . 809 [I-D.negi-pce-segment-routing-ipv6] 810 Negi, M., Li, C., Sivabalan, S., and P. Kaladharan, "PCEP 811 Extensions for Segment Routing leveraging the IPv6 data 812 plane", draft-negi-pce-segment-routing-ipv6-04 (work in 813 progress), February 2019. 815 Appendix A. Contributors 817 Dhruv Dhody 818 Huawei Technologies 819 Divyashree Techno Park, Whitefield 820 Bangalore, Karnataka 560066 821 India 823 Email: dhruv.ietf@gmail.com 825 Authors' Addresses 827 Mike Koldychev 828 Cisco Systems, Inc. 829 2000 Innovation Drive 830 Kanata, Ontario K2K 3E8 831 Canada 833 Email: mkoldych@cisco.com 835 Siva Sivabalan 836 Cisco Systems, Inc. 837 2000 Innovation Drive 838 Kanata, Ontario K2K 3E8 839 Canada 841 Email: msiva@cisco.com 843 Colby Barth 844 Juniper Networks, Inc. 846 Email: cbarth@juniper.net 847 Cheng Li 848 Huawei Technologies 849 Huawei Campus, No. 156 Beiqing Rd. 850 Beijing 100095 851 China 853 Email: chengli13@huawei.com 855 Hooman Bidgoli 856 Nokia 858 Email: hooman.bidgoli@nokia.com