idnits 2.17.1 draft-barth-pce-segment-routing-policy-cp-06.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 (June 2, 2020) is 1418 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-07 == 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) == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-04 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 S. Sivabalan 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: December 4, 2020 C. Barth 6 Juniper Networks, Inc. 7 S. Peng 8 Huawei Technologies 9 H. Bidgoli 10 Nokia 11 June 2, 2020 13 PCEP extension to support Segment Routing Policy Candidate Paths 14 draft-barth-pce-segment-routing-policy-cp-06 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 December 4, 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 . . . . . . . . . . . . 8 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 . . . . . . . . 11 83 5.4. SR Policy Candidate Path Name TLV . . . . . . . . . . . . 12 84 5.5. SR Policy Candidate Path Preference TLV . . . . . . . . . 12 85 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 86 6.1. PCC Initiated SR Policy with single candidate-path . . . 13 87 6.2. PCC Initiated SR Policy with multiple candidate-paths . . 13 88 6.3. PCE Initiated SR Policy with single candidate-path . . . 14 89 6.4. PCE Initiated SR Policy with multiple candidate-paths . . 15 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 91 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 15 92 7.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 16 93 7.3. SRPAG TLVs . . . . . . . . . . . . . . . . . . . . . . . 16 94 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 95 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 98 10.2. Informative References . . . . . . . . . . . . . . . . . 18 99 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 19 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 102 1. Introduction 104 Path Computation Element (PCE) Communication Protocol (PCEP) 105 [RFC5440] enables the communication between a Path Computation Client 106 (PCC) and a Path Control Element (PCE), or between two PCEs based on 107 the PCE architecture [RFC4655]. 109 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 110 of extensions to PCEP to enable active control of Multiprotocol Label 111 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 112 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 113 LSPs under the active stateful PCE model, without the need for local 114 configuration on the PCC, thus allowing for dynamic centralized 115 control of a network. 117 PCEP Extensions for Segment Routing [RFC8664] specifies extensions to 118 the Path Computation Element Protocol (PCEP) that allow a stateful 119 PCE to compute and initiate Traffic Engineering (TE) paths, as well 120 as a PCC to request a path subject to certain constraint(s) and 121 optimization criteria in SR networks. 123 PCEP Extensions for Establishing Relationships Between Sets of LSPs 124 [RFC8697] introduces a generic mechanism to create a grouping of LSPs 125 which can then be used to define associations between a set of LSPs 126 and a set of attributes (such as configuration parameters or 127 behaviors) and is equally applicable to stateful PCE (active and 128 passive modes) and stateless PCE. 130 Segment Routing Policy for Traffic Engineering 131 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 132 Policy and approaches to steering traffic into an SR Policy. 134 An SR policy contains one or more candidate paths where one or more 135 such paths can be computed via PCE. This document specifies PCEP 136 extensions to signal additional information to map candidate paths to 137 their SR policies. Each candidate path maps to a unique PLSP-ID in 138 PCEP. By associating multiple candidate paths together, a PCE 139 becomes aware of the hierarchical structure of an SR policy. Thus 140 the PCE can take computation and control decisions about the 141 candidate paths, with the additional knowledge that these candidate 142 paths belong to the same SR policy. This is accomplished via the use 143 of the existing PCEP Association object, by defining a new 144 association type specifically for associating SR candidate paths into 145 a single SR policy. 147 [Editor's Note- Currently it is assumed that each candidate path has 148 only one ERO (SID-List) within the scope of this document. Another 149 document will deal with a way to allow multiple ERO/SID-Lists for a 150 candidate path within PCEP.] 152 2. Terminology 154 The following terminologies are used in this document: 156 Endpoint: The IPv4 or IPv6 endpoint address of the SR policy in 157 question, as described in 158 [I-D.ietf-spring-segment-routing-policy]. 160 Association parameters: As described in [RFC8697], the combination 161 of the mandatory fields Association type, Association ID and 162 Association Source in the ASSOCIATION object uniquely identify the 163 association group. If the optional TLVs - Global Association 164 Source or Extended Association ID are included, then they MUST be 165 included in combination with mandatory fields to uniquely identify 166 the association group. 168 Association information: As described in [RFC8697], the ASSOCIATION 169 object could also include other optional TLVs based on the 170 association types, that provides 'information' related to the 171 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 associated SR policy. For the SR policy, the parameters are: color 192 and endpoint. For the candidate path, the parameters are: protocol 193 origin, originator, discriminator and preference. 194 [I-D.ietf-spring-segment-routing-policy] describes the concept of SR 195 Policy and these parameters. 197 The motivation for signaling these parameters is summarized in the 198 following subsections. 200 3.1. Group Candidate Paths belonging to the same SR policy 202 Since each candidate path of an SR policy appears as a different LSP 203 (identified via a PLSP-ID) in PCEP, it is useful to group together 204 all the candidate paths that belong to the same SR policy. 205 Furthermore, it is useful for the PCE to have knowledge of the SR 206 candidate path parameters such as color, protocol origin, 207 discriminator, and preference. 209 3.2. Instantiation of SR policy candidate paths 211 A PCE may want to instantiate one or more candidate paths on the PCC, 212 as specified in [RFC8281]. In this scenario, the PCE needs to signal 213 to a PCC tuple using which the PCC can instantiate a candidate 215 path for the SR policy identified. Current PCEP standards (as of the 216 time of this writing) do not provide a way to signal color and 217 preference. Although end-point can be signaled via the PCEP END- 218 POINTS object, this object may not be suitable because the end-point 219 to which the path is computed is not required to be the same IPv4/ 220 IPv6 address as the actual endpoint of the SR policy. Thus, a 221 separate way to specify SR policy's end-point is provided in this 222 document. 224 3.3. Avoid computing lower preference candidate paths 226 When a PCE knows that a given set of candidate paths all belong to 227 the same SR policy, then path computation MAY be done on only the 228 highest preference candidate-path(s). Path computation for lower 229 preference paths is not necessary if one or two higher preference 230 paths are already computed. Since computing their paths will not 231 affect traffic steering, it MAY be postponed until the higher 232 preference paths become invalid, thus saving computation resources on 233 the PCE. 235 3.4. Minimal signaling overhead 237 When an SR policy contains multiple candidate paths computed by a 238 PCE, such candidate paths can be created, updated and deleted 239 independently of each other. This is achieved by making each 240 candidate path correspond to a unique LSP (identified via PLSP-ID). 241 For example, if an SR policy has 4 candidate paths, then if the PCE 242 wants to update one of those candidate paths, only one set of PCUpd 243 and PCRpt messages needs to be exchanged. 245 4. Procedure 247 4.1. Overview 249 As per [RFC8697], LSPs are placed into an association group. As per 250 [I-D.koldychev-pce-operational], LSPs are contained in PCEP Tunnels 251 and a PCEP Tunnel is contained in an Association if all of its LSPs 252 are in that Association. 254 PCEP Tunnels naturally map to SR Candidate Paths and PCEP 255 Associations naturally map to SR Policies. Definition of these 256 mappings is the central purpose of this document. 258 The mapping between PCEP Associations and SR Policies is always one- 259 to-one. However, the mapping between PCEP Tunnels and SR Candidate 260 Paths may be either one-to-one, or many-to-one. The mapping is one- 261 to-one when the SR Candidate Path has only a single constraint and 262 optimization objective. The mapping is many-to-one when the SR 263 Candidate Path has multiple constraints and optimization objectives. 264 For more details on multiple optimization objectives and constraints, 265 see Section 4.3. 267 [Editor's Note - Segment-lists within a candidate path are not 268 represented by different PCEP Tunnels. The subject of encoding 269 multiple segment lists within a candidate path is left to another 270 document and is not specified in this document. It is not a good 271 idea to have each segment-list correspond to a different Tunnel, 272 because when the PCC wants to get a path, it must know in advance how 273 many multipaths (i.e., segment-lists) there will be and create that 274 many Tunnels. For example, if the PCC supports 32 multipaths, then 275 it must delegate 32 Tunnels for every candidate path, which may not 276 be scalable.] 278 A new Association Type is defined in this document, based on the 279 generic ASSOCIATION object. Association type = TBD1 "SR Policy 280 Association Type" for SR Policy Association Group (SRPAG). The SRPAG 281 Association is only meant to be used for SR LSPs and with PCEP peers 282 which advertise SR capability. 284 An Association object of SRPAG group contains TLVs that carry 285 Association Information. The association information can be 286 subdivided into three parts: Policy identifiers, Candidate path 287 identifiers, and Candidate path attributes. 289 Policy Identifiers uniquely identify the SR policy to which a given 290 LSP belongs, within the context of the head-end. Policy Identifiers 291 MUST be the same for all candidate paths in the same SRPAG. Policy 292 Identifiers MUST NOT change for a given LSP during its lifetime. 293 Policy Identifiers MUST be different for different SRPAG 294 associations. When these rules are not satisfied, the PCE MUST send 295 a PCErr message with Error Code = 26 "Association Error", Error Type 296 = TBD6 "Conflicting SRPAG TLV". Policy Identifiers consist of: 298 o Color of SR policy. 300 o End-point of SR policy. 302 o Optionally, the policy name. 304 Candidate Path Identifiers uniquely identify the SR candidate path 305 within the context of an SR policy. Candidate path Identifiers MUST 306 NOT change for a given LSP during its lifetime. Candidate path 307 Identifiers MUST be different for different LSPs within the same 308 SRPAG. When these rules are not satisfied, the PCE MUST send a PCErr 309 message with Error Code = 26 "Association Error", Error Type = TBD6 310 "Conflicting SRPAG TLV". Candidate path Identifiers consist of: 312 o Protocol Origin of candidate path. 314 o Originator of candidate path. 316 o Discriminator of candidate path. 318 o Optionally, the candidate path name. 320 Candidate Path Attributes MUST NOT be used to identify the candidate 321 path. Candidate path attributes carry additional information about 322 the candidate path and MAY change during the lifetime of the LSP. 323 Candidate path Attributes consist of: 325 o Preference of candidate path. 327 As per the processing rules specified in section 5.4 of [RFC8697], if 328 a PCEP speaker does not support the SRPAG association type, it MUST 329 return a PCErr message with Error-Type 26 (Early allocation by IANA) 330 "Association Error" and Error-Value 1 "Association-type is not 331 supported". Please note that the corresponding PCEP session is not 332 reset. 334 4.2. Choice of Association Parameters 336 The Association Parameters (see Section 2) uniquely identify the 337 Association. In this section, we describe how these are to be set. 339 The Association Source MUST be set to the PCC's address. This 340 applies for both PCC-initiated and PCE-initiated candidate paths. 341 The reasoning for this is that if different PCEs could set their own 342 Association Source, then the candidate paths instantiated by 343 different PCEs would by definition be in different PCEP Associations, 344 which contradicts our requirement that the SR Policy is represented 345 by an Association. 347 The Association ID MUST be chosen by the PCC when the SR policy is 348 allocated. In PCRpt messages from the PCC, the Association ID MUST 349 be set to the unique value that was allocated by the PCC at the time 350 of policy creation. In PCInit messages from the PCE, the Association 351 ID MUST be set to the reserved value 0xFFFF, which indicates that the 352 PCE is asking the PCC to choose an ID value. The PCE MUST NOT send 353 the Extended Association ID TLV in the PCInit messages. 355 If the PCC receives a PCInit message with Association Source not 356 equal to the PCCs address, or with Association ID not equal to 357 0xFFFF, or with Extended Association ID TLV present, the PCC SHOULD 358 ignore the given ASSOCIATION object. 360 4.3. Multiple Optimization Objectives and Constraints 362 In certain scenarios, it is desired for each SR Candidate Path to 363 contain multiple sub-candidate paths, each of which has a different 364 optimization objective and constraints. Traffic is then sent ECMP or 365 UCMP among these sub-candidate paths. 367 This is represented in PCEP by a many-to-one mapping between PCEP 368 Tunnels and SR Candidate Paths. This means that multiple PCEP 369 Tunnels are allocated for each SR Candidate Path. Each PCEP Tunnel 370 has its own optimization objective and constraints. When a single SR 371 Candidate Path contains multiple PCEP Tunnels, each of these PCEP 372 Tunnels MUST have identical values of Candidate Path Identifiers, as 373 encoded in SRPOLICY-CPATH-ID TLV, see Section 5.3. 375 5. SR Policy Association Group 377 Two ASSOCIATION object types for IPv4 and IPv6 are defined in 378 [RFC8697]. The ASSOCIATION object includes "Association type" 379 indicating the type of the association group. This document adds a 380 new Association type. 382 Association type = TBD1 "SR Policy Association Type" for SR Policy 383 Association Group (SRPAG). 385 This Association type is dynamic in nature and created by the PCC or 386 PCE for the candidate paths belonging to the same SR policy (as 387 described in [I-D.ietf-spring-segment-routing-policy]). These 388 associations are conveyed via PCEP messages to the PCEP peer. 389 Operator-configured Association Range MUST NOT be set for this 390 Association type and MUST be ignored. 392 SRPAG MUST carry additional TLVs to communicate Association 393 Information. This document specifies five new TLVs to carry 394 Association Information: SRPOLICY-POL-ID TLV, SRPOLICY-POL-NAME TLV, 395 SRPOLICY-CPATH-ID TLV, SRPOLICY-CPATH-NAME TLV, SRPOLICY-CPATH- 396 PREFERENCE TLV. These five TLVs encode the Policy Identifiers, SR 397 Policy name, Candidate path identifiers, candidate path name, and 398 Candidate path preference, respectively. When any of the mandatory 399 TLVs are missing from the SRPAG association object, the PCE MUST send 400 a PCErr message with Error Code = 26 "Association Error", Error Type 401 = TBD7 "Missing mandatory SRPAG TLV". 403 A given LSP MUST belong to at most one SRPAG, since a candidate path 404 cannot belong to multiple SR policies. If a PCEP speaker receives a 405 PCEP message with more than one SRPAG for an LSP, then the PCEP 406 speaker MUST send a PCErr message with Error-Type 26 "Association 407 Error" and Error-Value TBD8 "Multiple SRPAG for one LSP". If the 408 message is a PCRpt message, then the PCEP speaker MUST close the PCEP 409 connection. Closing the PCEP connection is necessary because 410 ignoring PCRpt messages may lead to inconsistent LSP DB state between 411 the two PCEP peers. 413 If the PCEP speaker receives the SRPAG association when the SR 414 capability (as per [RFC8664] or [I-D.ietf-pce-segment-routing-ipv6]) 415 was not exchanged, the PCEP speaker MUST send a PCErr message with 416 Error-Type 26 "Association Error" and Error-Value TBD9 "Use of SRPAG 417 without SR capability exchange". If the Path Setup Type (PST) of the 418 LSP in SRPAG is not set to SR or SRv6, then the PCEP speaker MUST 419 send a PCErr message with Error-Type 26 "Association Error" and 420 Error-Value TBD10 "non-SR LSP in SRPAG". 422 5.1. SR Policy Identifiers TLV 424 The SRPOLICY-POL-ID TLV is a mandatory TLV for the SRPAG Association. 425 Only one SRPOLICY-POL-ID TLV can be carried and only the first 426 occurrence is processed and any others MUST be ignored. 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Type | Length | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | Color | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 ~ End-point ~ 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 Figure 1: The SRPOLICY-POL-ID TLV format 440 Type: TBD2 for "SRPOLICY-POL-ID" TLV. 442 Length: 8 or 20, depending on length of End-point (IPv4 or IPv6) 444 Color: any unsigned 32-bit number. 446 End-point: can be either IPv4 or IPv6, depending on whether the 447 policy endpoint has IPv4 or IPv6 address. This value may be 448 different from the one contained in the END-POINTS object, or in the 449 LSP IDENTIFIERS TLV of the LSP object. Endpoint is meant to strictly 450 correspond to the endpoint of the SR policy, as it is defined in 451 [I-D.ietf-spring-segment-routing-policy]. 453 5.2. SR Policy Name TLV 455 The SRPOLICY-POL-NAME TLV is an optional TLV for the SRPAG 456 Association. At most one SRPOLICY-POL-NAME TLV can be carried and 457 only the first occurrence is processed and any others MUST be 458 ignored. 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Type | Length | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | | 466 ~ Policy Name ~ 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 2: The SRPOLICY-POL-NAME TLV format 472 Type: TBD3 for "SRPOLICY-POL-NAME" TLV. 474 Length: indicates the total length of the TLV in octets and MUST be 475 greater than 0. The TLV MUST be zero-padded so that the TLV is 476 4-octet aligned. 478 Policy Name: Policy name, as defined in 479 [I-D.ietf-spring-segment-routing-policy]. It SHOULD be a string of 480 printable ASCII characters, without a NULL terminator. 482 5.3. SR Policy Candidate Path Identifiers TLV 484 The SRPOLICY-CPATH-ID TLV is a mandatory TLV for the SRPAG 485 Association. Only one SRPOLICY-CPATH-ID TLV can be carried and only 486 the first occurrence is processed and any others MUST be ignored. 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | Type | Length | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Proto. Origin | Reserved | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 | Originator ASN | 496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 | | 498 | Originator Address | 499 | | 500 | | 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Discriminator | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 Figure 3: The SRPOLICY-CPATH-ID TLV format 507 Type: TBD4 for "SRPOLICY-CPATH-ID" TLV. 509 Length: 28. 511 Protocol Origin: 8-bit value that encodes the protocol origin, as 512 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.3. 514 Reserved: MUST be set to zero on transmission and ignored on receipt. 516 Originator ASN: Represented as 4 byte number, part of the originator 517 identifier, as specified in [I-D.ietf-spring-segment-routing-policy] 518 Section 2.4. 520 Originator Address: Represented as 128 bit value where IPv4 address 521 are encoded in lowest 32 bits, part of the originator identifier, as 522 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.4. 524 Discriminator: 32-bit value that encodes the Discriminator of the 525 candidate path. 527 5.4. SR Policy Candidate Path Name TLV 529 The SRPOLICY-CPATH-NAME TLV is an optional TLV for the SRPAG 530 Association. At most one SRPOLICY-CPATH-NAME TLV can be carried and 531 only the first occurrence is processed and any others MUST be 532 ignored. 534 0 1 2 3 535 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 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | Type | Length | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 | | 540 ~ SR Policy Candidate Path Name ~ 541 | | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Figure 4: The SRPOLICY-CPATH-NAME TLV format 546 Type: TBD11 for "SRPOLICY-CPATH-NAME" TLV. 548 Length: indicates the total length of the TLV in octets and MUST be 549 greater than 0. The TLV MUST be zero-padded so that the TLV is 550 4-octet aligned. 552 SR Policy Candidate Path Name: SR Policy Candidate Path Name, as 553 defined in [I-D.ietf-spring-segment-routing-policy]. It SHOULD be a 554 string of printable ASCII characters, without a NULL terminator. 556 5.5. SR Policy Candidate Path Preference TLV 558 The SRPOLICY-CPATH-PREFERENCE TLV is an optional TLV for the SRPAG 559 Association. Only one SRPOLICY-CPATH-PREFERENCE TLV can be carried 560 and only the first occurrence is processed and any others MUST be 561 ignored. 563 0 1 2 3 564 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 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Type | Length | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 568 | Preference | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Figure 5: The SRPOLICY-CPATH-PREFERENCE TLV format 573 Type: TBD5 for "SRPOLICY-CPATH-PREFERENCE" TLV. 575 Length: 4. 577 Preference: Numerical preference of the candidate path, as specified 578 in [I-D.ietf-spring-segment-routing-policy] Section 2.7. 580 If the TLV is missing, a default preference of 100 as specified in 581 [I-D.ietf-spring-segment-routing-policy] is used. 583 6. Examples 585 6.1. PCC Initiated SR Policy with single candidate-path 587 PCReq and PCRep messages are exchanged in the following sequence: 589 1. PCC sends PCReq message to the PCE, encoding the SRPAG 590 ASSOCIATION object and TLVs in the PCReq message. 592 2. PCE returns the path in PCRep message, and echoes back the SRPAG 593 object that was used in the computation. 595 PCRpt and PCUpd messages are exchanged in the following sequence: 597 1. PCC sends PCRpt message to the PCE, including the LSP object and 598 the SRPAG ASSOCIATION object. 600 2. PCE computes path, possibly making use of the Association 601 Information from the SRPAG ASSOCIATION object. 603 3. PCE updates the SR policy candidate path's ERO using PCUpd 604 message. 606 6.2. PCC Initiated SR Policy with multiple candidate-paths 608 PCRpt and PCUpd messages are exchanged in the following sequence: 610 1. For each candidate path of the SR Policy, the PCC generates a 611 different PLSP-ID and symbolic-name and sends multiple PCRpt 612 messages (or one message with multiple LSP objects) to the PCE. 613 Each LSP object is followed by SRPAG ASSOCIATION object with 614 identical Color and Endpoint values. The Association Source is 615 set to the IP address of the PCC and the Association ID is set to 616 a number that PCC locally chose to represent the SR Policy. 618 2. PCE takes into account that all the LSPs belong to the same SR 619 policy. PCE prioritizes computation for the highest preference 620 LSP and sends PCUpd message(s) back to the PCC. 622 3. If a new candidate path is added on the PCC by the operator, then 623 a new PLSP-ID and symbolic name is generated for that candidate 624 path and a new PCRpt is sent to the PCE. 626 4. If an existing candidate path is removed from the PCC by the 627 operator, then that PLSP-ID is deleted from the PCE by sending 628 PCRpt with the R-flag in the LSP object set. 630 6.3. PCE Initiated SR Policy with single candidate-path 632 A candidate-path is created using the following steps: 634 1. PCE sends PCInitiate message, containing the SRPAG Association 635 object. The Association Source is set to the IP address of the 636 PCC and the Association ID is set to 0xFFFF, as described in 637 Section 4.2. 639 2. PCC uses the color, endpoint and preference from the SRPAG object 640 to create a new candidate path. If no SR policy exists to hold 641 the candidate path, then a new SR policy is created to hold the 642 new candidate-path. The Originator of the candidate path is set 643 to be the address of the PCE that is sending the PCInitiate 644 message. 646 3. PCC sends a PCRpt message back to the PCE to report the newly 647 created Candidate Path. The PCRpt message contains the SRPAG 648 Association object. The Association Source is set to the IP 649 address of the PCC and the Association ID is set to a number that 650 PCC locally chose to represent the SR Policy. 652 A candidate-path is deleted using the following steps: 654 1. PCE sends PCInitiate message, setting the R-flag in the LSP 655 object. 657 2. PCC uses the PLSP-ID from the LSP object to find the candidate 658 path and delete it. If this is the last candidate path under the 659 SR policy, then the containing SR policy is deleted as well. 661 6.4. PCE Initiated SR Policy with multiple candidate-paths 663 A candidate-path is created using the following steps: 665 1. PCE sends a separate PCInitiate message for every candidate path 666 that it wants to create, or it sends multiple LSP objects within 667 a single PCInitiate message. The SRPAG Association object is 668 sent for every LSP in the PCInitiate message. The Association 669 Source is set to the IP address of the PCC and the Association ID 670 is set to 0xFFFF, as described in Section 4.2. 672 2. PCC creates multiple candidate paths under the same SR policy, 673 identified by Color and Endpoint. 675 3. PCC sends a PCRpt message back to the PCE to report the newly 676 created Candidate Path. The PCRpt message contains the SRPAG 677 Association object. The Association Source is set to the IP 678 address of the PCC and the Association ID is set to a number that 679 PCC locally chose to represent the SR Policy. 681 A candidate path is deleted using the following steps: 683 1. PCE sends PCInitiate message, setting the R-flag in the LSP 684 object. 686 2. PCC uses the PLSP-ID from the LSP object to find the candidate 687 path and delete it. 689 7. IANA Considerations 691 7.1. Association Type 693 This document defines a new association type: SR Policy Association 694 Group (SRPAG). IANA is requested to make the assignment of a new 695 value for the sub-registry "ASSOCIATION Type Field" (request to be 696 created in [RFC8697]), as follows: 698 +----------------------+-------------------------+------------------+ 699 | Association Type | Association Name | Reference | 700 | Value | | | 701 +----------------------+-------------------------+------------------+ 702 | TBD1 | SR Policy Association | This document | 703 +----------------------+-------------------------+------------------+ 705 7.2. PCEP Errors 707 This document defines five new Error-Values within the "Association 708 Error" Error-Type. IANA is requested to allocate new error values 709 within the "PCEP-ERROR Object Error Types and Values" sub-registry of 710 the PCEP Numbers registry, as follows: 712 +-------+----------+-----------------------------+------------------+ 713 | Error | Error | Meaning | Reference | 714 | Type | Value | | | 715 +-------+----------+-----------------------------+------------------+ 716 | 29 | TBD6 | Conflicting SRPAG TLV | This document | 717 +-------+----------+-----------------------------+------------------+ 718 | 29 | TBD7 | Missing mandatory SRPAG TLV | This document | 719 +-------+----------+-----------------------------+------------------+ 720 | 29 | TBD8 | Multiple SRPAG for one LSP | This document | 721 +-------+----------+-----------------------------+------------------+ 722 | 29 | TBD9 | Use of SRPAG without SR | This document | 723 | | | capability exchange | | 724 +-------+----------+-----------------------------+------------------+ 725 | 29 | TBD10 | non-SR LSP in SRPAG | This document | 726 +-------+----------+-----------------------------+------------------+ 728 7.3. SRPAG TLVs 730 This document defines five new TLVs for carrying additional 731 information about SR policy and SR candidate paths. IANA is 732 requested to make the assignment of a new value for the existing 733 "PCEP TLV Type Indicators" registry as follows: 735 +------------+-----------------------------------+------------------+ 736 | TLV Type | TLV Name | Reference | 737 | Value | | | 738 +------------+-----------------------------------+------------------+ 739 | TBD2 | SRPOLICY-POL-ID | This document | 740 +------------+-----------------------------------+------------------+ 741 | TBD3 | SRPOLICY-POL-NAME | This document | 742 +------------+-----------------------------------+------------------+ 743 | TBD4 | SRPOLICY-CPATH-ID | This document | 744 +------------+-----------------------------------+------------------+ 745 | TBD11 | SRPOLICY-CPATH-NAME | This document | 746 +------------+-----------------------------------+------------------+ 747 | TBD5 | SRPOLICY-CPATH-PREFERENCE | This document | 748 +------------+-----------------------------------+------------------+ 750 8. Security Considerations 752 This document defines one new type for association, which do not add 753 any new security concerns beyond those discussed in [RFC5440], 754 [RFC8231], [RFC8664], [I-D.ietf-pce-segment-routing-ipv6] and 755 [RFC8697] in itself. 757 The information carried in the SRPAG Association object, as per this 758 document is related to SR Policy. It often reflects information that 759 can also be derived from the SR Database, but association provides a 760 much easier grouping of related LSPs and messages. The SRPAG 761 association could provides an adversary with the opportunity to 762 eavesdrop on the relationship between the LSPs. Thus securing the 763 PCEP session using Transport Layer Security (TLS) [RFC8253], as per 764 the recommendations and best current practices in [RFC7525], is 765 RECOMMENDED. 767 9. Acknowledgement 769 10. References 771 10.1. Normative References 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, 775 DOI 10.17487/RFC2119, March 1997, 776 . 778 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 779 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 780 DOI 10.17487/RFC5440, March 2009, 781 . 783 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 784 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 785 May 2017, . 787 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 788 Computation Element Communication Protocol (PCEP) 789 Extensions for Stateful PCE", RFC 8231, 790 DOI 10.17487/RFC8231, September 2017, 791 . 793 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 794 Computation Element Communication Protocol (PCEP) 795 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 796 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 797 . 799 [I-D.ietf-spring-segment-routing-policy] 800 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 801 P. Mattes, "Segment Routing Policy Architecture", draft- 802 ietf-spring-segment-routing-policy-07 (work in progress), 803 May 2020. 805 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 806 Dhody, D., and Y. Tanaka, "Path Computation Element 807 Communication Protocol (PCEP) Extensions for Establishing 808 Relationships between Sets of Label Switched Paths 809 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 810 . 812 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 813 and J. Hardwick, "Path Computation Element Communication 814 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 815 DOI 10.17487/RFC8664, December 2019, 816 . 818 [I-D.koldychev-pce-operational] 819 Koldychev, M., Sivabalan, S., Negi, M., Achaval, D., and 820 H. Kotni, "PCEP Operational Clarification", draft- 821 koldychev-pce-operational-01 (work in progress), February 822 2020. 824 10.2. Informative References 826 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 827 Element (PCE)-Based Architecture", RFC 4655, 828 DOI 10.17487/RFC4655, August 2006, 829 . 831 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 832 "Recommendations for Secure Use of Transport Layer 833 Security (TLS) and Datagram Transport Layer Security 834 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 835 2015, . 837 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 838 "PCEPS: Usage of TLS to Provide a Secure Transport for the 839 Path Computation Element Communication Protocol (PCEP)", 840 RFC 8253, DOI 10.17487/RFC8253, October 2017, 841 . 843 [I-D.ietf-pce-segment-routing-ipv6] 844 Negi, M., Li, C., Sivabalan, S., Kaladharan, P., and Y. 845 Zhu, "PCEP Extensions for Segment Routing leveraging the 846 IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-04 847 (work in progress), March 2020. 849 Appendix A. Contributors 851 Dhruv Dhody 852 Huawei Technologies 853 Divyashree Techno Park, Whitefield 854 Bangalore, Karnataka 560066 855 India 857 Email: dhruv.ietf@gmail.com 859 Cheng Li 860 Huawei Technologies 861 Huawei Campus, No. 156 Beiqing Rd. 862 Beijing, 10095 863 China 865 Email: chengli13@huawei.com 867 Authors' Addresses 869 Mike Koldychev 870 Cisco Systems, Inc. 871 2000 Innovation Drive 872 Kanata, Ontario K2K 3E8 873 Canada 875 Email: mkoldych@cisco.com 877 Siva Sivabalan 878 Cisco Systems, Inc. 879 2000 Innovation Drive 880 Kanata, Ontario K2K 3E8 881 Canada 883 Email: msiva@cisco.com 884 Colby Barth 885 Juniper Networks, Inc. 887 Email: cbarth@juniper.net 889 Shuping Peng 890 Huawei Technologies 891 Huawei Campus, No. 156 Beiqing Rd. 892 Beijing 100095 893 China 895 Email: pengshuping@huawei.com 897 Hooman Bidgoli 898 Nokia 900 Email: hooman.bidgoli@nokia.com