idnits 2.17.1 draft-ietf-pce-multipath-01.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 (27 July 2021) is 1003 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-05 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-13 == Outdated reference: A later version (-07) exists of draft-koldychev-pce-operational-03 Summary: 0 errors (**), 0 flaws (~~), 4 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 January 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 27 July 2021 17 PCEP Extensions for Signaling Multipath Information 18 draft-ietf-pce-multipath-01 20 Abstract 22 Current PCEP standards allow only one intended and/or actual path to 23 be present in a PCEP message. Applications that require multipath 24 support such as SR Policy require an extension to allow signaling 25 multiple intended and/or actual paths within a single PCEP message. 26 This document introduces such an extension. Encoding of multiple 27 intended and/or actual paths is done by encoding multiple Explicit 28 Route Objects (EROs) and/or multiple Record Route Objects (RROs). A 29 special separator object is defined in this document, to facilitate 30 this. This mechanism is applicable to SR-TE and RSVP-TE and is 31 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 28 January 2022. 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 (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 69 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Signaling Multiple Segment-Lists of an SR 71 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. Multipath Opposite Direction Path TLV . . . . . . . . . . 8 80 4.6. Composite Candidate Path . . . . . . . . . . . . . . . . 9 81 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 5.1. Signaling Multiple Paths for Loadbalancing . . . . . . . 10 83 5.2. Signaling Multiple Paths for Protection . . . . . . . . . 11 84 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 12 85 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 7.1. SR Policy Candidate-Path with Multiple Segment-Lists . . 12 87 7.2. Two Primary Paths Protected by One Backup Path . . . . . 13 88 7.3. Composite Candidate Path . . . . . . . . . . . . . . . . 14 89 7.4. Opposite Direction Tunnels . . . . . . . . . . . . . . . 15 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 91 8.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 17 92 8.2. PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . . 17 93 8.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 17 94 8.4. Flags in the Multipath Capability TLV . . . . . . . . . . 18 95 8.5. Flags in the Path Attribute Object . . . . . . . . . . . 18 96 8.6. Flags in the Multipath Backup TLV . . . . . . . . . . . . 18 97 8.7. Flags in the Multipath Opposite Direction Path TLV . . . 19 99 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 100 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 19 101 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 102 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 103 12.1. Normative References . . . . . . . . . . . . . . . . . . 19 104 12.2. Informative References . . . . . . . . . . . . . . . . . 21 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 107 1. Introduction 109 Path Computation Element (PCE) Communication Protocol (PCEP) 110 [RFC5440] enables the communication between a Path Computation Client 111 (PCC) and a Path Control Element (PCE), or between two PCEs based on 112 the PCE architecture [RFC4655]. 114 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 115 of extensions to PCEP that enable active control of Multiprotocol 116 Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS 117 (GMPLS) tunnels. [RFC8281] describes the setup and teardown of PCE- 118 initiated LSPs under the active stateful PCE model, without the need 119 for local configuration on the PCC, thus allowing for dynamic 120 centralized control of a network. 122 PCEP Extensions for Segment Routing [RFC8664] specifies extensions to 123 the Path Computation Element Protocol (PCEP) that allow a stateful 124 PCE to compute and initiate Traffic Engineering (TE) paths, as well 125 as for a PCC to request a path subject to certain constraint(s) and 126 optimization criteria in SR networks. 128 Segment Routing Policy for Traffic Engineering 129 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 130 Policy and approaches to steering traffic into an SR Policy. In 131 particular, it describes the SR candidate-path as a collection of one 132 or more Segment-Lists. The current PCEP standards only allow for 133 signaling of one Segment-List per Candidate-Path. PCEP extension to 134 support Segment Routing Policy Candidate Paths 135 [I-D.ietf-pce-segment-routing-policy-cp] specifically avoids defining 136 how to signal multipath information, and states that this will be 137 defined in another document. 139 This document defines the required extensions that allow the 140 signaling of multipath information via PCEP. 142 2. Terminology 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here. 150 2.1. Terms and Abbreviations 152 The following terms are used in this document: 154 PCEP Tunnel: 156 The object identified by the PLSP-ID, see 157 [I-D.koldychev-pce-operational] for more details. 159 3. Motivation 161 This extension is motivated by the use-cases described below. 163 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 165 The Candidate-Path of an SR Policy is the unit of report/update in 166 PCEP, see [I-D.ietf-pce-segment-routing-policy-cp]. Each Candidate- 167 Path can contain multiple Segment-Lists and each Segment-List is 168 encoded by one ERO. However, each PCEP LSP can contain only a single 169 ERO (containing multiple SR-ERO subobject), which prevents us from 170 encoding multiple Segment- Lists within the same SR Candidate-Path. 172 With the help of the protocol extensions defined in this document, 173 this limitation is overcome. 175 3.2. Splitting of Requested Bandwidth 177 A PCC may request a path with 80 Gbps of bandwidth, but all links in 178 the network have only 50 Gbps capacity. The PCE can return two 179 paths, that can together carry 80 Gbps. The PCC can then equally or 180 unequally split the incoming 80 Gbps of traffic among the two paths. 181 Section 4.3 introduces a new TLV that carries the path weight that 182 allows for distribution of incoming traffic on to the multiple paths. 184 3.3. Providing Backup path for Protection 186 It is desirable for the PCE to compute and signal to the PCC a backup 187 path that is used to protect a primary path within the multipaths in 188 a given LSP. 190 Note that [RFC8745] specify the Path Protection association among 191 LSPs. The use of [RFC8745] with multipath is out of scope of this 192 document and is for future study. 194 When multipath is used, a backup path may protect one or more primary 195 paths. For this reason, primary and backup path identifiers are 196 needed to indicate which backup path(s) protect which primary 197 path(s). Section 4.4 introduces a new TLV that carries the required 198 information. 200 4. Protocol Extensions 202 4.1. Multipath Capability TLV 204 We define the MULTIPATH-CAP TLV that MAY be present in the OPEN 205 object and/or the LSP object. The purpose of this TLV is two-fold: 207 1. From PCC: it tells how many multipaths per PCEP Tunnel, the PCC 208 can install in forwarding. 210 2. From PCE: it tells that the PCE supports this standard and how 211 many multipaths per PCEP Tunnel, the PCE can compute. 213 Only the first instance of this TLV can be processed, subsequent 214 instances SHOULD be ignored. 216 Section 5 specify the usage of this TLV with Open message (within the 217 OPEN object) and other PCEP messages (within the LSP object). 219 0 1 2 3 220 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 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Type | Length | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Number of Multipaths | Flags |O|B|W| 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 Figure 1: MULTIPATH-CAP TLV format 229 Type: TBD1 for "MULTIPATH-CAP" TLV. 231 Length: 4. 233 Number of Multipaths: the maximum number of multipaths per PCEP 234 Tunnel. The value 0 indicates unlimited number. 236 W-flag: whether MULTIPATH-WEIGHT-TLV is supported. 238 B-flag: whether MULTIPATH-BACKUP-TLV is supported. 240 O-flag: whether MULTIPATH-OPPDIR-PATH-TLV is supported. 242 4.2. Path Attributes Object 244 We define the PATH-ATTRIB object that is used to carry per-path 245 information and to act as a separator between several ERO/RRO objects 246 in the / RBNF element. The PATH-ATTRIB 247 object always precedes the ERO/RRO that it applies to. If multiple 248 ERO/RRO objects are present, then each ERO/RRO object MUST be 249 preceded by an PATH-ATTRIB object that describes it. 251 The PATH-ATTRIB Object-Class value is TBD2. 253 The PATH-ATTRIB Object-Type value is 1. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Flags | O | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Path ID | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 ~ Optional TLVs ~ 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 2: PATH-ATTRIB object format 267 O (Operational - 3 bits): operational state of the path, same values 268 as the identically named field in the LSP object [RFC8231]. 270 Path ID: 4-octet identifier that identifies a path in the set of 271 multiple paths. It uniquely identifies a path (encoded in the ERO/ 272 RRO) within the set of multiple paths under the PCEP LSP. Once a 273 path changes, a new Path ID is assigned. Value 0x0 is reserved to 274 indicate the absense of a Path ID. 276 TLVs that may be included in the PATH-ATTRIB object are described in 277 the following sections. Other optional TLVs could be defined by 278 future documents to be included within the PATH-ATTRIB object body. 280 4.3. Multipath Weight TLV 282 We define the MULTIPATH-WEIGHT TLV that MAY be present in the PATH- 283 ATTRIB object. 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Type | Length | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Weight | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Figure 3: MULTIPATH-WEIGHT TLV format 295 Type: TBD3 for "MULTIPATH-WEIGHT" TLV. 297 Length: 4. 299 Weight: weight of this path within the multipath, if W-ECMP is 300 desired. The fraction of flows a specific ERO/RRO carries is derived 301 from the ratio of its weight to the sum of all other multipath ERO/ 302 RRO weights. 304 When the MULTIPATH-WEIGHT TLV is absent from the PATH-ATTRIB object, 305 or the PATH-ATTRIB object is absent from the /, then the Weight of the corresponding path is taken to be "1". 308 4.4. Multipath Backup TLV 310 This document introduces a new MULTIPATH-BACKUP TLV that is optional 311 and can be present in the PATH-ATTRIB object. 313 This TLV is used to indicate the presence of a backup path that is 314 used for protection in case of failure of the primary path. The 315 format of the MULTIPATH-BACKUP TLV is: 317 0 1 2 3 318 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 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | Type | Length | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Backup Path Count | Flags |B| 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Backup Path ID 1 | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Backup Path ID 2 | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | ... | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | Backup Path ID n | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 4: MULTIPATH-BACKUP TLV format 334 Type: TBD4 for "MULTIPATH-BACKUP" TLV 336 Length: 4 + (N * 4) (where N is the Backup Path Count) 338 Backup Path Count: Number of backup path(s). 340 B: If set, indicates a pure backup path. This is a path that only 341 carries rerouted traffic after the protected path fails. If this 342 flag is not set, or if the MULTIPATH-BACKUP TLV is absent, then the 343 path is assumed to be primary that carries normal traffic. 345 Backup Path ID(s): a series of 4-octet identifier(s) that identify 346 the backup path(s) in the set that protect this primary path. 348 4.5. Multipath Opposite Direction Path TLV 350 This document introduces a new MULTIPATH-OPPDIR-PATH TLV that is 351 optional and can be present in the PATH-ATTRIB object. 353 This TLV is used to indicate whether the given path is a forward path 354 or a reverse path in its PCEP Tunnel, as well as give information 355 about the opposite-direction path(s) of the given path. 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Type | Length | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Reserved (MBZ) | Flags |L|N|R| 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Opposite Direction Path ID | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 Figure 5: MULTIPATH-OPPDIR-PATH TLV format 369 Type: TBD9 for "MULTIPATH-OPPDIR-PATH" TLV 371 Length: 16. 373 R (Reverse path): If set, indicates this path is reverse, i.e., it 374 originates on the Tunnel destination and terminates on the Tunnel 375 source (usually the PCC headend itself). Paths with this flag set 376 MUST NOT be installed into forwarding, they serve only informational 377 purposes. 379 N (Node co-routed): If set, indicates this path is node co-routed 380 with its opposite direction path, specified in this TLV. Two 381 opposite direction paths are node co-routed if they traverse the same 382 nodes, but MAY traverse different links. 384 L (Link co-routed): If set, indicates this path is link co-routed 385 with its opposite directions path, specified in this TLV. Two 386 opposite direction paths are link co-routed if they traverse the same 387 links (but in the opposite directions). 389 Opposite Direction Path ID: Identifies the path that goes in the 390 opposite direction to this path. If no such path exists, then this 391 field MUST be set to 0x0, which is reserved to indicate the absense 392 of a Path ID. 394 Multiple instances of this TLV present in the same PATH-ATTRIB object 395 indicate that there are multiple opposite-direction paths 396 corresponding to the given path. This allows for many-to-many 397 relationship among the paths of two opposite direction Tunnels. 399 Whenever path A references another path B as being the opposite- 400 direction path, then path B typically also reference path A as its 401 own opposite-direction path. 403 See Section 7.4 for an example of usage. 405 4.6. Composite Candidate Path 407 SR Policy Architecture [I-D.ietf-spring-segment-routing-policy] 408 defines the concept of a Composite Candidate Path. Unlike a Non- 409 Composite Candidate Path, which contains Segment Lists, the Composite 410 Candidate Path contains Colors of other policies. The traffic that 411 is steered into a Composite Candidate Path is split among the 412 policies that are identified by the Colors contained in the Composite 413 Candidate Path. The split can be either ECMP or UCMP by adjusting 414 the weight of each color in the Composite Candidate Path, in the same 415 manner as the weight of each Segment List in the Non-Composite 416 Candidate Path is adjusted. 418 To signal the Composite Candidate Path, we make use of the COLOR TLV, 419 defined in [I-D.peng-pce-te-constraints]. For a Composite Candidate 420 Path, the COLOR TLV is included in the PATH-ATTRIB Object, thus 421 allowing each Composite Candidate Path to do ECMP/UCMP among SR 422 Policies or Tunnels identified by its constituent Colors. Only one 423 COLOR TLV SHOULD be included into the PATH-ATTRIB object. If 424 multiple COLOR TLVs are contained in the PATH-ATTRIB object, only the 425 first one MUST be processed and the others SHOULD be ignored. 427 An empty SR-ERO/SR-RRO object MUST be included as per the existing 428 RBNF, i.e., SR-ERO/SR-RRO MUST contain no sub-objects. If the head- 429 end receives a non-empty SR-ERO/SR-RRO, then it MUST send PCError 430 message with Error-Type 19 ("Invalid Operation") and Error-Value = 431 TBD8 ("Non-empty path"). 433 See Section 7.3 for an example of the encoding. 435 5. Operation 437 When the PCC wants to indicate to the PCE that it wants to get 438 multipaths for a PCEP Tunnel, instead of a single path, it can do (1) 439 or both (1) and (2) of the following: 441 (1) Send the MULTIPATH-CAP TLV in the OPEN object during session 442 establishment. This applies to all PCEP Tunnels on the PCC, unless 443 overridden by PCEP Tunnel specific information. 445 (2) Additionally send the MULTIPATH-CAP TLV in the LSP object for a 446 particular PCEP Tunnel in the PCRpt or PCReq message. This applies 447 to the specified PCEP Tunnel and overrides the information from the 448 OPEN object. 450 When PCE computes the path for a PCEP Tunnel, it MUST NOT return more 451 multipaths than the corresponding value of "Number of Multipaths" 452 from the MULTIPATH-CAP TLV. If this TLV is absent (from both OPEN 453 and LSP objects), then the "Number of Multipaths" is assumed to be 1. 455 If the PCE supports this standard, then it MUST include the 456 MULTIPATH-CAP TLV in the OPEN object. This tells the PCC that it can 457 report multiple ERO/RRO objects per PCEP Tunnel to this PCE. If the 458 PCE does not include the MULTIPATH-CAP TLV in the OPEN object, then 459 the PCC MUST assume that the PCE does not support this standard and 460 fall back to reporting only a single ERO/RRO. The PCE MUST NOT 461 include MULTIPATH-CAP TLV in the LSP object in any other PCEP message 462 towards the PCC and the PCC MUST ignore it if received. 464 The Path ID of each ERO/RRO MUST be unique within that LSP. If a 465 PCEP speaker detects that there are two paths with the same Path ID, 466 then the PCEP speaker SHOULD send PCError message with Error-Type = 1 467 ("Reception of an invalid object") and Error-Value = TBD5 468 ("Conflicting Path ID"). 470 5.1. Signaling Multiple Paths for Loadbalancing 472 The PATH-ATTRIB object can be used to signal multiple path(s) and 473 indicate (un)equal loadbalancing amongst the set of multipaths. In 474 this case, the PATH-ATTRIB is populated for each ERO as follows: 476 1. The PCE assigns a unique Path ID to each ERO path and populates 477 it inside the PATH-ATTRIB object. The Path ID is unique within 478 the context of a PLSP or PCEP Tunnel. 480 2. The MULTIPATH-WEIGHT TLV MAY be carried inside the PATH-ATTRIB 481 object. A weight is populated to reflect the relative loadshare 482 that is to be carried by the path. If the MULTIPATH-WEIGHT is 483 not carried inside a PATH-ATTRIB object, the default weight 1 484 MUST be assumed when computing the loadshare. 486 3. The fraction of flows carried by a specific primary path is 487 derived from the ratio of its weight to the sum of all other 488 multipath weights. 490 5.2. Signaling Multiple Paths for Protection 492 The PATH-ATTRIB object can be used to describe a set of backup 493 path(s) protecting a primary path within a PCEP Tunnel. In this 494 case, the PATH-ATTRIB is populated for each ERO as follows: 496 1. The PCE assigns a unique Path ID to each ERO path and populates 497 it inside the PATH-ATTRIB object. The Path ID is unique within 498 the context of a PLSP or PCEP Tunnel. 500 2. The MULTIPATH-BACKUP TLV MUST be added inside the PATH-ATTRIB 501 object for each ERO that is protected. The backup path ID(s) are 502 populated in the MULTIPATH-BACKUP TLV to reflect the set of 503 backup path(s) protecting the primary path. The Length field and 504 Backup Path Number in the MULTIPATH-BACKUP are updated according 505 to the number of backup path ID(s) included. 507 3. The MULTIPATH-BACKUP TLV MAY be added inside the PATH-ATTRIB 508 object for each ERO that is unprotected. In this case, 509 MULTIPATH-BACKUP does not carry any backup path IDs in the TLV. 510 If the path acts as a pure backup - i.e. the path only carries 511 rerouted traffic after the protected path(s) fail- then the B 512 flag MUST be set. 514 Note that if a given path has the B-flag set, then there MUST be some 515 other path within the same LSP that uses the given path as a backup. 516 If this condition is violated, then the PCEP speaker SHOULD send a 517 PCError message with Error-Type = 10 ("Reception of an invalid 518 object") and Error-Value = TBD6 ("No primary path for pure backup"). 520 Note that a given PCC may not support certain backup combinations, 521 such as a backup path that is itself protected by another backup 522 path, etc. If a PCC is not able to implement a requested backup 523 scenario, the PCC SHOULD send a PCError message with Error-Type = 19 524 ("Invalid Operation") and Error-Value = TBD7 ("Not supported path 525 backup"). 527 6. PCEP Message Extensions 529 The RBNF of PCReq, PCRep, PCRpt, PCUpd and PCInit messages currently 530 use a combination of and/or . As 531 specified in Section 6.1 of [RFC8231], is represented 532 by the ERO object and is represented by the RRO object: 534 ::= 536 ::= 538 In this standard, we extend these two elements to allow multiple ERO/ 539 RRO objects to be present in the /: 541 ::= (| 542 () 543 []) 545 ::= (| 546 () 547 []) 549 7. Examples 551 7.1. SR Policy Candidate-Path with Multiple Segment-Lists 553 Consider the following sample SR Policy, taken from 554 [I-D.ietf-spring-segment-routing-policy]. 556 SR policy POL1 557 Candidate-path CP1 559 Preference 200 560 Weight W1, SID-List1 561 Weight W2, SID-List2 562 Candidate-path CP2 564 Preference 100 565 Weight W3, SID-List3 566 Weight W4, SID-List4 568 As specified in [I-D.ietf-pce-segment-routing-policy-cp], CP1 and CP2 569 are signaled as separate state-report elements and each has a unique 570 PLSP-ID, assigned by the PCC. Let us assign PLSP-ID 100 to CP1 and 571 PLSP-ID 200 to CP2. 573 The state-report for CP1 can be encoded as: 575 = 576 577 578 579 > 580 581 > 582 584 The state-report for CP2 can be encoded as: 586 = 587 588 589 590 > 591 592 > 593 595 The above sample state-report elements only specify the minimum 596 mandatory objects, of course other objects like SRP, LSPA, METRIC, 597 etc., are allowed to be inserted. 599 Note that the syntax 601 > 603 , simply means that this is PATH-ATTRIB object with Path ID field set 604 to "1" and with a MULTIPATH-WEIGHT TLV carrying weight of "W1". 606 7.2. Two Primary Paths Protected by One Backup Path 608 Suppose there are 3 paths: A, B, C. Where A,B are primary and C is 609 to be used only when A or B fail. Suppose the Path IDs for A, B, C 610 are respectively 1, 2, 3. This would be encoded in a state-report 611 as: 613 = 614 615 616 617 > 618 619 > 620 621 > 622 624 Note that the syntax 626 > 628 , simply means that this is PATH-ATTRIB object with Path ID field set 629 to "1" and with a MULTIPATH-BACKUP TLV that has B-flag cleared and 630 contains a single backup path with Backup Path ID of 3. 632 7.3. Composite Candidate Path 634 Consider the following Composite Candidate Path, taken from 635 [I-D.ietf-spring-segment-routing-policy]. 637 SR policy POL100 638 Candidate-path CP1 640 Preference 200 641 Weight W1, SR policy 642 Weight W2, SR policy 644 This is signaled in PCEP as: 646 647 648 649 651 > 652 653 655 > 656 658 7.4. Opposite Direction Tunnels 660 Consider the two opposite-direction SR Policies between end-points H1 661 and E1. 663 SR policy POL1 664 Candidate-path CP1 665 Preference 200 666 Bidirectional Association = A1 667 SID-List = 668 SID-List = 669 Candidate-path CP2 670 Preference 100 671 Bidirectional Association = A2 672 SID-List = 673 SID-List = 675 SR policy POL2 676 Candidate-path CP1 677 Preference 200 678 Bidirectional Association = A1 679 SID-List = 680 SID-List = 681 Candidate-path CP2 682 Preference 100 683 Bidirectional Association = A2 684 SID-List = 686 The state-report for POL1, CP1 can be encoded as: 688 = 689 690 691 > 693 > 694 > 696 > 697 > 699 > 700 > 702 > 704 The state-report for POL1, CP2 can be encoded as: 706 = 707 708 709 > 711 > 712 > 714 > 715 > 717 > 719 The state-report for POL2, CP1 can be encoded as: 721 = 722 723 724 > 726 > 727 > 729 > 730 > 732 > 733 > 735 > 737 The state-report for POL2, CP2 can be encoded as: 739 = 740 741 742 > 744 > 745 > 747 > 748 > 750 > 752 8. IANA Considerations 753 8.1. PCEP Object 755 IANA is requested to make the assignment of a new value for the 756 existing "PCEP Objects" registry as follows: 758 +--------------+-------------+-------------------+-----------------+ 759 | Object-Class | Name | Object-Type | Reference | 760 | Value | | Value | | 761 +--------------+-------------+-------------------+-----------------+ 762 | TBD2 | PATH-ATTRIB | 1 | This document | 763 +--------------+-------------+-------------------+-----------------+ 765 8.2. PCEP TLV 767 IANA is requested to make the assignment of a new value for the 768 existing "PCEP TLV Type Indicators" registry as follows: 770 +------------+-----------------------------------+-----------------+ 771 | TLV Type | TLV Name | Reference | 772 | Value | | | 773 +------------+-----------------------------------+-----------------+ 774 | TBD1 | MULTIPATH-CAP | This document | 775 +------------+-----------------------------------+-----------------+ 776 | TBD3 | MULTIPATH-WEIGHT | This document | 777 +------------+-----------------------------------+-----------------+ 778 | TBD4 | MULTIPATH-BACKUP | This document | 779 +------------+-----------------------------------+-----------------+ 780 | TBD9 | MULTIPATH-OPPDIR-PATH | This document | 781 +------------+-----------------------------------+-----------------+ 783 8.3. PCEP-Error Object 785 IANA is requested to make the assignment of a new value for the 786 existing "PCEP-ERROR Object Error Types and Values" sub-registry of 787 the PCEP Numbers registry for the following errors: 789 +------------+-----------------------------------+-----------------+ 790 | Error-Type | Error-Value | Reference | 791 +------------+-----------------------------------+-----------------+ 792 | 10 | TBD5 - Conflicting Path ID | This document | 793 +------------+-----------------------------------+-----------------+ 794 | 10 | TBD6 - No primary path for pure | This document | 795 | | backup | | 796 +------------+-----------------------------------+-----------------+ 797 | 19 | TBD7 - Not supported path backup | This document | 798 +------------+-----------------------------------+-----------------+ 799 | 19 | TBD8 - Non-empty path | This document | 800 +------------+-----------------------------------+-----------------+ 802 8.4. Flags in the Multipath Capability TLV 804 IANA is requested to create a new sub-registry to manage the Flag 805 field of the MULTIPATH-CAP TLV, called "Flags in MULTIPATH-CAP TLV". 807 +------------+-----------------------------------+-----------------+ 808 | Bit | Description | Reference | 809 +------------+-----------------------------------+-----------------+ 810 | 0-12 | Unassigned | This document | 811 +------------+-----------------------------------+-----------------+ 812 | 13 | 0-flag: support for processing | This document | 813 | | MULTIPATH-OPPDIR-PATH TLV | | 814 +------------+-----------------------------------+-----------------+ 815 | 14 | B-flag: support for processing | This document | 816 | | MULTIPATH-BACKUP TLV | | 817 +------------+-----------------------------------+-----------------+ 818 | 15 | W-flag: support for processing | This document | 819 | | MULTIPATH-WEIGHT TLV | | 820 +------------+-----------------------------------+-----------------+ 822 8.5. Flags in the Path Attribute Object 824 IANA is requested to create a new sub-registry to manage the Flag 825 field of the PATH-ATTRIBUTE object, called "Flags in PATH-ATTRIBUTE 826 Object". 828 +------------+-----------------------------------+-----------------+ 829 | Bit | Description | Reference | 830 +------------+-----------------------------------+-----------------+ 831 | 0-12 | Unassigned | This document | 832 +------------+-----------------------------------+-----------------+ 833 | 13-15 | O-flag: Operational state | This document | 834 +------------+-----------------------------------+-----------------+ 836 8.6. Flags in the Multipath Backup TLV 838 IANA is requested to create a new sub-registry to manage the Flag 839 field of the MULTIPATH-BACKUP TLV, called "Flags in MULTIPATH-BACKUP 840 TLV". 842 +------------+-----------------------------------+-----------------+ 843 | Bit | Description | Reference | 844 +------------+-----------------------------------+-----------------+ 845 | 0-14 | Unassigned | This document | 846 +------------+-----------------------------------+-----------------+ 847 | 15 | B-flag: Pure backup | This document | 848 +------------+-----------------------------------+-----------------+ 850 8.7. Flags in the Multipath Opposite Direction Path TLV 852 IANA is requested to create a new sub-registry to manage the flag 853 fields of the MULTIPATH-OPPDIR-PATH TLV, called "Flags in the 854 MULTIPATH-OPPDIR-PATH TLV". 856 +------------+-----------------------------------+-----------------+ 857 | Bit | Description | Reference | 858 +------------+-----------------------------------+-----------------+ 859 | 0-12 | Unassigned | This document | 860 +------------+-----------------------------------+-----------------+ 861 | 13 | L-flag: Link co-routed | This document | 862 +------------+-----------------------------------+-----------------+ 863 | 14 | N-flag: Node co-routed | This document | 864 +------------+-----------------------------------+-----------------+ 865 | 15 | R-flag: Reverse path | This document | 866 +------------+-----------------------------------+-----------------+ 868 9. Security Considerations 870 None at this time. 872 10. Acknowledgement 874 Thanks to Dhruv Dhody for ideas and discussion. 876 11. Contributors 878 Andrew Stone 879 Nokia 881 Email: andrew.stone@nokia.com 883 12. References 885 12.1. Normative References 887 [I-D.ietf-pce-segment-routing-policy-cp] 888 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 889 Bidgoli, "PCEP extension to support Segment Routing Policy 890 Candidate Paths", Work in Progress, Internet-Draft, draft- 891 ietf-pce-segment-routing-policy-cp-05, 23 May 2021, 892 . 895 [I-D.ietf-spring-segment-routing-policy] 896 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 897 P. Mattes, "Segment Routing Policy Architecture", Work in 898 Progress, Internet-Draft, draft-ietf-spring-segment- 899 routing-policy-13, 28 May 2021, 900 . 903 [I-D.koldychev-pce-operational] 904 Koldychev, M., Sivabalan, S., Peng, S., Achaval, D., and 905 H. Kotni, "PCEP Operational Clarification", Work in 906 Progress, Internet-Draft, draft-koldychev-pce-operational- 907 03, 19 February 2021, . 910 [I-D.peng-pce-te-constraints] 911 Peng, S., Xiong, Q., Qin, F., Koldychev, M., and S. 912 Sivabalan, "PCE TE Constraints", Work in Progress, 913 Internet-Draft, draft-peng-pce-te-constraints-06, 11 July 914 2021, . 917 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 918 Requirement Levels", BCP 14, RFC 2119, 919 DOI 10.17487/RFC2119, March 1997, 920 . 922 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 923 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 924 DOI 10.17487/RFC5440, March 2009, 925 . 927 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 928 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 929 May 2017, . 931 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 932 Computation Element Communication Protocol (PCEP) 933 Extensions for Stateful PCE", RFC 8231, 934 DOI 10.17487/RFC8231, September 2017, 935 . 937 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 938 Computation Element Communication Protocol (PCEP) 939 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 940 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 941 . 943 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 944 and J. Hardwick, "Path Computation Element Communication 945 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 946 DOI 10.17487/RFC8664, December 2019, 947 . 949 12.2. Informative References 951 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 952 Computation Element (PCE)-Based Architecture", RFC 4655, 953 DOI 10.17487/RFC4655, August 2006, 954 . 956 [RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., 957 and M. Negi, "Path Computation Element Communication 958 Protocol (PCEP) Extensions for Associating Working and 959 Protection Label Switched Paths (LSPs) with Stateful PCE", 960 RFC 8745, DOI 10.17487/RFC8745, March 2020, 961 . 963 Authors' Addresses 965 Mike Koldychev 966 Cisco Systems, Inc. 968 Email: mkoldych@cisco.com 970 Siva Sivabalan 971 Ciena Corporation 973 Email: ssivabal@ciena.com 975 Tarek Saad 976 Juniper Networks, Inc. 978 Email: tsaad@juniper.net 980 Vishnu Pavan Beeram 981 Juniper Networks, Inc. 983 Email: vbeeram@juniper.net 984 Hooman Bidgoli 985 Nokia 987 Email: hooman.bidgoli@nokia.com 989 Bhupendra Yadav 990 Ciena 992 Email: byadav@ciena.com 994 Shuping Peng 995 Huawei Technologies 997 Email: pengshuping@huawei.com