idnits 2.17.1 draft-ietf-pce-multipath-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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 03, 2021) is 1088 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 (-15) exists of draft-ietf-pce-segment-routing-policy-cp-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-11 == Outdated reference: A later version (-07) exists of draft-koldychev-pce-operational-03 == Outdated reference: A later version (-06) exists of draft-peng-pce-te-constraints-05 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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: November 4, 2021 Ciena Corporation 6 T. Saad 7 V. Beeram 8 Juniper Networks, Inc. 9 H. Bidgoli 10 Nokia 11 B. Yadav 12 Ciena 13 S. Peng 14 Huawei Technologies 15 May 03, 2021 17 PCEP Extensions for Signaling Multipath Information 18 draft-ietf-pce-multipath-00 20 Abstract 22 Current PCEP standards allow only one intended and/or actual path to 23 be present in a PCEP report or update. Applications that require 24 multipath support such as SR Policy require an extension to allow 25 signaling multiple intended and/or actual paths within a single PCEP 26 message. This document introduces such an extension. Encoding of 27 multiple intended and/or actual paths is done by encoding multiple 28 Explicit Route Objects (EROs) and/or multiple Record Route Objects 29 (RROs). A special separator object is defined in this document, to 30 facilitate this. This mechanism is applicable to SR-TE and RSVP-TE 31 and is dataplane agnostic. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on November 4, 2021. 50 Copyright Notice 52 Copyright (c) 2021 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 70 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 4 72 3.2. Splitting of Requested Bandwidth . . . . . . . . . . . . 4 73 3.3. Providing Backup path for Protection . . . . . . . . . . 4 74 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 75 4.1. Multipath Capability TLV . . . . . . . . . . . . . . . . 5 76 4.2. Path Attributes Object . . . . . . . . . . . . . . . . . 6 77 4.3. Multipath Weight TLV . . . . . . . . . . . . . . . . . . 6 78 4.4. Multipath Backup TLV . . . . . . . . . . . . . . . . . . 7 79 4.5. Composite Candidate Path . . . . . . . . . . . . . . . . 8 80 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 5.1. Signaling Multiple Paths for Loadbalancing . . . . . . . 10 82 5.2. Signaling Multiple Paths for Protection . . . . . . . . . 10 83 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 11 84 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 7.1. SR Policy Candidate-Path with Multiple Segment-Lists . . 11 86 7.2. Two Primary Paths Protected by One Backup Path . . . . . 13 87 7.3. Composite Candidate Path . . . . . . . . . . . . . . . . 13 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 89 8.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 14 90 8.2. PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . . 14 91 8.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 14 92 8.4. Flags in the Multipath Capability TLV . . . . . . . . . . 15 93 8.5. Flags in the Path Attribute Object . . . . . . . . . . . 15 94 8.6. Flags in the Multipath Backup TLV . . . . . . . . . . . . 16 95 9. Security Considerations . . . . . . . . . . . . . . . . . . . 16 96 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 16 97 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 98 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 100 12.2. Informative References . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 103 1. Introduction 105 Path Computation Element (PCE) Communication Protocol (PCEP) 106 [RFC5440] enables the communication between a Path Computation Client 107 (PCC) and a Path Control Element (PCE), or between two PCEs based on 108 the PCE architecture [RFC4655]. 110 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 111 of extensions to PCEP that enable active control of Multiprotocol 112 Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS 113 (GMPLS) tunnels. [RFC8281] describes the setup and teardown of PCE- 114 initiated LSPs under the active stateful PCE model, without the need 115 for local configuration on the PCC, thus allowing for dynamic 116 centralized control of a network. 118 PCEP Extensions for Segment Routing [RFC8664] specifies extensions to 119 the Path Computation Element Protocol (PCEP) that allow a stateful 120 PCE to compute and initiate Traffic Engineering (TE) paths, as well 121 as for a PCC to request a path subject to certain constraint(s) and 122 optimization criteria in SR networks. 124 Segment Routing Policy for Traffic Engineering 125 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 126 Policy and approaches to steering traffic into an SR Policy. In 127 particular, it describes the SR candidate-path as a collection of one 128 or more Segment-Lists. The current PCEP standards only allow for 129 signaling of one Segment-List per Candidate-Path. PCEP extension to 130 support Segment Routing Policy Candidate Paths 131 [I-D.ietf-pce-segment-routing-policy-cp] specifically avoids defining 132 how to signal multipath information, and states that this will be 133 defined in another document. 135 This document defines the required extensions that allow the 136 signaling of multipath information via PCEP. 138 2. Terminology 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 2.1. Terms and Abbreviations 148 The following terms are used in this document: 150 PCEP Tunnel: 152 The object identified by the PLSP-ID, see 153 [I-D.koldychev-pce-operational] for more details. 155 3. Motivation 157 This extension is motivated by the use-cases described below. 159 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 161 The Candidate-Path of an SR Policy is the unit of report/update in 162 PCEP, see [I-D.ietf-pce-segment-routing-policy-cp]. Each Candidate- 163 Path can contain multiple Segment-Lists and each Segment-List is 164 encoded by one ERO. However, each PCEP LSP can contain only a single 165 ERO (containing multiple SR-ERO subobject), which prevents us from 166 encoding multiple Segment- Lists within the same SR Candidate-Path. 168 With the help of the protocol extensions defined in this document, 169 this limitation is overcome. 171 3.2. Splitting of Requested Bandwidth 173 A PCC may request a path with 80 Gbps of bandwidth, but all links in 174 the network have only 50 Gbps capacity. The PCE can return two 175 paths, that can together carry 80 Gbps. The PCC can then equally or 176 unequally split the incoming 80 Gbps of traffic among the two paths. 177 Section 4.3 introduces a new TLV that carries the path weight that 178 allows for distribution of incoming traffic on to the multiple paths. 180 3.3. Providing Backup path for Protection 182 It is desirable for the PCE to compute and signal to the PCC a backup 183 path that is used to protect a primary path within the multipaths in 184 a given LSP. 186 Note that [RFC8745] specify the Path Protection association among 187 LSPs. The use of [RFC8745] with multipath is out of scope of this 188 document and is for future study. 190 When multipath is used, a backup path may protect one or more primary 191 paths. For this reason, primary and backup path identifiers are 192 needed to indicate which backup path(s) protect which primary 193 path(s). Section 4.4 introduces a new TLV that carries the required 194 information. 196 4. Protocol Extensions 198 4.1. Multipath Capability TLV 200 We define the MULTIPATH-CAP TLV that MAY be present in the OPEN 201 object and/or the LSP object. The purpose of this TLV is two-fold: 203 1. From PCC: it tells how many multipaths per PCEP Tunnel, the PCC 204 can install in forwarding. 206 2. From PCE: it tells that the PCE supports this standard and how 207 many multipaths per PCEP Tunnel, the PCE can compute. 209 Only the first instance of this TLV can be processed, subsequent 210 instances SHOULD be ignored. 212 Section 5 specify the usage of this TLV with Open message (within the 213 OPEN object) and other PCEP messages (within the LSP object). 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type | Length | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Number of Multipaths | Flags |B|W| 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 1: MULTIPATH-CAP TLV format 225 Type: TBD1 for "MULTIPATH-CAP" TLV. 227 Length: 4. 229 Number of Multipaths: the maximum number of multipaths per PCEP 230 Tunnel. The value 0 indicates unlimited number. 232 Flags: Following bits are defined: 234 W-flag: whether MULTIPATH-WEIGHT-TLV is supported. 236 B-flag: whether MULTIPATH-BACKUP-TLV is supported. 238 Unassigned bits are for future use. They MUST be set to 0 on 239 transmission and MUST be ignored on receipt. 241 4.2. Path Attributes Object 243 We define the PATH-ATTRIB object that is used to carry per-path 244 information and to act as a separator between several ERO/RRO objects 245 in the / RBNF element. The PATH-ATTRIB 246 object always precedes the ERO/RRO that it applies to. If multiple 247 ERO/RRO objects are present, then each ERO/RRO object MUST be 248 preceded by an PATH-ATTRIB object that describes it. 250 The PATH-ATTRIB Object-Class value is TBD2. 252 The PATH-ATTRIB Object-Type value is 1. 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Flags | O | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Path ID | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 ~ Optional TLVs ~ 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Figure 2: PATH-ATTRIB object format 266 Flags (32-bits): Following bits are assigned - 268 O (Operational - 3 bits): operational state of the path, same 269 values as the identically named field in the LSP object {{RFC8231}}. 271 Unassigned bits are for future use. They MUST be set to 0 on 272 transmission and MUST be ignored on receipt. 274 Path ID: 4-octet identifier that identifies a path in the set of 275 multiple paths. It uniquely identifies a path (encoded in the ERO/ 276 RRO) within the set of multiple paths under the PCEP LSP. Once a 277 path changes, a new Path ID is assigned. 279 TLVs that may be included in the PATH-ATTRIB object are described in 280 the following sections. Other optional TLVs could be defined by 281 future documents to be included within the PATH-ATTRIB object body. 283 4.3. Multipath Weight TLV 285 We define the MULTIPATH-WEIGHT TLV that MAY be present in the PATH- 286 ATTRIB object. 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type | Length | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Weight | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 3: MULTIPATH-WEIGHT TLV format 298 Type: TBD3 for "MULTIPATH-WEIGHT" TLV. 300 Length: 4. 302 Weight: weight of this path within the multipath, if W-ECMP is 303 desired. The fraction of flows a specific ERO/RRO carries is derived 304 from the ratio of its weight to the sum of all other multipath ERO/ 305 RRO weights. 307 When the MULTIPATH-WEIGHT TLV is absent from the PATH-ATTRIB object, 308 or the PATH-ATTRIB object is absent from the /, then the Weight of the corresponding path is taken to be "1". 311 4.4. Multipath Backup TLV 313 This document introduces a new MULTIPATH-BACKUP TLV that is optional 314 and can be present in the PATH-ATTRIB object. 316 This TLV is used to indicate the presence of a backup path that is 317 used for protection in case of failure of the primary path. The 318 format of the MULTIPATH-BACKUP TLV is: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Backup Path Count | Flags |B| 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Backup Path ID 1 | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | Backup Path ID 2 | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | ... | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Backup Path ID n | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Figure 4: MULTIPATH-BACKUP TLV format 338 Type: TBD4 for "MULTIPATH-BACKUP" TLV 340 Length: 4 + (N * 4) (where N is the Backup Path Count) 342 Backup Path Count: Number of backup path(s). 344 Flags (16 bits): a flag field. Currently a single flag "B bit" is 345 defined. 346 Unused flags MUST be set to zero while sending and ignored on 347 receipt. 349 B: If set, indicates a pure backup path. This is a path that only 350 carries rerouted traffic after the protected path fails. If this flag 351 is not set, or if the MULTIPATH-BACKUP TLV is absent, 352 then the path is assumed to be primary that 353 carries normal traffic. 355 Backup Path ID(s): a series of 4-octet identifier(s) that identify 356 the backup path(s) in the set that protect this primary path. 358 4.5. Composite Candidate Path 360 SR Policy Architecture [I-D.ietf-spring-segment-routing-policy] 361 defines the concept of a Composite Candidate Path. Unlike a Non- 362 Composite Candidate Path, which contains Segment Lists, the Composite 363 Candidate Path contains Colors of other policies. The traffic that 364 is steered into a Composite Candidate Path is split among the 365 policies that are identified by the Colors contained in the Composite 366 Candidate Path. The split can be either ECMP or UCMP by adjusting 367 the weight of each color in the Composite Candidate Path, in the same 368 manner as the weight of each Segment List in the Non-Composite 369 Candidate Path is adjusted. 371 To signal the Composite Candidate Path, we make use of the COLOR TLV, 372 defined in [I-D.peng-pce-te-constraints]. For a Composite Candidate 373 Path, the COLOR TLV is included in the PATH-ATTRIB Object, thus 374 allowing each Composite Candidate Path to do ECMP/UCMP among SR 375 Policies or Tunnels identified by its constituent Colors. Only one 376 COLOR TLV SHOULD be included into the PATH-ATTRIB object. If 377 multiple COLOR TLVs are contained in the PATH-ATTRIB object, only the 378 first one MUST be processed and the others SHOULD be ignored. 380 An empty SR-ERO/SR-RRO object MUST be included as per the existing 381 RBNF, i.e., SR-ERO/SR-RRO MUST contain no sub-objects. If the head- 382 end receives a non-empty SR-ERO/SR-RRO, then it MUST send PCError 383 message with Error-Type 19 ("Invalid Operation") and Error-Value = 384 TBD8 ("Non-empty path"). 386 See Section 7.3 for an example of the encoding. 388 5. Operation 390 When the PCC wants to indicate to the PCE that it wants to get 391 multipaths for a PCEP Tunnel, instead of a single path, it can do (1) 392 or both (1) and (2) of the following: 394 (1) Send the MULTIPATH-CAP TLV in the OPEN object during session 395 establishment. This applies to all PCEP Tunnels on the PCC, unless 396 overridden by PCEP Tunnel specific information. 398 (2) Additionally send the MULTIPATH-CAP TLV in the LSP object for a 399 particular PCEP Tunnel in the PCRpt or PCReq message. This applies 400 to the specified PCEP Tunnel and overrides the information from the 401 OPEN object. 403 When PCE computes the path for a PCEP Tunnel, it MUST NOT return more 404 multipaths than the corresponding value of "Number of Multipaths" 405 from the MULTIPATH-CAP TLV. If this TLV is absent (from both OPEN 406 and LSP objects), then the "Number of Multipaths" is assumed to be 1. 408 If the PCE supports this standard, then it MUST include the 409 MULTIPATH-CAP TLV in the OPEN object. This tells the PCC that it can 410 report multiple ERO/RRO objects per PCEP Tunnel to this PCE. If the 411 PCE does not include the MULTIPATH-CAP TLV in the OPEN object, then 412 the PCC MUST assume that the PCE does not support this standard and 413 fall back to reporting only a single ERO/RRO. The PCE MUST NOT 414 include MULTIPATH-CAP TLV in the LSP object in any other PCEP message 415 towards the PCC and the PCC MUST ignore it if received. 417 The Path ID of each ERO/RRO MUST be unique within that LSP. If a 418 PCEP speaker detects that there are two paths with the same Path ID, 419 then the PCEP speaker SHOULD send PCError message with Error-Type = 1 420 ("Reception of an invalid object") and Error-Value = TBD5 421 ("Conflicting Path ID"). 423 5.1. Signaling Multiple Paths for Loadbalancing 425 The PATH-ATTRIB object can be used to signal multiple path(s) and 426 indicate (un)equal loadbalancing amongst the set of multipaths. In 427 this case, the PATH-ATTRIB is populated for each ERO as follows: 429 1. The PCE assigns a unique Path ID to each ERO path and populates 430 it inside the PATH-ATTRIB object. The Path ID is unique within 431 the context of a PLSP or PCEP Tunnel. 433 2. The MULTIPATH-WEIGHT TLV MAY be carried inside the PATH-ATTRIB 434 object. A weight is populated to reflect the relative loadshare 435 that is to be carried by the path. If the MULTIPATH-WEIGHT is 436 not carried inside a PATH-ATTRIB object, the default weight 1 437 MUST be assumed when computing the loadshare. 439 3. The fraction of flows carried by a specific primary path is 440 derived from the ratio of its weight to the sum of all other 441 multipath weights. 443 5.2. Signaling Multiple Paths for Protection 445 The PATH-ATTRIB object can be used to describe a set of backup 446 path(s) protecting a primary path within a PCEP Tunnel. In this 447 case, the PATH-ATTRIB is populated for each ERO as follows: 449 1. The PCE assigns a unique Path ID to each ERO path and populates 450 it inside the PATH-ATTRIB object. The Path ID is unique within 451 the context of a PLSP or PCEP Tunnel. 453 2. The MULTIPATH-BACKUP TLV MUST be added inside the PATH-ATTRIB 454 object for each ERO that is protected. The backup path ID(s) are 455 populated in the MULTIPATH-BACKUP TLV to reflect the set of 456 backup path(s) protecting the primary path. The Length field and 457 Backup Path Number in the MULTIPATH-BACKUP are updated according 458 to the number of backup path ID(s) included. 460 3. The MULTIPATH-BACKUP TLV MAY be added inside the PATH-ATTRIB 461 object for each ERO that is unprotected. In this case, 462 MULTIPATH-BACKUP does not carry any backup path IDs in the TLV. 463 If the path acts as a pure backup - i.e. the path only carries 464 rerouted traffic after the protected path(s) fail- then the B 465 flag MUST be set. 467 Note that if a given path has the B-flag set, then there MUST be some 468 other path within the same LSP that uses the given path as a backup. 469 If this condition is violated, then the PCEP speaker SHOULD send a 470 PCError message with Error-Type = 10 ("Reception of an invalid 471 object") and Error-Value = TBD6 ("No primary path for pure backup"). 473 Note that a given PCC may not support certain backup combinations, 474 such as a backup path that is itself protected by another backup 475 path, etc. If a PCC is not able to implement a requested backup 476 scenario, the PCC SHOULD send a PCError message with Error-Type = 19 477 ("Invalid Operation") and Error-Value = TBD7 ("Not supported path 478 backup"). 480 6. PCEP Message Extensions 482 The RBNF of PCReq, PCRep, PCRpt, PCUpd and PCInit messages currently 483 use a combination of and/or . As 484 specified in Section 6.1 of [RFC8231], is represented 485 by the ERO object and is represented by the RRO object: 487 ::= 489 ::= 491 In this standard, we extend these two elements to allow multiple ERO/ 492 RRO objects to be present in the /: 494 ::= (| 495 () 496 []) 498 ::= (| 499 () 500 []) 502 7. Examples 504 7.1. SR Policy Candidate-Path with Multiple Segment-Lists 506 Consider the following sample SR Policy, taken from 507 [I-D.ietf-spring-segment-routing-policy]. 509 SR policy POL1 510 Candidate-path CP1 512 Preference 200 513 Weight W1, SID-List1 514 Weight W2, SID-List2 515 Candidate-path CP2 517 Preference 100 518 Weight W3, SID-List3 519 Weight W4, SID-List4 521 As specified in [I-D.ietf-pce-segment-routing-policy-cp], CP1 and CP2 522 are signaled as separate state-report elements and each has a unique 523 PLSP-ID, assigned by the PCC. Let us assign PLSP-ID 100 to CP1 and 524 PLSP-ID 200 to CP2. 526 The state-report for CP1 can be encoded as: 528 = 529 530 531 532 > 533 534 > 535 537 The state-report for CP2 can be encoded as: 539 = 540 541 542 543 > 544 545 > 546 548 The above sample state-report elements only specify the minimum 549 mandatory objects, of course other objects like SRP, LSPA, METRIC, 550 etc., are allowed to be inserted. 552 Note that the syntax 554 > 555 , simply means that this is PATH-ATTRIB object with Path ID field set 556 to "1" and with a MULTIPATH-WEIGHT TLV carrying weight of "W1". 558 7.2. Two Primary Paths Protected by One Backup Path 560 Suppose there are 3 paths: A, B, C. Where A,B are primary and C is 561 to be used only when A or B fail. Suppose the Path IDs for A, B, C 562 are respectively 1, 2, 3. This would be encoded in a state-report 563 as: 565 = 566 567 568 569 > 570 571 > 572 573 > 574 576 Note that the syntax 578 > 580 , simply means that this is PATH-ATTRIB object with Path ID field set 581 to "1" and with a MULTIPATH-BACKUP TLV that has B-flag cleared and 582 contains a single backup path with Backup Path ID of 3. 584 7.3. Composite Candidate Path 586 Consider the following Composite Candidate Path, taken from 587 [I-D.ietf-spring-segment-routing-policy]. 589 SR policy POL100 590 Candidate-path CP1 592 Preference 200 593 Weight W1, SR policy 594 Weight W2, SR policy 596 This is signaled in PCEP as: 598 599 600 601 > 602 603 > 604 606 8. IANA Considerations 608 8.1. PCEP Object 610 IANA is requested to make the assignment of a new value for the 611 existing "PCEP Objects" registry as follows: 613 +--------------+-------------+-------------------+-----------------+ 614 | Object-Class | Name | Object-Type | Reference | 615 | Value | | Value | | 616 +--------------+-------------+-------------------+-----------------+ 617 | TBD2 | PATH-ATTRIB | 1 | This document | 618 +--------------+-------------+-------------------+-----------------+ 620 8.2. PCEP TLV 622 IANA is requested to make the assignment of a new value for the 623 existing "PCEP TLV Type Indicators" registry as follows: 625 +------------+-----------------------------------+-----------------+ 626 | TLV Type | TLV Name | Reference | 627 | Value | | | 628 +------------+-----------------------------------+-----------------+ 629 | TBD1 | MULTIPATH-CAP | This document | 630 +------------+-----------------------------------+-----------------+ 631 | TBD3 | MULTIPATH-WEIGHT | This document | 632 +------------+-----------------------------------+-----------------+ 633 | TBD4 | MULTIPATH-BACKUP | This document | 634 +------------+-----------------------------------+-----------------+ 636 8.3. PCEP-Error Object 638 IANA is requested to make the assignment of a new value for the 639 existing "PCEP-ERROR Object Error Types and Values" sub-registry of 640 the PCEP Numbers registry for the following errors: 642 +------------+-----------------------------------+-----------------+ 643 | Error-Type | Error-Value | Reference | 644 +------------+-----------------------------------+-----------------+ 645 | 10 | TBD5 - Conflicting Path ID | This document | 646 +------------+-----------------------------------+-----------------+ 647 | 10 | TBD6 - No primary path for pure | This document | 648 | | backup | | 649 +------------+-----------------------------------+-----------------+ 650 | 19 | TBD7 - Not supported path backup | This document | 651 +------------+-----------------------------------+-----------------+ 652 | 19 | TBD8 - Non-empty path | This document | 653 +------------+-----------------------------------+-----------------+ 655 8.4. Flags in the Multipath Capability TLV 657 IANA is requested to create a new sub-registry to manage the Flag 658 field of the MULTIPATH-CAP TLV, called "Flags in MULTIPATH-CAP TLV". 660 Following bits are defined: 662 +------------+-----------------------------------+-----------------+ 663 | Bit | Description | Reference | 664 +------------+-----------------------------------+-----------------+ 665 | 0-13 | Unassigned | This document | 666 +------------+-----------------------------------+-----------------+ 667 | 14 | B-flag: Backup support | This document | 668 +------------+-----------------------------------+-----------------+ 669 | 15 | W-flag: Weighted ECMP support | This document | 670 +------------+-----------------------------------+-----------------+ 672 8.5. Flags in the Path Attribute Object 674 IANA is requested to create a new sub-registry to manage the Flag 675 field of the PATH-ATTRIBUTE object, called "Flags in PATH-ATTRIBUTE 676 Object". 678 Following bits are defined: 680 +------------+-----------------------------------+-----------------+ 681 | Bit | Description | Reference | 682 +------------+-----------------------------------+-----------------+ 683 | 0-12 | Unassigned | This document | 684 +------------+-----------------------------------+-----------------+ 685 | 13-15 | O-flag: Operational state | This document | 686 +------------+-----------------------------------+-----------------+ 688 8.6. Flags in the Multipath Backup TLV 690 IANA is requested to create a new sub-registry to manage the Flag 691 field of the MULTIPATH-BACKUP TLV, called "Flags in MULTIPATH-BACKUP 692 TLV". 694 Following bits are defined: 696 +------------+-----------------------------------+-----------------+ 697 | Bit | Description | Reference | 698 +------------+-----------------------------------+-----------------+ 699 | 0-14 | Unassigned | This document | 700 +------------+-----------------------------------+-----------------+ 701 | 15 | B-flag: Pure backup | This document | 702 +------------+-----------------------------------+-----------------+ 704 9. Security Considerations 706 None at this time. 708 10. Acknowledgement 710 Thanks to Dhruv Dhody for ideas and discussion. 712 11. Contributors 714 Andrew Stone 715 Nokia 717 Email: andrew.stone@nokia.com 719 12. References 721 12.1. Normative References 723 [I-D.ietf-pce-segment-routing-policy-cp] 724 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 725 Bidgoli, "PCEP extension to support Segment Routing Policy 726 Candidate Paths", draft-ietf-pce-segment-routing-policy- 727 cp-04 (work in progress), March 2021. 729 [I-D.ietf-spring-segment-routing-policy] 730 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 731 P. Mattes, "Segment Routing Policy Architecture", draft- 732 ietf-spring-segment-routing-policy-11 (work in progress), 733 April 2021. 735 [I-D.koldychev-pce-operational] 736 Koldychev, M., Sivabalan, S., Peng, S., Achaval, D., and 737 H. Kotni, "PCEP Operational Clarification", draft- 738 koldychev-pce-operational-03 (work in progress), February 739 2021. 741 [I-D.peng-pce-te-constraints] 742 Peng, S., Xiong, Q., and F. Qin, "PCE TE Constraints for 743 Network Slicing", draft-peng-pce-te-constraints-05 (work 744 in progress), April 2021. 746 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 747 Requirement Levels", BCP 14, RFC 2119, 748 DOI 10.17487/RFC2119, March 1997, 749 . 751 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 752 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 753 DOI 10.17487/RFC5440, March 2009, 754 . 756 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 757 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 758 May 2017, . 760 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 761 Computation Element Communication Protocol (PCEP) 762 Extensions for Stateful PCE", RFC 8231, 763 DOI 10.17487/RFC8231, September 2017, 764 . 766 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 767 Computation Element Communication Protocol (PCEP) 768 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 769 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 770 . 772 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 773 and J. Hardwick, "Path Computation Element Communication 774 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 775 DOI 10.17487/RFC8664, December 2019, 776 . 778 12.2. Informative References 780 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 781 Element (PCE)-Based Architecture", RFC 4655, 782 DOI 10.17487/RFC4655, August 2006, 783 . 785 [RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., 786 and M. Negi, "Path Computation Element Communication 787 Protocol (PCEP) Extensions for Associating Working and 788 Protection Label Switched Paths (LSPs) with Stateful PCE", 789 RFC 8745, DOI 10.17487/RFC8745, March 2020, 790 . 792 Authors' Addresses 794 Mike Koldychev 795 Cisco Systems, Inc. 797 Email: mkoldych@cisco.com 799 Siva Sivabalan 800 Ciena Corporation 802 Email: ssivabal@ciena.com 804 Tarek Saad 805 Juniper Networks, Inc. 807 Email: tsaad@juniper.net 809 Vishnu Pavan Beeram 810 Juniper Networks, Inc. 812 Email: vbeeram@juniper.net 814 Hooman Bidgoli 815 Nokia 817 Email: hooman.bidgoli@nokia.com 819 Bhupendra Yadav 820 Ciena 822 Email: byadav@ciena.com 823 Shuping Peng 824 Huawei Technologies 826 Email: pengshuping@huawei.com