idnits 2.17.1 draft-ietf-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 (February 22, 2021) is 1160 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: August 26, 2021 Ciena Corporation 6 C. Barth 7 Juniper Networks, Inc. 8 S. Peng 9 Huawei Technologies 10 H. Bidgoli 11 Nokia 12 February 22, 2021 14 PCEP extension to support Segment Routing Policy Candidate Paths 15 draft-ietf-pce-segment-routing-policy-cp-03 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 August 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 . . . . . . . . . . . . . . . 5 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 TLV Type Indicators . . . . . . . . . . . . . . . . 16 94 7.3. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 16 95 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 96 8.1. Cisco . . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 98 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 100 11.1. Normative References . . . . . . . . . . . . . . . . . . 18 101 11.2. Informative References . . . . . . . . . . . . . . . . . 20 102 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 20 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 needs to instantiate one or more candidate paths on the PCC, as 215 specified in [RFC8281]. Each candidate path is identified by the 216 tuple . This draft provides a mechanism to signal this 218 information in PCEP. 220 3.3. Avoid computing lower preference candidate paths 222 When a PCE knows that a given set of candidate paths all belong to 223 the same SR policy, then path computation MAY be done on only the 224 highest preference candidate-path(s). Path computation for lower 225 preference paths is not necessary if one or two higher preference 226 paths are already computed. Since computing their paths will not 227 affect traffic steering, it MAY be postponed until the higher 228 preference paths become invalid, thus saving computation resources on 229 the PCE. 231 3.4. Minimal signaling overhead 233 When an SR policy contains multiple candidate paths computed by a 234 PCE, such candidate paths can be created, updated and deleted 235 independently of each other. This is achieved by making each 236 candidate path correspond to a unique LSP (identified via PLSP-ID). 238 For example, if an SR policy has 4 candidate paths, then if the PCE 239 wants to update one of those candidate paths, only one set of PCUpd 240 and PCRpt messages needs to be exchanged. 242 4. Procedure 244 4.1. Overview 246 As per [RFC8697], LSPs are placed into an association group. As per 247 [I-D.koldychev-pce-operational], LSPs are contained in PCEP Tunnels 248 and a PCEP Tunnel is contained in an Association if all of its LSPs 249 are in that Association. 251 PCEP Tunnels naturally map to SR Candidate Paths and PCEP 252 Associations naturally map to SR Policies. Definition of these 253 mappings is the central purpose of this document. 255 The mapping between PCEP Associations and SR Policies is always one- 256 to-one. However, the mapping between PCEP Tunnels and SR Candidate 257 Paths may be either one-to-one, or many-to-one. The mapping is one- 258 to-one when the SR Candidate Path has only a single constraint and 259 optimization objective. The mapping is many-to-one when the SR 260 Candidate Path has multiple constraints and optimization objectives. 261 For more details on multiple optimization objectives and constraints, 262 see Section 4.3. 264 [Editor's Note - Segment-lists within a candidate path are not 265 represented by different PCEP Tunnels. The subject of encoding 266 multiple segment lists within a candidate path is left to another 267 document and is not specified in this document. It is not a good 268 idea to have each segment-list correspond to a different Tunnel, 269 because when the PCC wants to get a path, it must know in advance how 270 many multipaths (i.e., segment-lists) there will be and create that 271 many Tunnels. For example, if the PCC supports 32 multipaths, then 272 it must delegate 32 Tunnels for every candidate path, which may not 273 be scalable.] 275 A new Association Type is defined in this document, based on the 276 generic ASSOCIATION object. Association type = TBD1 "SR Policy 277 Association" for SR Policy Association Group (SRPAG). The SRPAG 278 Association MUST NOT be used for LSPs that are not part of an SR 279 Policy. 281 An Association object of SRPAG group contains TLVs that carry 282 Association Information. The association information can be 283 subdivided into three parts: Policy identifiers, Candidate path 284 identifiers, and Candidate path attributes. 286 Policy Identifiers uniquely identify the SR policy to which a given 287 LSP belongs, within the context of the head-end. Policy Identifiers 288 MUST be the same for all candidate paths in the same SRPAG. Policy 289 Identifiers MUST NOT change for a given LSP during its lifetime. 290 Policy Identifiers MUST be different for different SRPAG 291 associations. When these rules are not satisfied, the PCE MUST send 292 a PCErr message with Error Code = 26 "Association Error", Error Type 293 = TBD6 "Inconsistent SRPAG Identifiers". Policy Identifiers consist 294 of: 296 o Color of SR policy. 298 o Endpoint of SR policy. 300 o Optionally, the policy name. 302 Candidate Path Identifiers uniquely identify the SR candidate path 303 within the context of an SR policy. Candidate path Identifiers MUST 304 NOT change for a given LSP during its lifetime. Candidate path 305 Identifiers MUST be different for different LSPs within the same 306 SRPAG. When these rules are not satisfied, the PCE MUST send a PCErr 307 message with Error Code = 26 "Association Error", Error Type = TBD6 308 "Inconsistent SRPAG Identifiers". Candidate path Identifiers consist 309 of: 311 o Protocol Origin of candidate path. 313 o Originator of candidate path. 315 o Discriminator of candidate path. 317 o Optionally, the candidate path name. 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 [RFC8697], if 327 a PCEP speaker does not support the SRPAG association type, it MUST 328 return a PCErr message with Error-Type 26 "Association Error" and 329 Error-Value 1 "Association-type is not supported". Please note that 330 the corresponding PCEP session is not reset. 332 4.2. Choice of Association Parameters 334 The Association Parameters (see Section 2) uniquely identify the 335 Association. In this section, we describe how these are to be set. 337 The Association Source MUST be set to the headend value of the SR 338 Policy, as defined in [I-D.ietf-spring-segment-routing-policy]. 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 If the PCC receives a PCInit message for a non-existing SR Policy, 347 where the Association Source is set not to the headend value but to 348 some globally unique IP address that the PCC owns, then the PCC 349 SHOULD accept the PCInit message and create the SR Policy Association 350 with the Association Source that was sent in the PCInit message. 352 The 16-bit Association ID field in the ASSOCIATION object MUST be set 353 to the value of "1". The Extended Association ID TLV MUST be 354 included and it MUST be in the following format: 356 0 1 2 3 357 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 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Type = 31 | Length = 8 or 20 | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Color | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 ~ Endpoint ~ 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 1: Extended Association ID TLV format 368 Type: Extended Association ID TLV, type = 31. 370 Length: Either 8 or 20, depending on whether IPv4 or IPv6 address is 371 encoded in the Endpoint. 373 Color: SR Policy color value. 375 Endpoint: can be either IPv4 or IPv6, depending on whether the policy 376 endpoint is IPv4 or IPv6. This value MAY be different from the one 377 contained in the END-POINTS object, or in the LSP IDENTIFIERS TLV of 378 the LSP object. This value is part of the tuple 379 that identifies the SR Policy on a given head-end. 381 If the PCEP speaker receives an ASSOCIATION object whose ID and 382 Extended ID do not follow the above specification, then the PCEP 383 speaker MUST send PCErr message with Error-Type 26 "Association 384 Error" and Error-Value 7 "Cannot join the association group". 386 The purpose of choosing the Association Parameters in this way is to 387 guarantee that there is no possibility of a race condition when 388 multiple PCEP speakers want to create the same SR Policy at the same 389 time. By adhering to this format, all PCEP speakers come up with the 390 same Association Parameters independently of each other. Thus, there 391 is no chance that different PCEP speakers will come up with different 392 Association Parameters for the same SR Policy. 394 4.3. Multiple Optimization Objectives and Constraints 396 In certain scenarios, it is desired for each SR Candidate Path to 397 contain multiple sub-candidate paths, each of which has a different 398 optimization objective and constraints. Traffic is then sent ECMP or 399 UCMP among these sub-candidate paths. 401 This is represented in PCEP by a many-to-one mapping between PCEP 402 Tunnels and SR Candidate Paths. This means that multiple PCEP 403 Tunnels are allocated for each SR Candidate Path. Each PCEP Tunnel 404 has its own optimization objective and constraints. When a single SR 405 Candidate Path contains multiple PCEP Tunnels, each of these PCEP 406 Tunnels MUST have identical values of Candidate Path Identifiers, as 407 encoded in SRPOLICY-CPATH-ID TLV, see Section 5.2. 409 5. SR Policy Association Group 411 Two ASSOCIATION object types for IPv4 and IPv6 are defined in 412 [RFC8697]. The ASSOCIATION object includes "Association type" 413 indicating the type of the association group. This document adds a 414 new Association type. 416 Association type = TBD1 "SR Policy Association" for SR Policy 417 Association Group (SRPAG). 419 This Association type is dynamic in nature and created by the PCC or 420 PCE for the candidate paths belonging to the same SR policy (as 421 described in [I-D.ietf-spring-segment-routing-policy]). These 422 associations are conveyed via PCEP messages to the PCEP peer. 423 Operator-configured Association Range MUST NOT be set for this 424 Association type and MUST be ignored. 426 SRPAG MUST carry additional TLVs to communicate Association 427 Information. This document specifies four new TLVs to carry 428 Association Information: SRPOLICY-POL-NAME TLV, SRPOLICY-CPATH-ID 429 TLV, SRPOLICY-CPATH-NAME TLV, SRPOLICY-CPATH-PREFERENCE TLV. These 430 four TLVs encode the SR Policy Name, Candidate Path Identifiers, 431 Candidate Path Name, and Candidate Path Preference, respectively. Of 432 these new TLVs, only SRPOLICY-CPATH-ID TLV is mandatory. When the 433 mandatory TLV is missing from the SRPAG association object, the PCE 434 MUST send a PCErr message with Error Code = 26 "Association Error", 435 Error Type = TBD7 "Missing mandatory SRPAG TLV". 437 A given LSP MUST belong to at most one SRPAG, since a candidate path 438 cannot belong to multiple SR policies. If a PCEP speaker receives a 439 PCEP message with more than one SRPAG for an LSP, then the PCEP 440 speaker MUST send a PCErr message with Error-Type 26 "Association 441 Error" and Error-Value TBD8 "Same LSP in multiple SRPAG". If the 442 message is a PCRpt message, then the PCEP speaker MUST close the PCEP 443 connection. Closing the PCEP connection is necessary because 444 ignoring PCRpt messages may lead to inconsistent LSP DB state between 445 the two PCEP peers. 447 If the PCEP speaker receives the SRPAG association when the SR 448 capability (as per [RFC8664] or [I-D.ietf-pce-segment-routing-ipv6]) 449 was not exchanged, the PCEP speaker MUST send a PCErr message with 450 Error-Type 26 "Association Error" and Error-Value TBD9 "Use of SRPAG 451 without SR capability exchange". If the Path Setup Type (PST) of the 452 LSP in SRPAG is not set to SR or SRv6, then the PCEP speaker MUST 453 send a PCErr message with Error-Type 26 "Association Error" and 454 Error-Value TBD10 "non-SR LSP in SRPAG". 456 5.1. SR Policy Name TLV 458 The SRPOLICY-POL-NAME TLV is an optional TLV for the SRPAG 459 Association. At most one SRPOLICY-POL-NAME TLV SHOULD be encoded by 460 the sender and only the first occurrence is processed and any others 461 MUST be ignored. 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Type | Length | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | | 469 ~ Policy Name ~ 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 2: The SRPOLICY-POL-NAME TLV format 475 Type: TBD2 for "SRPOLICY-POL-NAME" TLV. 477 Length: indicates the length of the value portion of the TLV in 478 octets and MUST be greater than 0. The TLV MUST be zero-padded so 479 that the TLV is 4-octet aligned. 481 Policy Name: Policy name, as defined in 482 [I-D.ietf-spring-segment-routing-policy]. It SHOULD be a string of 483 printable ASCII characters, without a NULL terminator. 485 5.2. SR Policy Candidate Path Identifiers TLV 487 The SRPOLICY-CPATH-ID TLV is a mandatory TLV for the SRPAG 488 Association. Only one SRPOLICY-CPATH-ID TLV SHOULD be encoded by the 489 sender and only the first occurrence is processed and any others MUST 490 be ignored. 492 0 1 2 3 493 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 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Type | Length | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | Proto. Origin | Reserved | 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 | Originator ASN | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | | 502 | Originator Address | 503 | | 504 | | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Discriminator | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Figure 3: The SRPOLICY-CPATH-ID TLV format 511 Type: TBD3 for "SRPOLICY-CPATH-ID" TLV. 513 Length: 28. 515 Protocol Origin: 8-bit value that encodes the protocol origin, as 516 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.3. 518 Reserved: MUST be set to zero on transmission and ignored on receipt. 520 Originator ASN: Represented as 4 byte number, part of the originator 521 identifier, as specified in [I-D.ietf-spring-segment-routing-policy] 522 Section 2.4. 524 Originator Address: Represented as 128 bit value where IPv4 address 525 are encoded in lowest 32 bits, part of the originator identifier, as 526 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.4. 528 Discriminator: 32-bit value that encodes the Discriminator of the 529 candidate path. 531 5.3. SR Policy Candidate Path Name TLV 533 The SRPOLICY-CPATH-NAME TLV is an optional TLV for the SRPAG 534 Association. At most one SRPOLICY-CPATH-NAME TLV SHOULD be encoded 535 by the sender and only the first occurrence is processed and any 536 others MUST be ignored. 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Type | Length | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 | | 544 ~ SR Policy Candidate Path Name ~ 545 | | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 4: The SRPOLICY-CPATH-NAME TLV format 550 Type: TBD4 for "SRPOLICY-CPATH-NAME" TLV. 552 Length: indicates the length of the value portion of the TLV in 553 octets and MUST be greater than 0. The TLV MUST be zero-padded so 554 that the TLV is 4-octet aligned. 556 SR Policy Candidate Path Name: SR Policy Candidate Path Name, as 557 defined in [I-D.ietf-spring-segment-routing-policy]. It SHOULD be a 558 string of printable ASCII characters, without a NULL terminator. 560 5.4. SR Policy Candidate Path Preference TLV 562 The SRPOLICY-CPATH-PREFERENCE TLV is an optional TLV for the SRPAG 563 Association. Only one SRPOLICY-CPATH-PREFERENCE TLV SHOULD be 564 encoded by the sender and only the first occurrence is processed and 565 any others MUST be ignored. 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type | Length | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Preference | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 Figure 5: The SRPOLICY-CPATH-PREFERENCE TLV format 577 Type: TBD5 for "SRPOLICY-CPATH-PREFERENCE" TLV. 579 Length: 4. 581 Preference: Numerical preference of the candidate path, as specified 582 in [I-D.ietf-spring-segment-routing-policy] Section 2.7. 584 If the TLV is missing, a default preference of 100 as specified in 585 [I-D.ietf-spring-segment-routing-policy] is used. 587 6. Examples 589 6.1. PCC Initiated SR Policy with single candidate-path 591 PCReq and PCRep messages are exchanged in the following sequence: 593 1. PCC sends PCReq message to the PCE, encoding the SRPAG 594 ASSOCIATION object and TLVs in the PCReq message. 596 2. PCE returns the path in PCRep message, and echoes back the SRPAG 597 object that was used in the computation. 599 PCRpt and PCUpd messages are exchanged in the following sequence: 601 1. PCC sends PCRpt message to the PCE, including the LSP object and 602 the SRPAG ASSOCIATION object. 604 2. PCE computes path, possibly making use of the Association 605 Information from the SRPAG ASSOCIATION object. 607 3. PCE updates the SR policy candidate path's ERO using PCUpd 608 message. 610 6.2. PCC Initiated SR Policy with multiple candidate-paths 612 PCRpt and PCUpd messages are exchanged in the following sequence: 614 1. For each candidate path of the SR Policy, the PCC generates a 615 different PLSP-ID and symbolic-name and sends multiple PCRpt 616 messages (or one message with multiple LSP objects) to the PCE. 617 Each LSP object is followed by SRPAG ASSOCIATION object with 618 identical Color and Endpoint values. The Association Source is 619 set to the IP address of the PCC and the Association ID is set to 620 a number that PCC locally chose to represent the SR Policy. 622 2. PCE takes into account that all the LSPs belong to the same SR 623 policy. PCE prioritizes computation for the highest preference 624 LSP and sends PCUpd message(s) back to the PCC. 626 3. If a new candidate path is added on the PCC by the operator, then 627 a new PLSP-ID and symbolic name is generated for that candidate 628 path and a new PCRpt is sent to the PCE. 630 4. If an existing candidate path is removed from the PCC by the 631 operator, then that PLSP-ID is deleted from the PCE by sending 632 PCRpt with the R-flag in the LSP object set. 634 6.3. PCE Initiated SR Policy with single candidate-path 636 A candidate-path is created using the following steps: 638 1. PCE sends PCInitiate message, containing the SRPAG Association 639 object. The Association Source is set to the IP address of the 640 PCC and the Association ID is set to 0, as described in 641 Section 4.2. 643 2. PCC uses the color, endpoint and preference from the SRPAG object 644 to create a new candidate path. If no SR policy exists to hold 645 the candidate path, then a new SR policy is created to hold the 646 new candidate-path. The Originator of the candidate path is set 647 to be the address of the PCE that is sending the PCInitiate 648 message. 650 3. PCC sends a PCRpt message back to the PCE to report the newly 651 created Candidate Path. The PCRpt message contains the SRPAG 652 Association object. The Association Source is set to the IP 653 address of the PCC and the Association ID is set to a number that 654 PCC locally chose to represent the SR Policy. 656 A candidate-path is deleted using the following steps: 658 1. PCE sends PCInitiate message, setting the R-flag in the LSP 659 object. 661 2. PCC uses the PLSP-ID from the LSP object to find the candidate 662 path and delete it. If this is the last candidate path under the 663 SR policy, then the containing SR policy is deleted as well. 665 6.4. PCE Initiated SR Policy with multiple candidate-paths 667 A candidate-path is created using the following steps: 669 1. PCE sends a separate PCInitiate message for every candidate path 670 that it wants to create, or it sends multiple LSP objects within 671 a single PCInitiate message. The SRPAG Association object is 672 sent for every LSP in the PCInitiate message. The Association 673 Source is set to the IP address of the PCC and the Association ID 674 is set to 0, as described in Section 4.2. 676 2. PCC creates multiple candidate paths under the same SR policy, 677 identified by Color and Endpoint. 679 3. PCC sends a PCRpt message back to the PCE to report the newly 680 created Candidate Path. The PCRpt message contains the SRPAG 681 Association object. The Association Source is set to the IP 682 address of the PCC and the Association ID is set to a number that 683 PCC locally chose to represent the SR Policy. 685 A candidate path is deleted using the following steps: 687 1. PCE sends PCInitiate message, setting the R-flag in the LSP 688 object. 690 2. PCC uses the PLSP-ID from the LSP object to find the candidate 691 path and delete it. 693 7. IANA Considerations 695 7.1. Association Type 697 This document defines a new association type: SR Policy Association. 698 IANA is requested to make the following codepoint assignment in the 699 "ASSOCIATION Type Field" subregistry [RFC8697] within the "Path 700 Computation Element Protocol (PCEP) Numbers" registry: 702 +-----------+-------------------------------------------+-----------+ 703 | Type | Name | Reference | 704 +-----------+-------------------------------------------+-----------+ 705 | TBD1 | SR Policy Association | This.I-D | 706 +-----------+-------------------------------------------+-----------+ 708 7.2. PCEP TLV Type Indicators 710 This document defines four new TLVs for carrying additional 711 information about SR policy and SR candidate paths. IANA is 712 requested to make the assignment of a new value for the existing 713 "PCEP TLV Type Indicators" registry as follows: 715 +-----------+-------------------------------------------+-----------+ 716 | Value | Description | Reference | 717 +-----------+-------------------------------------------+-----------+ 718 | TBD2 | SRPOLICY-POL-NAME | This.I-D | 719 +-----------+-------------------------------------------+-----------+ 720 | TBD3 | SRPOLICY-CPATH-ID | This.I-D | 721 +-----------+-------------------------------------------+-----------+ 722 | TBD4 | SRPOLICY-CPATH-NAME | This.I-D | 723 +-----------+-------------------------------------------+-----------+ 724 | TBD5 | SRPOLICY-CPATH-PREFERENCE | This.I-D | 725 +-----------+-------------------------------------------+-----------+ 727 7.3. PCEP Errors 729 This document defines five new Error-Values within the "Association 730 Error" Error-Type. IANA is requested to allocate new error values 731 within the "PCEP-ERROR Object Error Types and Values" sub-registry of 732 the PCEP Numbers registry, as follows: 734 +------------+------------------+-----------------------+-----------+ 735 | Error-Type | Meaning | Error-value | Reference | 736 +------------+------------------+-----------------------+-----------+ 737 | 26 | Association | | [RFC8697] | 738 | | Error | | | 739 +------------+------------------+-----------------------+-----------+ 740 | | | TBD6: Inconsistent | This.I-D | 741 | | | SRPAG Identifiers | | 742 +------------+------------------+-----------------------+-----------+ 743 | | | TBD7: Missing | This.I-D | 744 | | | mandatory SRPAG TLV | | 745 +------------+------------------+-----------------------+-----------+ 746 | | | TBD8: Same LSP in | This.I-D | 747 | | | multiple SRPAG | | 748 +------------+------------------+-----------------------+-----------+ 749 | | | TBD9: Use of SRPAG | This.I-D | 750 | | | without SR capability | | 751 | | | exchange | | 752 +------------+------------------+-----------------------+-----------+ 753 | | | TBD10: non-SR LSP in | This.I-D | 754 | | | SRPAG | | 755 +------------+------------------+-----------------------+-----------+ 757 8. Implementation Status 759 [Note to the RFC Editor - remove this section before publication, as 760 well as remove the reference to RFC 7942.] 762 This section records the status of known implementations of the 763 protocol defined by this specification at the time of posting of this 764 Internet-Draft, and is based on a proposal described in [RFC7942]. 765 The description of implementations in this section is intended to 766 assist the IETF in its decision processes in progressing drafts to 767 RFCs. Please note that the listing of any individual implementation 768 here does not imply endorsement by the IETF. Furthermore, no effort 769 has been spent to verify the information presented here that was 770 supplied by IETF contributors. This is not intended as, and must not 771 be construed to be, a catalog of available implementations or their 772 features. Readers are advised to note that other implementations may 773 exist. 775 According to [RFC7942], "this will allow reviewers and working groups 776 to assign due consideration to documents that have the benefit of 777 running code, which may serve as evidence of valuable experimentation 778 and feedback that have made the implemented protocols more mature. 779 It is up to the individual working groups to use this information as 780 they see fit". 782 8.1. Cisco 784 o Organization: Cisco Systems 786 o Implementation: Head-end and controller. 788 o Description: An experimental code-point is currently used. 790 o Maturity Level: Proof of concept. 792 o Coverage: Full. 794 o Contact: mkoldych@cisco.com 796 9. Security Considerations 798 This document defines one new type for association, which do not add 799 any new security concerns beyond those discussed in [RFC5440], 800 [RFC8231], [RFC8664], [I-D.ietf-pce-segment-routing-ipv6] and 801 [RFC8697] in itself. 803 The information carried in the SRPAG Association object, as per this 804 document is related to SR Policy. It often reflects information that 805 can also be derived from the SR Database, but association provides a 806 much easier grouping of related LSPs and messages. The SRPAG 807 association could provides an adversary with the opportunity to 808 eavesdrop on the relationship between the LSPs. Thus securing the 809 PCEP session using Transport Layer Security (TLS) [RFC8253], as per 810 the recommendations and best current practices in [RFC7525], is 811 RECOMMENDED. 813 10. Acknowledgement 815 Would like to thank Stephane Litkowski, Praveen Kumar and Tom Petch 816 for review comments. 818 11. References 820 11.1. Normative References 822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 823 Requirement Levels", BCP 14, RFC 2119, 824 DOI 10.17487/RFC2119, March 1997, 825 . 827 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 828 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 829 DOI 10.17487/RFC5440, March 2009, 830 . 832 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 833 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 834 May 2017, . 836 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 837 Computation Element Communication Protocol (PCEP) 838 Extensions for Stateful PCE", RFC 8231, 839 DOI 10.17487/RFC8231, September 2017, 840 . 842 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 843 Computation Element Communication Protocol (PCEP) 844 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 845 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 846 . 848 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 849 Code: The Implementation Status Section", BCP 205, 850 RFC 7942, DOI 10.17487/RFC7942, July 2016, 851 . 853 [I-D.ietf-spring-segment-routing-policy] 854 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 855 P. Mattes, "Segment Routing Policy Architecture", draft- 856 ietf-spring-segment-routing-policy-09 (work in progress), 857 November 2020. 859 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 860 Dhody, D., and Y. Tanaka, "Path Computation Element 861 Communication Protocol (PCEP) Extensions for Establishing 862 Relationships between Sets of Label Switched Paths 863 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 864 . 866 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 867 and J. Hardwick, "Path Computation Element Communication 868 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 869 DOI 10.17487/RFC8664, December 2019, 870 . 872 [I-D.koldychev-pce-operational] 873 Koldychev, M., Sivabalan, S., Negi, M., Achaval, D., and 874 H. Kotni, "PCEP Operational Clarification", draft- 875 koldychev-pce-operational-02 (work in progress), August 876 2020. 878 11.2. Informative References 880 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 881 Element (PCE)-Based Architecture", RFC 4655, 882 DOI 10.17487/RFC4655, August 2006, 883 . 885 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 886 "Recommendations for Secure Use of Transport Layer 887 Security (TLS) and Datagram Transport Layer Security 888 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 889 2015, . 891 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 892 "PCEPS: Usage of TLS to Provide a Secure Transport for the 893 Path Computation Element Communication Protocol (PCEP)", 894 RFC 8253, DOI 10.17487/RFC8253, October 2017, 895 . 897 [I-D.ietf-pce-segment-routing-ipv6] 898 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 899 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 900 Routing leveraging the IPv6 data plane", draft-ietf-pce- 901 segment-routing-ipv6-08 (work in progress), November 2020. 903 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 938 Colby Barth 939 Juniper Networks, Inc. 941 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