idnits 2.17.1 draft-ietf-pce-segment-routing-policy-cp-00.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 24, 2020) is 1396 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-05 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: December 26, 2020 Ciena Corporation 6 C. Barth 7 Juniper Networks, Inc. 8 S. Peng 9 Huawei Technologies 10 H. Bidgoli 11 Nokia 12 June 24, 2020 14 PCEP extension to support Segment Routing Policy Candidate Paths 15 draft-ietf-pce-segment-routing-policy-cp-00 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 via an PLSP-ID. This document proposes extension 24 to PCEP to support association among candidate paths of a given SR 25 policy. The mechanism proposed in this document is applicable to 26 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 December 26, 2020. 53 Copyright Notice 55 Copyright (c) 2020 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 . . . . 8 81 5. SR Policy Association Group . . . . . . . . . . . . . . . . . 9 82 5.1. SR Policy Identifiers TLV . . . . . . . . . . . . . . . . 10 83 5.2. SR Policy Name TLV . . . . . . . . . . . . . . . . . . . 10 84 5.3. SR Policy Candidate Path Identifiers TLV . . . . . . . . 11 85 5.4. SR Policy Candidate Path Name TLV . . . . . . . . . . . . 12 86 5.5. SR Policy Candidate Path Preference TLV . . . . . . . . . 13 87 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 6.1. PCC Initiated SR Policy with single candidate-path . . . 13 89 6.2. PCC Initiated SR Policy with multiple candidate-paths . . 14 90 6.3. PCE Initiated SR Policy with single candidate-path . . . 14 91 6.4. PCE Initiated SR Policy with multiple candidate-paths . . 15 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 7.1. Association Type . . . . . . . . . . . . . . . . . . . . 15 94 7.2. PCEP Errors . . . . . . . . . . . . . . . . . . . . . . . 16 95 7.3. SRPAG TLVs . . . . . . . . . . . . . . . . . . . . . . . 16 97 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 98 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 17 99 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 100 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 101 10.2. Informative References . . . . . . . . . . . . . . . . . 18 102 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 19 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 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 Control Element (PCE), or between two PCEs based on 110 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 end-point can be signaled via the PCEP END- 221 POINTS object, this object may not be suitable because the end-point 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 end-point 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 End-point 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 (Early allocation by IANA) 333 "Association Error" and Error-Value 1 "Association-type is not 334 supported". Please note that the corresponding PCEP session is not 335 reset. 337 4.2. Choice of Association Parameters 339 The Association Parameters (see Section 2) uniquely identify the 340 Association. In this section, we describe how these are to be set. 342 The Association Source MUST be set to the PCC's address. 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 The Association ID MUST be chosen by the PCC when the SR policy is 351 allocated. In PCRpt messages from the PCC, the Association ID MUST 352 be set to the unique value that was allocated by the PCC at the time 353 of policy creation. In PCInit messages from the PCE, the Association 354 ID MUST be set to the reserved value 0xFFFF, which indicates that the 355 PCE is asking the PCC to choose an ID value. The PCE MUST NOT send 356 the Extended Association ID TLV in the PCInit messages. 358 If the PCC receives a PCInit message with Association Source not 359 equal to the PCCs address, or with Association ID not equal to 360 0xFFFF, or with Extended Association ID TLV present, the PCC SHOULD 361 ignore the given ASSOCIATION object. 363 4.3. Multiple Optimization Objectives and Constraints 365 In certain scenarios, it is desired for each SR Candidate Path to 366 contain multiple sub-candidate paths, each of which has a different 367 optimization objective and constraints. Traffic is then sent ECMP or 368 UCMP among these sub-candidate paths. 370 This is represented in PCEP by a many-to-one mapping between PCEP 371 Tunnels and SR Candidate Paths. This means that multiple PCEP 372 Tunnels are allocated for each SR Candidate Path. Each PCEP Tunnel 373 has its own optimization objective and constraints. When a single SR 374 Candidate Path contains multiple PCEP Tunnels, each of these PCEP 375 Tunnels MUST have identical values of Candidate Path Identifiers, as 376 encoded in SRPOLICY-CPATH-ID TLV, see Section 5.3. 378 5. SR Policy Association Group 380 Two ASSOCIATION object types for IPv4 and IPv6 are defined in 381 [RFC8697]. The ASSOCIATION object includes "Association type" 382 indicating the type of the association group. This document adds a 383 new Association type. 385 Association type = TBD1 "SR Policy Association Type" for SR Policy 386 Association Group (SRPAG). 388 This Association type is dynamic in nature and created by the PCC or 389 PCE for the candidate paths belonging to the same SR policy (as 390 described in [I-D.ietf-spring-segment-routing-policy]). These 391 associations are conveyed via PCEP messages to the PCEP peer. 392 Operator-configured Association Range MUST NOT be set for this 393 Association type and MUST be ignored. 395 SRPAG MUST carry additional TLVs to communicate Association 396 Information. This document specifies five new TLVs to carry 397 Association Information: SRPOLICY-POL-ID TLV, SRPOLICY-POL-NAME TLV, 398 SRPOLICY-CPATH-ID TLV, SRPOLICY-CPATH-NAME TLV, SRPOLICY-CPATH- 399 PREFERENCE TLV. These five TLVs encode the Policy Identifiers, SR 400 Policy name, Candidate path identifiers, candidate path name, and 401 Candidate path preference, respectively. When any of the mandatory 402 TLVs are missing from the SRPAG association object, the PCE MUST send 403 a PCErr message with Error Code = 26 "Association Error", Error Type 404 = TBD7 "Missing mandatory SRPAG TLV". 406 A given LSP MUST belong to at most one SRPAG, since a candidate path 407 cannot belong to multiple SR policies. If a PCEP speaker receives a 408 PCEP message with more than one SRPAG for an LSP, then the PCEP 409 speaker MUST send a PCErr message with Error-Type 26 "Association 410 Error" and Error-Value TBD8 "Multiple SRPAG for one LSP". If the 411 message is a PCRpt message, then the PCEP speaker MUST close the PCEP 412 connection. Closing the PCEP connection is necessary because 413 ignoring PCRpt messages may lead to inconsistent LSP DB state between 414 the two PCEP peers. 416 If the PCEP speaker receives the SRPAG association when the SR 417 capability (as per [RFC8664] or [I-D.ietf-pce-segment-routing-ipv6]) 418 was not exchanged, the PCEP speaker MUST send a PCErr message with 419 Error-Type 26 "Association Error" and Error-Value TBD9 "Use of SRPAG 420 without SR capability exchange". If the Path Setup Type (PST) of the 421 LSP in SRPAG is not set to SR or SRv6, then the PCEP speaker MUST 422 send a PCErr message with Error-Type 26 "Association Error" and 423 Error-Value TBD10 "non-SR LSP in SRPAG". 425 5.1. SR Policy Identifiers TLV 427 The SRPOLICY-POL-ID TLV is a mandatory TLV for the SRPAG Association. 428 Only one SRPOLICY-POL-ID TLV can be carried and only the first 429 occurrence is processed and any others MUST be ignored. 431 0 1 2 3 432 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 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Type | Length | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Color | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 ~ End-point ~ 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 Figure 1: The SRPOLICY-POL-ID TLV format 443 Type: TBD2 for "SRPOLICY-POL-ID" TLV. 445 Length: 8 or 20, depending on length of End-point (IPv4 or IPv6) 447 Color: any unsigned 32-bit number. 449 End-point: can be either IPv4 or IPv6, depending on whether the 450 policy endpoint has IPv4 or IPv6 address. This value may be 451 different from the one contained in the END-POINTS object, or in the 452 LSP IDENTIFIERS TLV of the LSP object. Endpoint is meant to strictly 453 correspond to the endpoint of the SR policy, as it is defined in 454 [I-D.ietf-spring-segment-routing-policy]. 456 5.2. 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 can be carried and 460 only the first occurrence is processed and any others MUST be 461 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: TBD3 for "SRPOLICY-POL-NAME" TLV. 477 Length: indicates the total length of the TLV in octets and MUST be 478 greater than 0. The TLV MUST be zero-padded so that the TLV is 479 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.3. 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 can be carried and only 489 the first occurrence is processed and any others MUST be ignored. 491 0 1 2 3 492 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 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | Type | Length | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 | Proto. Origin | Reserved | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 | Originator ASN | 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | | 501 | Originator Address | 502 | | 503 | | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Discriminator | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 3: The SRPOLICY-CPATH-ID TLV format 510 Type: TBD4 for "SRPOLICY-CPATH-ID" TLV. 512 Length: 28. 514 Protocol Origin: 8-bit value that encodes the protocol origin, as 515 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.3. 517 Reserved: MUST be set to zero on transmission and ignored on receipt. 519 Originator ASN: Represented as 4 byte number, part of the originator 520 identifier, as specified in [I-D.ietf-spring-segment-routing-policy] 521 Section 2.4. 523 Originator Address: Represented as 128 bit value where IPv4 address 524 are encoded in lowest 32 bits, part of the originator identifier, as 525 specified in [I-D.ietf-spring-segment-routing-policy] Section 2.4. 527 Discriminator: 32-bit value that encodes the Discriminator of the 528 candidate path. 530 5.4. SR Policy Candidate Path Name TLV 532 The SRPOLICY-CPATH-NAME TLV is an optional TLV for the SRPAG 533 Association. At most one SRPOLICY-CPATH-NAME TLV can be carried and 534 only the first occurrence is processed and any others MUST be 535 ignored. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Type | Length | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | | 543 ~ SR Policy Candidate Path Name ~ 544 | | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 4: The SRPOLICY-CPATH-NAME TLV format 549 Type: TBD11 for "SRPOLICY-CPATH-NAME" TLV. 551 Length: indicates the total length of the TLV in octets and MUST be 552 greater than 0. The TLV MUST be zero-padded so that the TLV is 553 4-octet aligned. 555 SR Policy Candidate Path Name: SR Policy Candidate Path Name, as 556 defined in [I-D.ietf-spring-segment-routing-policy]. It SHOULD be a 557 string of printable ASCII characters, without a NULL terminator. 559 5.5. SR Policy Candidate Path Preference TLV 561 The SRPOLICY-CPATH-PREFERENCE TLV is an optional TLV for the SRPAG 562 Association. Only one SRPOLICY-CPATH-PREFERENCE TLV can be carried 563 and only the first occurrence is processed and any others MUST be 564 ignored. 566 0 1 2 3 567 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 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | Type | Length | 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Preference | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 Figure 5: The SRPOLICY-CPATH-PREFERENCE TLV format 576 Type: TBD5 for "SRPOLICY-CPATH-PREFERENCE" TLV. 578 Length: 4. 580 Preference: Numerical preference of the candidate path, as specified 581 in [I-D.ietf-spring-segment-routing-policy] Section 2.7. 583 If the TLV is missing, a default preference of 100 as specified in 584 [I-D.ietf-spring-segment-routing-policy] is used. 586 6. Examples 588 6.1. PCC Initiated SR Policy with single candidate-path 590 PCReq and PCRep messages are exchanged in the following sequence: 592 1. PCC sends PCReq message to the PCE, encoding the SRPAG 593 ASSOCIATION object and TLVs in the PCReq message. 595 2. PCE returns the path in PCRep message, and echoes back the SRPAG 596 object that was used in the computation. 598 PCRpt and PCUpd messages are exchanged in the following sequence: 600 1. PCC sends PCRpt message to the PCE, including the LSP object and 601 the SRPAG ASSOCIATION object. 603 2. PCE computes path, possibly making use of the Association 604 Information from the SRPAG ASSOCIATION object. 606 3. PCE updates the SR policy candidate path's ERO using PCUpd 607 message. 609 6.2. PCC Initiated SR Policy with multiple candidate-paths 611 PCRpt and PCUpd messages are exchanged in the following sequence: 613 1. For each candidate path of the SR Policy, the PCC generates a 614 different PLSP-ID and symbolic-name and sends multiple PCRpt 615 messages (or one message with multiple LSP objects) to the PCE. 616 Each LSP object is followed by SRPAG ASSOCIATION object with 617 identical Color and Endpoint values. The Association Source is 618 set to the IP address of the PCC and the Association ID is set to 619 a number that PCC locally chose to represent the SR Policy. 621 2. PCE takes into account that all the LSPs belong to the same SR 622 policy. PCE prioritizes computation for the highest preference 623 LSP and sends PCUpd message(s) back to the PCC. 625 3. If a new candidate path is added on the PCC by the operator, then 626 a new PLSP-ID and symbolic name is generated for that candidate 627 path and a new PCRpt is sent to the PCE. 629 4. If an existing candidate path is removed from the PCC by the 630 operator, then that PLSP-ID is deleted from the PCE by sending 631 PCRpt with the R-flag in the LSP object set. 633 6.3. PCE Initiated SR Policy with single candidate-path 635 A candidate-path is created using the following steps: 637 1. PCE sends PCInitiate message, containing the SRPAG Association 638 object. The Association Source is set to the IP address of the 639 PCC and the Association ID is set to 0xFFFF, as described in 640 Section 4.2. 642 2. PCC uses the color, endpoint and preference from the SRPAG object 643 to create a new candidate path. If no SR policy exists to hold 644 the candidate path, then a new SR policy is created to hold the 645 new candidate-path. The Originator of the candidate path is set 646 to be the address of the PCE that is sending the PCInitiate 647 message. 649 3. PCC sends a PCRpt message back to the PCE to report the newly 650 created Candidate Path. The PCRpt message contains the SRPAG 651 Association object. The Association Source is set to the IP 652 address of the PCC and the Association ID is set to a number that 653 PCC locally chose to represent the SR Policy. 655 A candidate-path is deleted using the following steps: 657 1. PCE sends PCInitiate message, setting the R-flag in the LSP 658 object. 660 2. PCC uses the PLSP-ID from the LSP object to find the candidate 661 path and delete it. If this is the last candidate path under the 662 SR policy, then the containing SR policy is deleted as well. 664 6.4. PCE Initiated SR Policy with multiple candidate-paths 666 A candidate-path is created using the following steps: 668 1. PCE sends a separate PCInitiate message for every candidate path 669 that it wants to create, or it sends multiple LSP objects within 670 a single PCInitiate message. The SRPAG Association object is 671 sent for every LSP in the PCInitiate message. The Association 672 Source is set to the IP address of the PCC and the Association ID 673 is set to 0xFFFF, as described in Section 4.2. 675 2. PCC creates multiple candidate paths under the same SR policy, 676 identified by Color and Endpoint. 678 3. PCC sends a PCRpt message back to the PCE to report the newly 679 created Candidate Path. The PCRpt message contains the SRPAG 680 Association object. The Association Source is set to the IP 681 address of the PCC and the Association ID is set to a number that 682 PCC locally chose to represent the SR Policy. 684 A candidate path is deleted using the following steps: 686 1. PCE sends PCInitiate message, setting the R-flag in the LSP 687 object. 689 2. PCC uses the PLSP-ID from the LSP object to find the candidate 690 path and delete it. 692 7. IANA Considerations 694 7.1. Association Type 696 This document defines a new association type: SR Policy Association 697 Group (SRPAG). IANA is requested to make the assignment of a new 698 value for the sub-registry "ASSOCIATION Type Field" (request to be 699 created in [RFC8697]), as follows: 701 +----------------------+-------------------------+------------------+ 702 | Association Type | Association Name | Reference | 703 | Value | | | 704 +----------------------+-------------------------+------------------+ 705 | TBD1 | SR Policy Association | This document | 706 +----------------------+-------------------------+------------------+ 708 7.2. PCEP Errors 710 This document defines five new Error-Values within the "Association 711 Error" Error-Type. IANA is requested to allocate new error values 712 within the "PCEP-ERROR Object Error Types and Values" sub-registry of 713 the PCEP Numbers registry, as follows: 715 +-------+----------+-----------------------------+------------------+ 716 | Error | Error | Meaning | Reference | 717 | Type | Value | | | 718 +-------+----------+-----------------------------+------------------+ 719 | 29 | TBD6 | Conflicting SRPAG TLV | This document | 720 +-------+----------+-----------------------------+------------------+ 721 | 29 | TBD7 | Missing mandatory SRPAG TLV | This document | 722 +-------+----------+-----------------------------+------------------+ 723 | 29 | TBD8 | Multiple SRPAG for one LSP | This document | 724 +-------+----------+-----------------------------+------------------+ 725 | 29 | TBD9 | Use of SRPAG without SR | This document | 726 | | | capability exchange | | 727 +-------+----------+-----------------------------+------------------+ 728 | 29 | TBD10 | non-SR LSP in SRPAG | This document | 729 +-------+----------+-----------------------------+------------------+ 731 7.3. SRPAG TLVs 733 This document defines five new TLVs for carrying additional 734 information about SR policy and SR candidate paths. IANA is 735 requested to make the assignment of a new value for the existing 736 "PCEP TLV Type Indicators" registry as follows: 738 +------------+-----------------------------------+------------------+ 739 | TLV Type | TLV Name | Reference | 740 | Value | | | 741 +------------+-----------------------------------+------------------+ 742 | TBD2 | SRPOLICY-POL-ID | This document | 743 +------------+-----------------------------------+------------------+ 744 | TBD3 | SRPOLICY-POL-NAME | This document | 745 +------------+-----------------------------------+------------------+ 746 | TBD4 | SRPOLICY-CPATH-ID | This document | 747 +------------+-----------------------------------+------------------+ 748 | TBD11 | SRPOLICY-CPATH-NAME | This document | 749 +------------+-----------------------------------+------------------+ 750 | TBD5 | SRPOLICY-CPATH-PREFERENCE | This document | 751 +------------+-----------------------------------+------------------+ 753 8. Security Considerations 755 This document defines one new type for association, which do not add 756 any new security concerns beyond those discussed in [RFC5440], 757 [RFC8231], [RFC8664], [I-D.ietf-pce-segment-routing-ipv6] and 758 [RFC8697] in itself. 760 The information carried in the SRPAG Association object, as per this 761 document is related to SR Policy. It often reflects information that 762 can also be derived from the SR Database, but association provides a 763 much easier grouping of related LSPs and messages. The SRPAG 764 association could provides an adversary with the opportunity to 765 eavesdrop on the relationship between the LSPs. Thus securing the 766 PCEP session using Transport Layer Security (TLS) [RFC8253], as per 767 the recommendations and best current practices in [RFC7525], is 768 RECOMMENDED. 770 9. Acknowledgement 772 10. References 774 10.1. Normative References 776 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 777 Requirement Levels", BCP 14, RFC 2119, 778 DOI 10.17487/RFC2119, March 1997, 779 . 781 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 782 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 783 DOI 10.17487/RFC5440, March 2009, 784 . 786 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 787 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 788 May 2017, . 790 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 791 Computation Element Communication Protocol (PCEP) 792 Extensions for Stateful PCE", RFC 8231, 793 DOI 10.17487/RFC8231, September 2017, 794 . 796 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 797 Computation Element Communication Protocol (PCEP) 798 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 799 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 800 . 802 [I-D.ietf-spring-segment-routing-policy] 803 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 804 P. Mattes, "Segment Routing Policy Architecture", draft- 805 ietf-spring-segment-routing-policy-07 (work in progress), 806 May 2020. 808 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 809 Dhody, D., and Y. Tanaka, "Path Computation Element 810 Communication Protocol (PCEP) Extensions for Establishing 811 Relationships between Sets of Label Switched Paths 812 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 813 . 815 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 816 and J. Hardwick, "Path Computation Element Communication 817 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 818 DOI 10.17487/RFC8664, December 2019, 819 . 821 [I-D.koldychev-pce-operational] 822 Koldychev, M., Sivabalan, S., Negi, M., Achaval, D., and 823 H. Kotni, "PCEP Operational Clarification", draft- 824 koldychev-pce-operational-01 (work in progress), February 825 2020. 827 10.2. Informative References 829 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 830 Element (PCE)-Based Architecture", RFC 4655, 831 DOI 10.17487/RFC4655, August 2006, 832 . 834 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 835 "Recommendations for Secure Use of Transport Layer 836 Security (TLS) and Datagram Transport Layer Security 837 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 838 2015, . 840 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 841 "PCEPS: Usage of TLS to Provide a Secure Transport for the 842 Path Computation Element Communication Protocol (PCEP)", 843 RFC 8253, DOI 10.17487/RFC8253, October 2017, 844 . 846 [I-D.ietf-pce-segment-routing-ipv6] 847 Negi, M., Li, C., Sivabalan, S., Kaladharan, P., and Y. 848 Zhu, "PCEP Extensions for Segment Routing leveraging the 849 IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-05 850 (work in progress), June 2020. 852 Appendix A. Contributors 854 Dhruv Dhody 855 Huawei Technologies 856 Divyashree Techno Park, Whitefield 857 Bangalore, Karnataka 560066 858 India 860 Email: dhruv.ietf@gmail.com 862 Cheng Li 863 Huawei Technologies 864 Huawei Campus, No. 156 Beiqing Rd. 865 Beijing, 10095 866 China 868 Email: chengli13@huawei.com 870 Authors' Addresses 872 Mike Koldychev 873 Cisco Systems, Inc. 874 2000 Innovation Drive 875 Kanata, Ontario K2K 3E8 876 Canada 878 Email: mkoldych@cisco.com 879 Siva Sivabalan 880 Ciena Corporation 881 385 Terry Fox Dr. 882 Kanata, Ontario K2K 0L1 883 Canada 885 Email: ssivabal@ciena.com 887 Colby Barth 888 Juniper Networks, Inc. 890 Email: cbarth@juniper.net 892 Shuping Peng 893 Huawei Technologies 894 Huawei Campus, No. 156 Beiqing Rd. 895 Beijing 100095 896 China 898 Email: pengshuping@huawei.com 900 Hooman Bidgoli 901 Nokia 903 Email: hooman.bidgoli@nokia.com