idnits 2.17.1 draft-ietf-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 (January 22, 2021) is 1188 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-09 == Outdated reference: A later version (-07) exists of draft-koldychev-pce-operational-02 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group M. Koldychev 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track S. Sivabalan 5 Expires: July 26, 2021 Ciena Corporation 6 C. Barth 7 Juniper Networks, Inc. 8 S. Peng 9 Huawei Technologies 10 H. Bidgoli 11 Nokia 12 January 22, 2021 14 PCEP extension to support Segment Routing Policy Candidate Paths 15 draft-ietf-pce-segment-routing-policy-cp-02 17 Abstract 19 This document introduces a mechanism to specify a Segment Routing 20 (SR) policy, as a collection of SR candidate paths. An SR policy is 21 identified by tuple. An SR policy can 22 contain one or more candidate paths where each candidate path is 23 identified in PCEP by its uniquely assigned PLSP-ID. This document 24 proposes extension to PCEP to support association among candidate 25 paths of a given SR policy. The mechanism proposed in this document 26 is applicable to both MPLS and IPv6 data planes of SR. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 32 "OPTIONAL" in this document are to be interpreted as described in BCP 33 14 [RFC2119] [RFC8174] when, and only when, they appear in all 34 capitals, as shown here. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at https://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on July 26, 2021. 53 Copyright Notice 55 Copyright (c) 2021 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (https://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.1. Group Candidate Paths belonging to the same SR policy . . 5 74 3.2. Instantiation of SR policy candidate paths . . . . . . . 5 75 3.3. Avoid computing lower preference candidate paths . . . . 5 76 3.4. Minimal signaling overhead . . . . . . . . . . . . . . . 6 77 4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 79 4.2. Choice of Association Parameters . . . . . . . . . . . . 8 80 4.3. Multiple Optimization Objectives and Constraints . . . . 9 81 5. SR Policy Association Group . . . . . . . . . . . . . . . . . 9 82 5.1. SR Policy Name TLV . . . . . . . . . . . . . . . . . . . 10 83 5.2. SR Policy Candidate Path Identifiers TLV . . . . . . . . 11 84 5.3. SR Policy Candidate Path Name TLV . . . . . . . . . . . . 12 85 5.4. SR Policy Candidate Path Preference TLV . . . . . . . . . 12 86 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 6.1. PCC Initiated SR Policy with single candidate-path . . . 13 88 6.2. PCC Initiated SR Policy with multiple candidate-paths . . 13 89 6.3. PCE Initiated SR Policy with single candidate-path . . . 14 90 6.4. PCE Initiated SR Policy with multiple candidate-paths . . 15 91 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 92 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 15 93 7.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 16 94 7.3. SRPAG TLVs . . . . . . . . . . . . . . . . . . . . . . . 16 95 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 96 8.1. Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 17 98 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 101 11.2. Informative References . . . . . . . . . . . . . . . . . 19 102 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 20 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 105 1. Introduction 107 Path Computation Element (PCE) Communication Protocol (PCEP) 108 [RFC5440] enables the communication between a Path Computation Client 109 (PCC) and a Path Computation Element (PCE), or between two PCEs based 110 on the PCE architecture [RFC4655]. 112 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 113 of extensions to PCEP to enable active control of Multiprotocol Label 114 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 115 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 116 LSPs under the active stateful PCE model, without the need for local 117 configuration on the PCC, thus allowing for dynamic centralized 118 control of a network. 120 PCEP Extensions for Segment Routing [RFC8664] specifies extensions to 121 the Path Computation Element Protocol (PCEP) that allow a stateful 122 PCE to compute and initiate Traffic Engineering (TE) paths, as well 123 as a PCC to request a path subject to certain constraint(s) and 124 optimization criteria in SR networks. 126 PCEP Extensions for Establishing Relationships Between Sets of LSPs 127 [RFC8697] introduces a generic mechanism to create a grouping of LSPs 128 which can then be used to define associations between a set of LSPs 129 and a set of attributes (such as configuration parameters or 130 behaviors) and is equally applicable to stateful PCE (active and 131 passive modes) and stateless PCE. 133 Segment Routing Policy for Traffic Engineering 134 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 135 Policy and approaches to steering traffic into an SR Policy. 137 An SR policy contains one or more candidate paths where one or more 138 such paths can be computed via PCE. This document specifies PCEP 139 extensions to signal additional information to map candidate paths to 140 their SR policies. Each candidate path maps to a unique PLSP-ID in 141 PCEP. By associating multiple candidate paths together, a PCE 142 becomes aware of the hierarchical structure of an SR policy. Thus 143 the PCE can take computation and control decisions about the 144 candidate paths, with the additional knowledge that these candidate 145 paths belong to the same SR policy. This is accomplished via the use 146 of the existing PCEP Association object, by defining a new 147 association type specifically for associating SR candidate paths into 148 a single SR policy. 150 [Editor's Note- Currently it is assumed that each candidate path has 151 only one ERO (SID-List) within the scope of this document. Another 152 document will deal with a way to allow multiple ERO/SID-Lists for a 153 candidate path within PCEP.] 155 2. Terminology 157 The following terminologies are used in this document: 159 Endpoint: The IPv4 or IPv6 endpoint address of the SR policy in 160 question, as described in 161 [I-D.ietf-spring-segment-routing-policy]. 163 Association parameters: As described in [RFC8697], the combination 164 of the mandatory fields Association type, Association ID and 165 Association Source in the ASSOCIATION object uniquely identify the 166 association group. If the optional TLVs - Global Association 167 Source or Extended Association ID are included, then they MUST be 168 included in combination with mandatory fields to uniquely identify 169 the association group. 171 Association information: As described in [RFC8697], the ASSOCIATION 172 object could also include other optional TLVs based on the 173 association types, that provides 'information' related to the 174 association type. 176 PCC: Path Computation Client. Any client application requesting a 177 path computation to be performed by a Path Computation Element. 179 PCE: Path Computation Element. An entity (component, application, 180 or network node) that is capable of computing a network path or 181 route based on a network graph and applying computational 182 constraints. 184 PCEP: Path Computation Element Protocol. 186 PCEP Tunnel: The entity identified by the PLSP-ID, as per 187 [I-D.koldychev-pce-operational]. 189 3. Motivation 191 The new Association Type (SR Policy Association) and the new TLVs for 192 the ASSOCIATION object, defined in this document, allow a PCEP peer 193 to exchange additional parameters of SR candidate paths and of their 194 associated SR policy. For the SR policy, the parameters are: color 195 and endpoint. For the candidate path, the parameters are: protocol 196 origin, originator, discriminator and preference. 197 [I-D.ietf-spring-segment-routing-policy] describes the concept of SR 198 Policy and these parameters. 200 The motivation for signaling these parameters is summarized in the 201 following subsections. 203 3.1. Group Candidate Paths belonging to the same SR policy 205 Since each candidate path of an SR policy appears as a different LSP 206 (identified via a PLSP-ID) in PCEP, it is useful to group together 207 all the candidate paths that belong to the same SR policy. 208 Furthermore, it is useful for the PCE to have knowledge of the SR 209 candidate path parameters such as color, protocol origin, 210 discriminator, and preference. 212 3.2. Instantiation of SR policy candidate paths 214 A PCE may want to instantiate one or more candidate paths on the PCC, 215 as specified in [RFC8281]. In this scenario, the PCE needs to signal 216 to a PCC tuple using which the PCC can instantiate a candidate 218 path for the SR policy identified. Current PCEP standards (as of the 219 time of this writing) do not provide a way to signal color and 220 preference. Although endpoint can be signaled via the PCEP END- 221 POINTS object, this object may not be suitable because the endpoint 222 to which the path is computed is not required to be the same IPv4/ 223 IPv6 address as the actual endpoint of the SR policy. Thus, a 224 separate way to specify SR policy's endpoint is provided in this 225 document. 227 3.3. Avoid computing lower preference candidate paths 229 When a PCE knows that a given set of candidate paths all belong to 230 the same SR policy, then path computation MAY be done on only the 231 highest preference candidate-path(s). Path computation for lower 232 preference paths is not necessary if one or two higher preference 233 paths are already computed. Since computing their paths will not 234 affect traffic steering, it MAY be postponed until the higher 235 preference paths become invalid, thus saving computation resources on 236 the PCE. 238 3.4. Minimal signaling overhead 240 When an SR policy contains multiple candidate paths computed by a 241 PCE, such candidate paths can be created, updated and deleted 242 independently of each other. This is achieved by making each 243 candidate path correspond to a unique LSP (identified via PLSP-ID). 244 For example, if an SR policy has 4 candidate paths, then if the PCE 245 wants to update one of those candidate paths, only one set of PCUpd 246 and PCRpt messages needs to be exchanged. 248 4. Procedure 250 4.1. Overview 252 As per [RFC8697], LSPs are placed into an association group. As per 253 [I-D.koldychev-pce-operational], LSPs are contained in PCEP Tunnels 254 and a PCEP Tunnel is contained in an Association if all of its LSPs 255 are in that Association. 257 PCEP Tunnels naturally map to SR Candidate Paths and PCEP 258 Associations naturally map to SR Policies. Definition of these 259 mappings is the central purpose of this document. 261 The mapping between PCEP Associations and SR Policies is always one- 262 to-one. However, the mapping between PCEP Tunnels and SR Candidate 263 Paths may be either one-to-one, or many-to-one. The mapping is one- 264 to-one when the SR Candidate Path has only a single constraint and 265 optimization objective. The mapping is many-to-one when the SR 266 Candidate Path has multiple constraints and optimization objectives. 267 For more details on multiple optimization objectives and constraints, 268 see Section 4.3. 270 [Editor's Note - Segment-lists within a candidate path are not 271 represented by different PCEP Tunnels. The subject of encoding 272 multiple segment lists within a candidate path is left to another 273 document and is not specified in this document. It is not a good 274 idea to have each segment-list correspond to a different Tunnel, 275 because when the PCC wants to get a path, it must know in advance how 276 many multipaths (i.e., segment-lists) there will be and create that 277 many Tunnels. For example, if the PCC supports 32 multipaths, then 278 it must delegate 32 Tunnels for every candidate path, which may not 279 be scalable.] 281 A new Association Type is defined in this document, based on the 282 generic ASSOCIATION object. Association type = TBD1 "SR Policy 283 Association Type" for SR Policy Association Group (SRPAG). The SRPAG 284 Association is only meant to be used for SR LSPs and with PCEP peers 285 which advertise SR capability. 287 An Association object of SRPAG group contains TLVs that carry 288 Association Information. The association information can be 289 subdivided into three parts: Policy identifiers, Candidate path 290 identifiers, and Candidate path attributes. 292 Policy Identifiers uniquely identify the SR policy to which a given 293 LSP belongs, within the context of the head-end. Policy Identifiers 294 MUST be the same for all candidate paths in the same SRPAG. Policy 295 Identifiers MUST NOT change for a given LSP during its lifetime. 296 Policy Identifiers MUST be different for different SRPAG 297 associations. When these rules are not satisfied, the PCE MUST send 298 a PCErr message with Error Code = 26 "Association Error", Error Type 299 = TBD6 "Conflicting SRPAG TLV". Policy Identifiers consist of: 301 o Color of SR policy. 303 o Endpoint of SR policy. 305 o Optionally, the policy name. 307 Candidate Path Identifiers uniquely identify the SR candidate path 308 within the context of an SR policy. Candidate path Identifiers MUST 309 NOT change for a given LSP during its lifetime. Candidate path 310 Identifiers MUST be different for different LSPs within the same 311 SRPAG. When these rules are not satisfied, the PCE MUST send a PCErr 312 message with Error Code = 26 "Association Error", Error Type = TBD6 313 "Conflicting SRPAG TLV". Candidate path Identifiers consist of: 315 o Protocol Origin of candidate path. 317 o Originator of candidate path. 319 o Discriminator of candidate path. 321 o Optionally, the candidate path name. 323 Candidate Path Attributes MUST NOT be used to identify the candidate 324 path. Candidate path attributes carry additional information about 325 the candidate path and MAY change during the lifetime of the LSP. 326 Candidate path Attributes consist of: 328 o Preference of candidate path. 330 As per the processing rules specified in section 5.4 of [RFC8697], if 331 a PCEP speaker does not support the SRPAG association type, it MUST 332 return a PCErr message with Error-Type 26 "Association Error" and 333 Error-Value 1 "Association-type is not supported". Please note that 334 the corresponding PCEP session is not reset. 336 4.2. Choice of Association Parameters 338 The Association Parameters (see Section 2) uniquely identify the 339 Association. In this section, we describe how these are to be set. 341 The Association Source MUST be set to the headend value of the SR 342 Policy, as defined in [I-D.ietf-spring-segment-routing-policy]. This 343 applies for both PCC-initiated and PCE-initiated candidate paths. 344 The reasoning for this is that if different PCEs could set their own 345 Association Source, then the candidate paths instantiated by 346 different PCEs would by definition be in different PCEP Associations, 347 which contradicts our requirement that the SR Policy is represented 348 by an Association. 350 If the PCC receives a PCInit message for a non-existing SR Policy, 351 where the Association Source is set not to the headend value but to 352 some globally unique IP address that the PCC owns, then the PCC 353 SHOULD accept the PCInit message and create the SR Policy Association 354 with the Association Source that was sent in the PCInit message. 356 The 16-bit Association ID field in the ASSOCIATION object MUST be set 357 to the value of "1". The Extended Association ID TLV MUST be 358 included and it MUST be in the following format: 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Type = 31 | Length = 8 or 20 | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Color | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 ~ Endpoint ~ 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 Figure 1: Extended Association ID TLV format 372 Type: Extended Association ID TLV, type = 31. 374 Length: Either 8 or 20, depending on whether IPv4 or IPv6 address is 375 encoded in the Endpoint. 377 Color: SR Policy color value. 379 Endpoint: can be either IPv4 or IPv6, depending on whether the policy 380 endpoint is IPv4 or IPv6. This value may be different from the one 381 contained in the END-POINTS object, or in the LSP IDENTIFIERS TLV of 382 the LSP object. Endpoint is meant to strictly correspond to the 383 endpoint of the SR policy, as it is defined in 384 [I-D.ietf-spring-segment-routing-policy]. 386 If the PCEP speaker receives an ASSOCIATION object whose ID and 387 Extended ID do not follow the above specification, then the PCEP 388 speaker MUST send PCErr message with Error-Type 26 "Association 389 Error" and Error-Value 7 "Cannot join the association group". 391 The purpose of choosing the Association Parameters in this way is to 392 guarantee that there is no possibility of a race condition when 393 multiple PCEP speakers want to create the same SR Policy at the same 394 time. By adhering to this format, all PCEP speakers come up with the 395 same Association Parameters independently of each other. Thus, there 396 is no chance that different PCEP speakers will come up with different 397 Association Parameters for the same SR Policy. 399 4.3. Multiple Optimization Objectives and Constraints 401 In certain scenarios, it is desired for each SR Candidate Path to 402 contain multiple sub-candidate paths, each of which has a different 403 optimization objective and constraints. Traffic is then sent ECMP or 404 UCMP among these sub-candidate paths. 406 This is represented in PCEP by a many-to-one mapping between PCEP 407 Tunnels and SR Candidate Paths. This means that multiple PCEP 408 Tunnels are allocated for each SR Candidate Path. Each PCEP Tunnel 409 has its own optimization objective and constraints. When a single SR 410 Candidate Path contains multiple PCEP Tunnels, each of these PCEP 411 Tunnels MUST have identical values of Candidate Path Identifiers, as 412 encoded in SRPOLICY-CPATH-ID TLV, see Section 5.2. 414 5. SR Policy Association Group 416 Two ASSOCIATION object types for IPv4 and IPv6 are defined in 417 [RFC8697]. The ASSOCIATION object includes "Association type" 418 indicating the type of the association group. This document adds a 419 new Association type. 421 Association type = TBD1 "SR Policy Association Type" for SR Policy 422 Association Group (SRPAG). 424 This Association type is dynamic in nature and created by the PCC or 425 PCE for the candidate paths belonging to the same SR policy (as 426 described in [I-D.ietf-spring-segment-routing-policy]). These 427 associations are conveyed via PCEP messages to the PCEP peer. 428 Operator-configured Association Range MUST NOT be set for this 429 Association type and MUST be ignored. 431 SRPAG MUST carry additional TLVs to communicate Association 432 Information. This document specifies four new TLVs to carry 433 Association Information: SRPOLICY-POL-NAME TLV, SRPOLICY-CPATH-ID 434 TLV, SRPOLICY-CPATH-NAME TLV, SRPOLICY-CPATH-PREFERENCE TLV. These 435 five TLVs encode the Policy Identifiers, SR Policy name, Candidate 436 path identifiers, candidate path name, and Candidate path preference, 437 respectively. When any of the mandatory TLVs are missing from the 438 SRPAG association object, the PCE MUST send a PCErr message with 439 Error Code = 26 "Association Error", Error Type = TBD7 "Missing 440 mandatory SRPAG TLV". 442 A given LSP MUST belong to at most one SRPAG, since a candidate path 443 cannot belong to multiple SR policies. If a PCEP speaker receives a 444 PCEP message with more than one SRPAG for an LSP, then the PCEP 445 speaker MUST send a PCErr message with Error-Type 26 "Association 446 Error" and Error-Value TBD8 "Multiple SRPAG for one LSP". If the 447 message is a PCRpt message, then the PCEP speaker MUST close the PCEP 448 connection. Closing the PCEP connection is necessary because 449 ignoring PCRpt messages may lead to inconsistent LSP DB state between 450 the two PCEP peers. 452 If the PCEP speaker receives the SRPAG association when the SR 453 capability (as per [RFC8664] or [I-D.ietf-pce-segment-routing-ipv6]) 454 was not exchanged, the PCEP speaker MUST send a PCErr message with 455 Error-Type 26 "Association Error" and Error-Value TBD9 "Use of SRPAG 456 without SR capability exchange". If the Path Setup Type (PST) of the 457 LSP in SRPAG is not set to SR or SRv6, then the PCEP speaker MUST 458 send a PCErr message with Error-Type 26 "Association Error" and 459 Error-Value TBD10 "non-SR LSP in SRPAG". 461 5.1. SR Policy Name TLV 463 The SRPOLICY-POL-NAME TLV is an optional TLV for the SRPAG 464 Association. At most one SRPOLICY-POL-NAME TLV can be carried and 465 only the first occurrence is processed and any others MUST be 466 ignored. 468 0 1 2 3 469 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 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Type | Length | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | | 474 ~ Policy Name ~ 475 | | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 Figure 2: The SRPOLICY-POL-NAME TLV format 480 Type: TBD3 for "SRPOLICY-POL-NAME" TLV. 482 Length: indicates the total length of the TLV in octets and MUST be 483 greater than 0. The TLV MUST be zero-padded so that the TLV is 484 4-octet aligned. 486 Policy Name: Policy name, as defined in 487 [I-D.ietf-spring-segment-routing-policy]. It SHOULD be a string of 488 printable ASCII characters, without a NULL terminator. 490 5.2. SR Policy Candidate Path Identifiers TLV 492 The SRPOLICY-CPATH-ID TLV is a mandatory TLV for the SRPAG 493 Association. Only one SRPOLICY-CPATH-ID TLV can be carried and only 494 the first occurrence is processed and any others MUST be ignored. 496 0 1 2 3 497 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 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Type | Length | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | Proto. Origin | Reserved | 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Originator ASN | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | | 506 | Originator Address | 507 | | 508 | | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Discriminator | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 Figure 3: The SRPOLICY-CPATH-ID TLV format 515 Type: TBD4 for "SRPOLICY-CPATH-ID" TLV. 517 Length: 28. 519 Protocol Origin: 8-bit value that encodes the protocol origin, as 520 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.3. 522 Reserved: MUST be set to zero on transmission and ignored on receipt. 524 Originator ASN: Represented as 4 byte number, part of the originator 525 identifier, as specified in [I-D.ietf-spring-segment-routing-policy] 526 Section 2.4. 528 Originator Address: Represented as 128 bit value where IPv4 address 529 are encoded in lowest 32 bits, part of the originator identifier, as 530 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.4. 532 Discriminator: 32-bit value that encodes the Discriminator of the 533 candidate path. 535 5.3. SR Policy Candidate Path Name TLV 537 The SRPOLICY-CPATH-NAME TLV is an optional TLV for the SRPAG 538 Association. At most one SRPOLICY-CPATH-NAME TLV can be carried and 539 only the first occurrence is processed and any others MUST be 540 ignored. 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | Type | Length | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | | 548 ~ SR Policy Candidate Path Name ~ 549 | | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 Figure 4: The SRPOLICY-CPATH-NAME TLV format 554 Type: TBD11 for "SRPOLICY-CPATH-NAME" TLV. 556 Length: indicates the total length of the TLV in octets and MUST be 557 greater than 0. The TLV MUST be zero-padded so that the TLV is 558 4-octet aligned. 560 SR Policy Candidate Path Name: SR Policy Candidate Path Name, as 561 defined in [I-D.ietf-spring-segment-routing-policy]. It SHOULD be a 562 string of printable ASCII characters, without a NULL terminator. 564 5.4. SR Policy Candidate Path Preference TLV 566 The SRPOLICY-CPATH-PREFERENCE TLV is an optional TLV for the SRPAG 567 Association. Only one SRPOLICY-CPATH-PREFERENCE TLV can be carried 568 and only the first occurrence is processed and any others MUST be 569 ignored. 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Type | Length | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Preference | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Figure 5: The SRPOLICY-CPATH-PREFERENCE TLV format 581 Type: TBD5 for "SRPOLICY-CPATH-PREFERENCE" TLV. 583 Length: 4. 585 Preference: Numerical preference of the candidate path, as specified 586 in [I-D.ietf-spring-segment-routing-policy] Section 2.7. 588 If the TLV is missing, a default preference of 100 as specified in 589 [I-D.ietf-spring-segment-routing-policy] is used. 591 6. Examples 593 6.1. PCC Initiated SR Policy with single candidate-path 595 PCReq and PCRep messages are exchanged in the following sequence: 597 1. PCC sends PCReq message to the PCE, encoding the SRPAG 598 ASSOCIATION object and TLVs in the PCReq message. 600 2. PCE returns the path in PCRep message, and echoes back the SRPAG 601 object that was used in the computation. 603 PCRpt and PCUpd messages are exchanged in the following sequence: 605 1. PCC sends PCRpt message to the PCE, including the LSP object and 606 the SRPAG ASSOCIATION object. 608 2. PCE computes path, possibly making use of the Association 609 Information from the SRPAG ASSOCIATION object. 611 3. PCE updates the SR policy candidate path's ERO using PCUpd 612 message. 614 6.2. PCC Initiated SR Policy with multiple candidate-paths 616 PCRpt and PCUpd messages are exchanged in the following sequence: 618 1. For each candidate path of the SR Policy, the PCC generates a 619 different PLSP-ID and symbolic-name and sends multiple PCRpt 620 messages (or one message with multiple LSP objects) to the PCE. 621 Each LSP object is followed by SRPAG ASSOCIATION object with 622 identical Color and Endpoint values. The Association Source is 623 set to the IP address of the PCC and the Association ID is set to 624 a number that PCC locally chose to represent the SR Policy. 626 2. PCE takes into account that all the LSPs belong to the same SR 627 policy. PCE prioritizes computation for the highest preference 628 LSP and sends PCUpd message(s) back to the PCC. 630 3. If a new candidate path is added on the PCC by the operator, then 631 a new PLSP-ID and symbolic name is generated for that candidate 632 path and a new PCRpt is sent to the PCE. 634 4. If an existing candidate path is removed from the PCC by the 635 operator, then that PLSP-ID is deleted from the PCE by sending 636 PCRpt with the R-flag in the LSP object set. 638 6.3. PCE Initiated SR Policy with single candidate-path 640 A candidate-path is created using the following steps: 642 1. PCE sends PCInitiate message, containing the SRPAG Association 643 object. The Association Source is set to the IP address of the 644 PCC and the Association ID is set to 0, as described in 645 Section 4.2. 647 2. PCC uses the color, endpoint and preference from the SRPAG object 648 to create a new candidate path. If no SR policy exists to hold 649 the candidate path, then a new SR policy is created to hold the 650 new candidate-path. The Originator of the candidate path is set 651 to be the address of the PCE that is sending the PCInitiate 652 message. 654 3. PCC sends a PCRpt message back to the PCE to report the newly 655 created Candidate Path. The PCRpt message contains the SRPAG 656 Association object. The Association Source is set to the IP 657 address of the PCC and the Association ID is set to a number that 658 PCC locally chose to represent the SR Policy. 660 A candidate-path is deleted using the following steps: 662 1. PCE sends PCInitiate message, setting the R-flag in the LSP 663 object. 665 2. PCC uses the PLSP-ID from the LSP object to find the candidate 666 path and delete it. If this is the last candidate path under the 667 SR policy, then the containing SR policy is deleted as well. 669 6.4. PCE Initiated SR Policy with multiple candidate-paths 671 A candidate-path is created using the following steps: 673 1. PCE sends a separate PCInitiate message for every candidate path 674 that it wants to create, or it sends multiple LSP objects within 675 a single PCInitiate message. The SRPAG Association object is 676 sent for every LSP in the PCInitiate message. The Association 677 Source is set to the IP address of the PCC and the Association ID 678 is set to 0, as described in Section 4.2. 680 2. PCC creates multiple candidate paths under the same SR policy, 681 identified by Color and Endpoint. 683 3. PCC sends a PCRpt message back to the PCE to report the newly 684 created Candidate Path. The PCRpt message contains the SRPAG 685 Association object. The Association Source is set to the IP 686 address of the PCC and the Association ID is set to a number that 687 PCC locally chose to represent the SR Policy. 689 A candidate path is deleted using the following steps: 691 1. PCE sends PCInitiate message, setting the R-flag in the LSP 692 object. 694 2. PCC uses the PLSP-ID from the LSP object to find the candidate 695 path and delete it. 697 7. IANA Considerations 699 7.1. Association Type 701 This document defines a new association type: SR Policy Association 702 Group (SRPAG). IANA is requested to make the assignment of a new 703 value for the sub-registry "ASSOCIATION Type Field" (request to be 704 created in [RFC8697]), as follows: 706 +----------------------+-------------------------+------------------+ 707 | Association Type | Association Name | Reference | 708 | Value | | | 709 +----------------------+-------------------------+------------------+ 710 | TBD1 | SR Policy Association | This document | 711 +----------------------+-------------------------+------------------+ 713 7.2. PCEP Errors 715 This document defines five new Error-Values within the "Association 716 Error" Error-Type. IANA is requested to allocate new error values 717 within the "PCEP-ERROR Object Error Types and Values" sub-registry of 718 the PCEP Numbers registry, as follows: 720 +-------+----------+-----------------------------+------------------+ 721 | Error | Error | Meaning | Reference | 722 | Type | Value | | | 723 +-------+----------+-----------------------------+------------------+ 724 | 29 | TBD6 | Conflicting SRPAG TLV | This document | 725 +-------+----------+-----------------------------+------------------+ 726 | 29 | TBD7 | Missing mandatory SRPAG TLV | This document | 727 +-------+----------+-----------------------------+------------------+ 728 | 29 | TBD8 | Multiple SRPAG for one LSP | This document | 729 +-------+----------+-----------------------------+------------------+ 730 | 29 | TBD9 | Use of SRPAG without SR | This document | 731 | | | capability exchange | | 732 +-------+----------+-----------------------------+------------------+ 733 | 29 | TBD10 | non-SR LSP in SRPAG | This document | 734 +-------+----------+-----------------------------+------------------+ 736 7.3. SRPAG TLVs 738 This document defines five new TLVs for carrying additional 739 information about SR policy and SR candidate paths. IANA is 740 requested to make the assignment of a new value for the existing 741 "PCEP TLV Type Indicators" registry as follows: 743 +------------+-----------------------------------+------------------+ 744 | TLV Type | TLV Name | Reference | 745 | Value | | | 746 +------------+-----------------------------------+------------------+ 747 | TBD3 | SRPOLICY-POL-NAME | This document | 748 +------------+-----------------------------------+------------------+ 749 | TBD4 | SRPOLICY-CPATH-ID | This document | 750 +------------+-----------------------------------+------------------+ 751 | TBD11 | SRPOLICY-CPATH-NAME | This document | 752 +------------+-----------------------------------+------------------+ 753 | TBD5 | SRPOLICY-CPATH-PREFERENCE | This document | 754 +------------+-----------------------------------+------------------+ 756 8. Implementation Status 758 [Note to the RFC Editor - remove this section before publication, as 759 well as remove the reference to RFC 7942.] 761 This section records the status of known implementations of the 762 protocol defined by this specification at the time of posting of this 763 Internet-Draft, and is based on a proposal described in [RFC7942]. 764 The description of implementations in this section is intended to 765 assist the IETF in its decision processes in progressing drafts to 766 RFCs. Please note that the listing of any individual implementation 767 here does not imply endorsement by the IETF. Furthermore, no effort 768 has been spent to verify the information presented here that was 769 supplied by IETF contributors. This is not intended as, and must not 770 be construed to be, a catalog of available implementations or their 771 features. Readers are advised to note that other implementations may 772 exist. 774 According to [RFC7942], "this will allow reviewers and working groups 775 to assign due consideration to documents that have the benefit of 776 running code, which may serve as evidence of valuable experimentation 777 and feedback that have made the implemented protocols more mature. 778 It is up to the individual working groups to use this information as 779 they see fit". 781 8.1. Cisco 783 o Organization: Cisco Systems 785 o Implementation: Head-end and controller. 787 o Description: An experimental code-point is currently used. 789 o Maturity Level: Proof of concept. 791 o Coverage: Full. 793 o Contact: mkoldych@cisco.com 795 9. Security Considerations 797 This document defines one new type for association, which do not add 798 any new security concerns beyond those discussed in [RFC5440], 799 [RFC8231], [RFC8664], [I-D.ietf-pce-segment-routing-ipv6] and 800 [RFC8697] in itself. 802 The information carried in the SRPAG Association object, as per this 803 document is related to SR Policy. It often reflects information that 804 can also be derived from the SR Database, but association provides a 805 much easier grouping of related LSPs and messages. The SRPAG 806 association could provides an adversary with the opportunity to 807 eavesdrop on the relationship between the LSPs. Thus securing the 808 PCEP session using Transport Layer Security (TLS) [RFC8253], as per 809 the recommendations and best current practices in [RFC7525], is 810 RECOMMENDED. 812 10. Acknowledgement 814 Would like to thank Stephane Litkowski and Praveen Kumar for review 815 comments. 817 11. References 819 11.1. Normative References 821 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 822 Requirement Levels", BCP 14, RFC 2119, 823 DOI 10.17487/RFC2119, March 1997, 824 . 826 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 827 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 828 DOI 10.17487/RFC5440, March 2009, 829 . 831 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 832 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 833 May 2017, . 835 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 836 Computation Element Communication Protocol (PCEP) 837 Extensions for Stateful PCE", RFC 8231, 838 DOI 10.17487/RFC8231, September 2017, 839 . 841 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 842 Computation Element Communication Protocol (PCEP) 843 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 844 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 845 . 847 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 848 Code: The Implementation Status Section", BCP 205, 849 RFC 7942, DOI 10.17487/RFC7942, July 2016, 850 . 852 [I-D.ietf-spring-segment-routing-policy] 853 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 854 P. Mattes, "Segment Routing Policy Architecture", draft- 855 ietf-spring-segment-routing-policy-09 (work in progress), 856 November 2020. 858 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 859 Dhody, D., and Y. Tanaka, "Path Computation Element 860 Communication Protocol (PCEP) Extensions for Establishing 861 Relationships between Sets of Label Switched Paths 862 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 863 . 865 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 866 and J. Hardwick, "Path Computation Element Communication 867 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 868 DOI 10.17487/RFC8664, December 2019, 869 . 871 [I-D.koldychev-pce-operational] 872 Koldychev, M., Sivabalan, S., Negi, M., Achaval, D., and 873 H. Kotni, "PCEP Operational Clarification", draft- 874 koldychev-pce-operational-02 (work in progress), August 875 2020. 877 11.2. Informative References 879 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 880 Element (PCE)-Based Architecture", RFC 4655, 881 DOI 10.17487/RFC4655, August 2006, 882 . 884 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 885 "Recommendations for Secure Use of Transport Layer 886 Security (TLS) and Datagram Transport Layer Security 887 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 888 2015, . 890 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 891 "PCEPS: Usage of TLS to Provide a Secure Transport for the 892 Path Computation Element Communication Protocol (PCEP)", 893 RFC 8253, DOI 10.17487/RFC8253, October 2017, 894 . 896 [I-D.ietf-pce-segment-routing-ipv6] 897 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 898 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 899 Routing leveraging the IPv6 data plane", draft-ietf-pce- 900 segment-routing-ipv6-08 (work in progress), November 2020. 902 Appendix A. Contributors 904 Dhruv Dhody 905 Huawei Technologies 906 Divyashree Techno Park, Whitefield 907 Bangalore, Karnataka 560066 908 India 910 Email: dhruv.ietf@gmail.com 912 Cheng Li 913 Huawei Technologies 914 Huawei Campus, No. 156 Beiqing Rd. 915 Beijing, 10095 916 China 918 Email: chengli13@huawei.com 920 Authors' Addresses 922 Mike Koldychev 923 Cisco Systems, Inc. 924 2000 Innovation Drive 925 Kanata, Ontario K2K 3E8 926 Canada 928 Email: mkoldych@cisco.com 930 Siva Sivabalan 931 Ciena Corporation 932 385 Terry Fox Dr. 933 Kanata, Ontario K2K 0L1 934 Canada 936 Email: ssivabal@ciena.com 937 Colby Barth 938 Juniper Networks, Inc. 940 Email: cbarth@juniper.net 942 Shuping Peng 943 Huawei Technologies 944 Huawei Campus, No. 156 Beiqing Rd. 945 Beijing 100095 946 China 948 Email: pengshuping@huawei.com 950 Hooman Bidgoli 951 Nokia 953 Email: hooman.bidgoli@nokia.com