idnits 2.17.1 draft-ietf-pce-multipath-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (25 October 2021) is 911 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 (-03) exists of draft-rajagopalan-pce-pcep-color-00 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-06 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-14 == Outdated reference: A later version (-07) exists of draft-koldychev-pce-operational-04 Summary: 0 errors (**), 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: 28 April 2022 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 25 October 2021 17 PCEP Extensions for Signaling Multipath Information 18 draft-ietf-pce-multipath-03 20 Abstract 22 Path computation algorithms are not limited to return a single 23 optimal path. Multiple paths may exist that satisfy the given 24 objectives and constraints. This document defines a mechanism to 25 encode multiple paths for a single set of objectives and constraints. 26 This is a generic PCEP mechanism, not specific to any path setup type 27 or dataplane. The mechanism is applicable to both stateless and 28 stateful PCEP. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 28 April 2022. 47 Copyright Notice 49 Copyright (c) 2021 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 66 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Signaling Multiple Segment-Lists of an SR 68 Candidate-Path . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Splitting of Requested Bandwidth . . . . . . . . . . . . 4 70 3.3. Providing Backup path for Protection . . . . . . . . . . 4 71 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 72 4.1. Multipath Capability TLV . . . . . . . . . . . . . . . . 5 73 4.2. Path Attributes Object . . . . . . . . . . . . . . . . . 6 74 4.3. Multipath Weight TLV . . . . . . . . . . . . . . . . . . 6 75 4.4. Multipath Backup TLV . . . . . . . . . . . . . . . . . . 7 76 4.5. Multipath Opposite Direction Path TLV . . . . . . . . . . 8 77 4.6. Composite Candidate Path . . . . . . . . . . . . . . . . 9 78 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 5.1. Signaling Multiple Paths for Loadbalancing . . . . . . . 10 80 5.2. Signaling Multiple Paths for Protection . . . . . . . . . 11 81 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 12 82 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 7.1. SR Policy Candidate-Path with Multiple Segment-Lists . . 12 84 7.2. Two Primary Paths Protected by One Backup Path . . . . . 13 85 7.3. Composite Candidate Path . . . . . . . . . . . . . . . . 14 86 7.4. Opposite Direction Tunnels . . . . . . . . . . . . . . . 15 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 8.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 17 89 8.2. PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . . 17 90 8.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 17 91 8.4. Flags in the Multipath Capability TLV . . . . . . . . . . 18 92 8.5. Flags in the Path Attribute Object . . . . . . . . . . . 18 93 8.6. Flags in the Multipath Backup TLV . . . . . . . . . . . . 18 94 8.7. Flags in the Multipath Opposite Direction Path TLV . . . 19 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 97 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 98 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 100 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 101 12.2. Informative References . . . . . . . . . . . . . . . . . 21 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 104 1. Introduction 106 Path Computation Element (PCE) Communication Protocol (PCEP) 107 [RFC5440] enables the communication between a Path Computation Client 108 (PCC) and a Path Control Element (PCE), or between two PCEs based on 109 the PCE architecture [RFC4655]. 111 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 112 of extensions to PCEP that enable active control of Multiprotocol 113 Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS 114 (GMPLS) tunnels. [RFC8281] describes the setup and teardown of PCE- 115 initiated LSPs under the active stateful PCE model, without the need 116 for local configuration on the PCC, thus allowing for dynamic 117 centralized control of a network. 119 PCEP Extensions for Segment Routing [RFC8664] specifies extensions to 120 the Path Computation Element Protocol (PCEP) that allow a stateful 121 PCE to compute and initiate Traffic Engineering (TE) paths, as well 122 as for a PCC to request a path subject to certain constraint(s) and 123 optimization criteria in SR networks. 125 Segment Routing Policy for Traffic Engineering 126 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 127 Policy and approaches to steering traffic into an SR Policy. In 128 particular, it describes the SR candidate-path as a collection of one 129 or more Segment-Lists. The current PCEP standards only allow for 130 signaling of one Segment-List per Candidate-Path. PCEP extension to 131 support Segment Routing Policy Candidate Paths 132 [I-D.ietf-pce-segment-routing-policy-cp] specifically avoids defining 133 how to signal multipath information, and states that this will be 134 defined in another document. 136 This document defines the required extensions that allow the 137 signaling of multipath information via PCEP. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 2.1. Terms and Abbreviations 149 The following terms are used in this document: 151 PCEP Tunnel: 153 The object identified by the PLSP-ID, see 154 [I-D.koldychev-pce-operational] for more details. 156 3. Motivation 158 This extension is motivated by the use-cases described below. 160 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 162 The Candidate-Path of an SR Policy is the unit of report/update in 163 PCEP, see [I-D.ietf-pce-segment-routing-policy-cp]. Each Candidate- 164 Path can contain multiple Segment-Lists and each Segment-List is 165 encoded by one ERO. However, each PCEP LSP can contain only a single 166 ERO, which prevents us from encoding multiple Segment- Lists within 167 the same SR Candidate-Path. 169 With the help of the protocol extensions defined in this document, 170 this limitation is overcome. 172 3.2. Splitting of Requested Bandwidth 174 A PCC may request a path with 80 Gbps of bandwidth, but all links in 175 the network have only 50 Gbps capacity. The PCE can return two 176 paths, that can together carry 80 Gbps. The PCC can then equally or 177 unequally split the incoming 80 Gbps of traffic among the two paths. 178 Section 4.3 introduces a new TLV that carries the path weight that 179 allows for distribution of incoming traffic on to the multiple paths. 181 3.3. Providing Backup path for Protection 183 It is desirable for the PCE to compute and signal to the PCC a backup 184 path that is used to protect a primary path within the multipaths in 185 a given LSP. 187 Note that [RFC8745] specify the Path Protection association among 188 LSPs. The use of [RFC8745] with multipath is out of scope of this 189 document and is for future study. 191 When multipath is used, a backup path may protect one or more primary 192 paths. For this reason, primary and backup path identifiers are 193 needed to indicate which backup path(s) protect which primary 194 path(s). Section 4.4 introduces a new TLV that carries the required 195 information. 197 4. Protocol Extensions 199 4.1. Multipath Capability TLV 201 We define the MULTIPATH-CAP TLV that MAY be present in the OPEN 202 object and/or the LSP object. The purpose of this TLV is two-fold: 204 1. From PCC: it tells how many multipaths per PCEP Tunnel, the PCC 205 can install in forwarding. 207 2. From PCE: it tells that the PCE supports this standard and how 208 many multipaths per PCEP Tunnel, the PCE can compute. 210 Only the first instance of this TLV can be processed, subsequent 211 instances SHOULD be ignored. 213 Section 5 specify the usage of this TLV with Open message (within the 214 OPEN object) and other PCEP messages (within the LSP object). 216 0 1 2 3 217 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 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Type | Length | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | Number of Multipaths | Flags |O|B|W| 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 Figure 1: MULTIPATH-CAP TLV format 226 Type: TBD1 for "MULTIPATH-CAP" TLV. 228 Length: 4. 230 Number of Multipaths: the maximum number of multipaths per PCEP 231 Tunnel. The value 0 indicates unlimited number. 233 W-flag: whether MULTIPATH-WEIGHT-TLV is supported. 235 B-flag: whether MULTIPATH-BACKUP-TLV is supported. 237 O-flag: whether MULTIPATH-OPPDIR-PATH-TLV is supported. 239 4.2. Path Attributes Object 241 We define the PATH-ATTRIB object that is used to carry per-path 242 information and to act as a separator between several ERO/RRO objects 243 in the / RBNF element. The PATH-ATTRIB 244 object always precedes the ERO/RRO that it applies to. If multiple 245 ERO/RRO objects are present, then each ERO/RRO object MUST be 246 preceded by an PATH-ATTRIB object that describes it. 248 The PATH-ATTRIB Object-Class value is TBD2. 250 The PATH-ATTRIB Object-Type value is 1. 252 0 1 2 3 253 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 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Flags | O | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Path ID | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 ~ Optional TLVs ~ 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 Figure 2: PATH-ATTRIB object format 264 O (Operational - 3 bits): operational state of the path, same values 265 as the identically named field in the LSP object [RFC8231]. 267 Path ID: 4-octet identifier that identifies a path (encoded in the 268 ERO/RRO) within the set of multiple paths under the PCEP LSP. Value 269 0x0 is reserved to indicate the absense of a Path ID. The value of 270 0x0 MAY be used when this Path is not being referenced by any other 271 path and the allocation of a Path ID is not necessary. 273 TLVs that may be included in the PATH-ATTRIB object are described in 274 the following sections. Other optional TLVs could be defined by 275 future documents to be included within the PATH-ATTRIB object body. 277 4.3. Multipath Weight TLV 279 We define the MULTIPATH-WEIGHT TLV that MAY be present in the PATH- 280 ATTRIB object. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type | Length | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Weight | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Figure 3: MULTIPATH-WEIGHT TLV format 292 Type: TBD3 for "MULTIPATH-WEIGHT" TLV. 294 Length: 4. 296 Weight: weight of this path within the multipath, if W-ECMP is 297 desired. The fraction of flows a specific ERO/RRO carries is derived 298 from the ratio of its weight to the sum of all other multipath ERO/ 299 RRO weights. 301 When the MULTIPATH-WEIGHT TLV is absent from the PATH-ATTRIB object, 302 or the PATH-ATTRIB object is absent from the /, then the Weight of the corresponding path is taken to be "1". 305 4.4. Multipath Backup TLV 307 This document introduces a new MULTIPATH-BACKUP TLV that is optional 308 and can be present in the PATH-ATTRIB object. 310 This TLV is used to indicate the presence of a backup path that is 311 used for protection in case of failure of the primary path. The 312 format of the MULTIPATH-BACKUP TLV is: 314 0 1 2 3 315 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 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Type | Length | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Backup Path Count | Flags |B| 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | Backup Path ID 1 | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Backup Path ID 2 | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | ... | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Backup Path ID n | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 4: MULTIPATH-BACKUP TLV format 331 Type: TBD4 for "MULTIPATH-BACKUP" TLV 333 Length: 4 + (N * 4) (where N is the Backup Path Count) 335 Backup Path Count: Number of backup path(s). 337 B: If set, indicates a pure backup path. This is a path that only 338 carries rerouted traffic after the protected path fails. If this 339 flag is not set, or if the MULTIPATH-BACKUP TLV is absent, then the 340 path is assumed to be primary that carries normal traffic. 342 Backup Path ID(s): a series of 4-octet identifier(s) that identify 343 the backup path(s) in the set that protect this primary path. 345 4.5. Multipath Opposite Direction Path TLV 347 This document introduces a new MULTIPATH-OPPDIR-PATH TLV that is 348 optional and can be present in the PATH-ATTRIB object. 350 This TLV is used to indicate whether the given path is a forward path 351 or a reverse path in its PCEP Tunnel, as well as give information 352 about the opposite-direction path(s) of the given path. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Type | Length | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | Reserved (MBZ) | Flags |L|N|R| 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Opposite Direction Path ID | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 Figure 5: MULTIPATH-OPPDIR-PATH TLV format 366 Type: TBD9 for "MULTIPATH-OPPDIR-PATH" TLV 368 Length: 16. 370 R (Reverse path): If set, indicates this path is reverse, i.e., it 371 originates on the Tunnel destination and terminates on the Tunnel 372 source (usually the PCC headend itself). Paths with this flag set 373 MUST NOT be installed into forwarding, they serve only informational 374 purposes. 376 N (Node co-routed): If set, indicates this path is node co-routed 377 with its opposite direction path, specified in this TLV. Two 378 opposite direction paths are node co-routed if they traverse the same 379 nodes, but MAY traverse different links. 381 L (Link co-routed): If set, indicates this path is link co-routed 382 with its opposite directions path, specified in this TLV. Two 383 opposite direction paths are link co-routed if they traverse the same 384 links (but in the opposite directions). 386 Opposite Direction Path ID: Identifies a path that goes in the 387 opposite direction to this path. If no such path exists, then this 388 field MUST be set to 0x0, which is reserved to indicate the absense 389 of a Path ID. 391 Multiple instances of this TLV present in the same PATH-ATTRIB object 392 indicate that there are multiple opposite-direction paths 393 corresponding to the given path. This allows for many-to-many 394 relationship among the paths of two opposite direction Tunnels. 396 Whenever path A references another path B as being the opposite- 397 direction path, then path B typically also reference path A as its 398 own opposite-direction path. 400 See Section 7.4 for an example of usage. 402 4.6. Composite Candidate Path 404 SR Policy Architecture [I-D.ietf-spring-segment-routing-policy] 405 defines the concept of a Composite Candidate Path. Unlike a Non- 406 Composite Candidate Path, which contains Segment Lists, the Composite 407 Candidate Path contains Colors of other policies. The traffic that 408 is steered into a Composite Candidate Path is split among the 409 policies that are identified by the Colors contained in the Composite 410 Candidate Path. The split can be either ECMP or UCMP by adjusting 411 the weight of each color in the Composite Candidate Path, in the same 412 manner as the weight of each Segment List in the Non-Composite 413 Candidate Path is adjusted. 415 To signal the Composite Candidate Path, we make use of the COLOR TLV, 416 defined in [I-D.draft-rajagopalan-pce-pcep-color]. For a Composite 417 Candidate Path, the COLOR TLV is included in the PATH-ATTRIB Object, 418 thus allowing each Composite Candidate Path to do ECMP/UCMP among SR 419 Policies or Tunnels identified by its constituent Colors. Only one 420 COLOR TLV SHOULD be included into the PATH-ATTRIB object. If 421 multiple COLOR TLVs are contained in the PATH-ATTRIB object, only the 422 first one MUST be processed and the others SHOULD be ignored. 424 An empty ERO object MUST be included as per the existing RBNF, i.e., 425 ERO MUST contain no sub-objects. If the head-end receives a non- 426 empty ERO, then it MUST send PCError message with Error-Type 19 427 ("Invalid Operation") and Error-Value = TBD8 ("Non-empty path"). 429 See Section 7.3 for an example of the encoding. 431 5. Operation 433 When the PCC wants to indicate to the PCE that it wants to get 434 multipaths for a PCEP Tunnel, instead of a single path, it can do (1) 435 or both (1) and (2) of the following: 437 (1) Send the MULTIPATH-CAP TLV in the OPEN object during session 438 establishment. This applies to all PCEP Tunnels on the PCC, unless 439 overridden by PCEP Tunnel specific information. 441 (2) Additionally send the MULTIPATH-CAP TLV in the LSP object for a 442 particular PCEP Tunnel in the PCRpt or PCReq message. This applies 443 to the specified PCEP Tunnel and overrides the information from the 444 OPEN object. 446 When PCE computes the path for a PCEP Tunnel, it MUST NOT return more 447 multipaths than the corresponding value of "Number of Multipaths" 448 from the MULTIPATH-CAP TLV. If this TLV is absent (from both OPEN 449 and LSP objects), then the "Number of Multipaths" is assumed to be 1. 451 If the PCE supports this standard, then it MUST include the 452 MULTIPATH-CAP TLV in the OPEN object. This tells the PCC that it can 453 report multiple ERO/RRO objects per PCEP Tunnel to this PCE. If the 454 PCE does not include the MULTIPATH-CAP TLV in the OPEN object, then 455 the PCC MUST assume that the PCE does not support this standard and 456 fall back to reporting only a single ERO/RRO. The PCE MUST NOT 457 include MULTIPATH-CAP TLV in the LSP object in any other PCEP message 458 towards the PCC and the PCC MUST ignore it if received. 460 The Path ID of each ERO/RRO MUST be unique within that LSP. If a 461 PCEP speaker detects that there are two paths with the same Path ID, 462 then the PCEP speaker SHOULD send PCError message with Error-Type = 1 463 ("Reception of an invalid object") and Error-Value = TBD5 464 ("Conflicting Path ID"). 466 5.1. Signaling Multiple Paths for Loadbalancing 468 The PATH-ATTRIB object can be used to signal multiple path(s) and 469 indicate (un)equal loadbalancing amongst the set of multipaths. In 470 this case, the PATH-ATTRIB is populated for each ERO as follows: 472 1. The PCE assigns a unique Path ID to each ERO path and populates 473 it inside the PATH-ATTRIB object. The Path ID is unique within 474 the context of a PLSP or PCEP Tunnel. 476 2. The MULTIPATH-WEIGHT TLV MAY be carried inside the PATH-ATTRIB 477 object. A weight is populated to reflect the relative loadshare 478 that is to be carried by the path. If the MULTIPATH-WEIGHT is 479 not carried inside a PATH-ATTRIB object, the default weight 1 480 MUST be assumed when computing the loadshare. 482 3. The fraction of flows carried by a specific primary path is 483 derived from the ratio of its weight to the sum of all other 484 multipath weights. 486 5.2. Signaling Multiple Paths for Protection 488 The PATH-ATTRIB object can be used to describe a set of backup 489 path(s) protecting a primary path within a PCEP Tunnel. In this 490 case, the PATH-ATTRIB is populated for each ERO as follows: 492 1. The PCE assigns a unique Path ID to each ERO path and populates 493 it inside the PATH-ATTRIB object. The Path ID is unique within 494 the context of a PLSP or PCEP Tunnel. 496 2. The MULTIPATH-BACKUP TLV MUST be added inside the PATH-ATTRIB 497 object for each ERO that is protected. The backup path ID(s) are 498 populated in the MULTIPATH-BACKUP TLV to reflect the set of 499 backup path(s) protecting the primary path. The Length field and 500 Backup Path Number in the MULTIPATH-BACKUP are updated according 501 to the number of backup path ID(s) included. 503 3. The MULTIPATH-BACKUP TLV MAY be added inside the PATH-ATTRIB 504 object for each ERO that is unprotected. In this case, 505 MULTIPATH-BACKUP does not carry any backup path IDs in the TLV. 506 If the path acts as a pure backup - i.e. the path only carries 507 rerouted traffic after the protected path(s) fail- then the B 508 flag MUST be set. 510 Note that if a given path has the B-flag set, then there MUST be some 511 other path within the same LSP that uses the given path as a backup. 512 If this condition is violated, then the PCEP speaker SHOULD send a 513 PCError message with Error-Type = 10 ("Reception of an invalid 514 object") and Error-Value = TBD6 ("No primary path for pure backup"). 516 Note that a given PCC may not support certain backup combinations, 517 such as a backup path that is itself protected by another backup 518 path, etc. If a PCC is not able to implement a requested backup 519 scenario, the PCC SHOULD send a PCError message with Error-Type = 19 520 ("Invalid Operation") and Error-Value = TBD7 ("Not supported path 521 backup"). 523 6. PCEP Message Extensions 525 The RBNF of PCReq, PCRep, PCRpt, PCUpd and PCInit messages currently 526 use a combination of and/or . As 527 specified in Section 6.1 of [RFC8231], is represented 528 by the ERO object and is represented by the RRO object: 530 ::= 532 ::= 534 In this standard, we extend these two elements to allow multiple ERO/ 535 RRO objects to be present in the /: 537 ::= (| 538 () 539 []) 541 ::= (| 542 () 543 []) 545 7. Examples 547 7.1. SR Policy Candidate-Path with Multiple Segment-Lists 549 Consider the following sample SR Policy, taken from 550 [I-D.ietf-spring-segment-routing-policy]. 552 SR policy POL1 553 Candidate-path CP1 555 Preference 200 556 Weight W1, SID-List1 557 Weight W2, SID-List2 558 Candidate-path CP2 560 Preference 100 561 Weight W3, SID-List3 562 Weight W4, SID-List4 564 As specified in [I-D.ietf-pce-segment-routing-policy-cp], CP1 and CP2 565 are signaled as separate state-report elements and each has a unique 566 PLSP-ID, assigned by the PCC. Let us assign PLSP-ID 100 to CP1 and 567 PLSP-ID 200 to CP2. 569 The state-report for CP1 can be encoded as: 571 = 572 573 574 575 > 576 577 > 578 580 The state-report for CP2 can be encoded as: 582 = 583 584 585 586 > 587 588 > 589 591 The above sample state-report elements only specify the minimum 592 mandatory objects, of course other objects like SRP, LSPA, METRIC, 593 etc., are allowed to be inserted. 595 Note that the syntax 597 > 599 , simply means that this is PATH-ATTRIB object with Path ID field set 600 to "1" and with a MULTIPATH-WEIGHT TLV carrying weight of "W1". 602 7.2. Two Primary Paths Protected by One Backup Path 604 Suppose there are 3 paths: A, B, C. Where A,B are primary and C is 605 to be used only when A or B fail. Suppose the Path IDs for A, B, C 606 are respectively 1, 2, 3. This would be encoded in a state-report 607 as: 609 = 610 611 612 613 > 614 615 > 616 617 > 618 620 Note that the syntax 622 > 624 , simply means that this is PATH-ATTRIB object with Path ID field set 625 to "1" and with a MULTIPATH-BACKUP TLV that has B-flag cleared and 626 contains a single backup path with Backup Path ID of 3. 628 7.3. Composite Candidate Path 630 Consider the following Composite Candidate Path, taken from 631 [I-D.ietf-spring-segment-routing-policy]. 633 SR policy POL100 634 Candidate-path CP1 636 Preference 200 637 Weight W1, SR policy 638 Weight W2, SR policy 640 This is signaled in PCEP as: 642 643 644 645 647 > 648 649 651 > 652 654 7.4. Opposite Direction Tunnels 656 Consider the two opposite-direction SR Policies between end-points H1 657 and E1. 659 SR policy POL1 660 Candidate-path CP1 661 Preference 200 662 Bidirectional Association = A1 663 SID-List = 664 SID-List = 665 Candidate-path CP2 666 Preference 100 667 Bidirectional Association = A2 668 SID-List = 669 SID-List = 671 SR policy POL2 672 Candidate-path CP1 673 Preference 200 674 Bidirectional Association = A1 675 SID-List = 676 SID-List = 677 Candidate-path CP2 678 Preference 100 679 Bidirectional Association = A2 680 SID-List = 682 The state-report for POL1, CP1 can be encoded as: 684 = 685 686 687 > 689 > 690 > 692 > 693 > 695 > 696 > 698 > 700 The state-report for POL1, CP2 can be encoded as: 702 = 703 704 705 > 707 > 708 > 710 > 711 > 713 > 715 The state-report for POL2, CP1 can be encoded as: 717 = 718 719 720 > 722 > 723 > 725 > 726 > 728 > 729 > 731 > 733 The state-report for POL2, CP2 can be encoded as: 735 = 736 737 738 > 740 > 741 > 743 > 744 > 746 > 748 8. IANA Considerations 749 8.1. PCEP Object 751 IANA is requested to make the assignment of a new value for the 752 existing "PCEP Objects" registry as follows: 754 +--------------+-------------+-------------------+-----------------+ 755 | Object-Class | Name | Object-Type | Reference | 756 | Value | | Value | | 757 +--------------+-------------+-------------------+-----------------+ 758 | TBD2 | PATH-ATTRIB | 1 | This document | 759 +--------------+-------------+-------------------+-----------------+ 761 8.2. PCEP TLV 763 IANA is requested to make the assignment of a new value for the 764 existing "PCEP TLV Type Indicators" registry as follows: 766 +------------+-----------------------------------+-----------------+ 767 | TLV Type | TLV Name | Reference | 768 | Value | | | 769 +------------+-----------------------------------+-----------------+ 770 | TBD1 | MULTIPATH-CAP | This document | 771 +------------+-----------------------------------+-----------------+ 772 | TBD3 | MULTIPATH-WEIGHT | This document | 773 +------------+-----------------------------------+-----------------+ 774 | TBD4 | MULTIPATH-BACKUP | This document | 775 +------------+-----------------------------------+-----------------+ 776 | TBD9 | MULTIPATH-OPPDIR-PATH | This document | 777 +------------+-----------------------------------+-----------------+ 779 8.3. PCEP-Error Object 781 IANA is requested to make the assignment of a new value for the 782 existing "PCEP-ERROR Object Error Types and Values" sub-registry of 783 the PCEP Numbers registry for the following errors: 785 +------------+-----------------------------------+-----------------+ 786 | Error-Type | Error-Value | Reference | 787 +------------+-----------------------------------+-----------------+ 788 | 10 | TBD5 - Conflicting Path ID | This document | 789 +------------+-----------------------------------+-----------------+ 790 | 10 | TBD6 - No primary path for pure | This document | 791 | | backup | | 792 +------------+-----------------------------------+-----------------+ 793 | 19 | TBD7 - Not supported path backup | This document | 794 +------------+-----------------------------------+-----------------+ 795 | 19 | TBD8 - Non-empty path | This document | 796 +------------+-----------------------------------+-----------------+ 798 8.4. Flags in the Multipath Capability TLV 800 IANA is requested to create a new sub-registry to manage the Flag 801 field of the MULTIPATH-CAP TLV, called "Flags in MULTIPATH-CAP TLV". 803 +------------+-----------------------------------+-----------------+ 804 | Bit | Description | Reference | 805 +------------+-----------------------------------+-----------------+ 806 | 0-12 | Unassigned | This document | 807 +------------+-----------------------------------+-----------------+ 808 | 13 | 0-flag: support for processing | This document | 809 | | MULTIPATH-OPPDIR-PATH TLV | | 810 +------------+-----------------------------------+-----------------+ 811 | 14 | B-flag: support for processing | This document | 812 | | MULTIPATH-BACKUP TLV | | 813 +------------+-----------------------------------+-----------------+ 814 | 15 | W-flag: support for processing | This document | 815 | | MULTIPATH-WEIGHT TLV | | 816 +------------+-----------------------------------+-----------------+ 818 8.5. Flags in the Path Attribute Object 820 IANA is requested to create a new sub-registry to manage the Flag 821 field of the PATH-ATTRIBUTE object, called "Flags in PATH-ATTRIBUTE 822 Object". 824 +------------+-----------------------------------+-----------------+ 825 | Bit | Description | Reference | 826 +------------+-----------------------------------+-----------------+ 827 | 0-12 | Unassigned | This document | 828 +------------+-----------------------------------+-----------------+ 829 | 13-15 | O-flag: Operational state | This document | 830 +------------+-----------------------------------+-----------------+ 832 8.6. Flags in the Multipath Backup TLV 834 IANA is requested to create a new sub-registry to manage the Flag 835 field of the MULTIPATH-BACKUP TLV, called "Flags in MULTIPATH-BACKUP 836 TLV". 838 +------------+-----------------------------------+-----------------+ 839 | Bit | Description | Reference | 840 +------------+-----------------------------------+-----------------+ 841 | 0-14 | Unassigned | This document | 842 +------------+-----------------------------------+-----------------+ 843 | 15 | B-flag: Pure backup | This document | 844 +------------+-----------------------------------+-----------------+ 846 8.7. Flags in the Multipath Opposite Direction Path TLV 848 IANA is requested to create a new sub-registry to manage the flag 849 fields of the MULTIPATH-OPPDIR-PATH TLV, called "Flags in the 850 MULTIPATH-OPPDIR-PATH TLV". 852 +------------+-----------------------------------+-----------------+ 853 | Bit | Description | Reference | 854 +------------+-----------------------------------+-----------------+ 855 | 0-12 | Unassigned | This document | 856 +------------+-----------------------------------+-----------------+ 857 | 13 | L-flag: Link co-routed | This document | 858 +------------+-----------------------------------+-----------------+ 859 | 14 | N-flag: Node co-routed | This document | 860 +------------+-----------------------------------+-----------------+ 861 | 15 | R-flag: Reverse path | This document | 862 +------------+-----------------------------------+-----------------+ 864 9. Security Considerations 866 None at this time. 868 10. Acknowledgement 870 Thanks to Dhruv Dhody for ideas and discussion. 872 11. Contributors 874 Andrew Stone 875 Nokia 877 Email: andrew.stone@nokia.com 879 Gyan Mishra 880 Verizon Inc. 882 Email: gyan.s.mishra@verizon.com 884 12. References 886 12.1. Normative References 888 [I-D.draft-rajagopalan-pce-pcep-color] 889 Rajagopalan, B., Beeram, V. P., Peng, S., Xiong, Q., 890 Koldychev, M., and G. Mishra, "Path Computation Element 891 Protocol(PCEP) Extension for Color", Work in Progress, 892 Internet-Draft, draft-rajagopalan-pce-pcep-color-00, 25 893 October 2021, . 896 [I-D.ietf-pce-segment-routing-policy-cp] 897 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 898 Bidgoli, "PCEP extension to support Segment Routing Policy 899 Candidate Paths", Work in Progress, Internet-Draft, draft- 900 ietf-pce-segment-routing-policy-cp-06, 22 October 2021, 901 . 904 [I-D.ietf-spring-segment-routing-policy] 905 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 906 P. Mattes, "Segment Routing Policy Architecture", Work in 907 Progress, Internet-Draft, draft-ietf-spring-segment- 908 routing-policy-14, 25 October 2021, 909 . 912 [I-D.koldychev-pce-operational] 913 Koldychev, M., Sivabalan, S., Peng, S., Achaval, D., and 914 H. Kotni, "PCEP Operational Clarification", Work in 915 Progress, Internet-Draft, draft-koldychev-pce-operational- 916 04, 19 August 2021, . 919 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 920 Requirement Levels", BCP 14, RFC 2119, 921 DOI 10.17487/RFC2119, March 1997, 922 . 924 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 925 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 926 DOI 10.17487/RFC5440, March 2009, 927 . 929 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 930 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 931 May 2017, . 933 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 934 Computation Element Communication Protocol (PCEP) 935 Extensions for Stateful PCE", RFC 8231, 936 DOI 10.17487/RFC8231, September 2017, 937 . 939 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 940 Computation Element Communication Protocol (PCEP) 941 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 942 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 943 . 945 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 946 and J. Hardwick, "Path Computation Element Communication 947 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 948 DOI 10.17487/RFC8664, December 2019, 949 . 951 12.2. Informative References 953 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 954 Computation Element (PCE)-Based Architecture", RFC 4655, 955 DOI 10.17487/RFC4655, August 2006, 956 . 958 [RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., 959 and M. Negi, "Path Computation Element Communication 960 Protocol (PCEP) Extensions for Associating Working and 961 Protection Label Switched Paths (LSPs) with Stateful PCE", 962 RFC 8745, DOI 10.17487/RFC8745, March 2020, 963 . 965 Authors' Addresses 967 Mike Koldychev 968 Cisco Systems, Inc. 970 Email: mkoldych@cisco.com 972 Siva Sivabalan 973 Ciena Corporation 975 Email: ssivabal@ciena.com 976 Tarek Saad 977 Juniper Networks, Inc. 979 Email: tsaad@juniper.net 981 Vishnu Pavan Beeram 982 Juniper Networks, Inc. 984 Email: vbeeram@juniper.net 986 Hooman Bidgoli 987 Nokia 989 Email: hooman.bidgoli@nokia.com 991 Bhupendra Yadav 992 Ciena 994 Email: byadav@ciena.com 996 Shuping Peng 997 Huawei Technologies 999 Email: pengshuping@huawei.com