idnits 2.17.1 draft-ietf-pce-multipath-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (12 May 2022) is 715 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-01 == Outdated reference: A later version (-15) exists of draft-ietf-pce-segment-routing-policy-cp-07 == Outdated reference: A later version (-07) exists of draft-koldychev-pce-operational-05 ** Downref: Normative reference to an Informational draft: draft-schmutzer-pce-cs-sr-policy (ref. 'I-D.schmutzer-pce-cs-sr-policy') Summary: 1 error (**), 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: 13 November 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 G. Mishra 16 Verizon Inc. 17 12 May 2022 19 PCEP Extensions for Signaling Multipath Information 20 draft-ietf-pce-multipath-06 22 Abstract 24 Path computation algorithms are not limited to return a single 25 optimal path. Multiple paths may exist that satisfy the given 26 objectives and constraints. This document defines a mechanism to 27 encode multiple paths for a single set of objectives and constraints. 28 This is a generic PCEP mechanism, not specific to any path setup type 29 or dataplane. The mechanism is applicable to both stateless and 30 stateful PCEP. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 13 November 2022. 49 Copyright Notice 51 Copyright (c) 2022 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Revised BSD License text as 60 described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Revised BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 4 68 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Signaling Multiple Segment-Lists of an SR 70 Candidate-Path . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Splitting of Requested Bandwidth . . . . . . . . . . . . 4 72 3.3. Providing Backup path for Protection . . . . . . . . . . 5 73 3.4. Reverse Path Information . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . 7 78 4.4. Multipath Backup TLV . . . . . . . . . . . . . . . . . . 7 79 4.5. Multipath Opposite Direction Path TLV . . . . . . . . . . 8 80 4.6. Composite Candidate Path . . . . . . . . . . . . . . . . 10 81 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 5.1. Capability Negotiation . . . . . . . . . . . . . . . . . 10 83 5.2. Path ID . . . . . . . . . . . . . . . . . . . . . . . . . 11 84 5.3. Signaling Multiple Paths for Loadbalancing . . . . . . . 11 85 5.4. Signaling Multiple Paths for Protection . . . . . . . . . 12 86 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 13 87 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 7.1. SR Policy Candidate-Path with Multiple Segment-Lists . . 13 89 7.2. Two Primary Paths Protected by One Backup Path . . . . . 14 90 7.3. Composite Candidate Path . . . . . . . . . . . . . . . . 15 91 7.4. Opposite Direction Tunnels . . . . . . . . . . . . . . . 15 92 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 93 8.1. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 18 94 8.2. Ciena Corp . . . . . . . . . . . . . . . . . . . . . . . 18 95 8.3. Huawei Technologies . . . . . . . . . . . . . . . . . . . 18 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 97 9.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 19 98 9.2. PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . . 19 99 9.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 19 100 9.4. Flags in the Multipath Capability TLV . . . . . . . . . . 20 101 9.5. Flags in the Path Attribute Object . . . . . . . . . . . 20 102 9.6. Flags in the Multipath Backup TLV . . . . . . . . . . . . 21 103 9.7. Flags in the Multipath Opposite Direction Path TLV . . . 21 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 105 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 106 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 107 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 108 13.1. Normative References . . . . . . . . . . . . . . . . . . 22 109 13.2. Informative References . . . . . . . . . . . . . . . . . 23 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 112 1. Introduction 114 Path Computation Element (PCE) Communication Protocol (PCEP) 115 [RFC5440] enables the communication between a Path Computation Client 116 (PCC) and a Path Control Element (PCE), or between two PCEs based on 117 the PCE architecture [RFC4655]. 119 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 120 of extensions to PCEP that enable active control of Multiprotocol 121 Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS 122 (GMPLS) tunnels. [RFC8281] describes the setup and teardown of PCE- 123 initiated LSPs under the active stateful PCE model, without the need 124 for local configuration on the PCC, thus allowing for dynamic 125 centralized control of a network. 127 PCEP Extensions for Segment Routing [RFC8664] specifies extensions to 128 the Path Computation Element Protocol (PCEP) that allow a stateful 129 PCE to compute and initiate Traffic Engineering (TE) paths, as well 130 as for a PCC to request a path subject to certain constraint(s) and 131 optimization criteria in SR networks. 133 Segment Routing Policy for Traffic Engineering 134 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 135 Policy and approaches to steering traffic into an SR Policy. In 136 particular, it describes the SR candidate-path as a collection of one 137 or more Segment-Lists. The current PCEP standards only allow for 138 signaling of one Segment-List per Candidate-Path. PCEP extension to 139 support Segment Routing Policy Candidate Paths 140 [I-D.ietf-pce-segment-routing-policy-cp] specifically avoids defining 141 how to signal multipath information, and states that this will be 142 defined in another document. 144 This document defines the required extensions that allow the 145 signaling of multipath information via PCEP. 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 151 "OPTIONAL" in this document are to be interpreted as described in BCP 152 14 [RFC2119] [RFC8174] when, and only when, they appear in all 153 capitals, as shown here. 155 2.1. Terms and Abbreviations 157 The following terms are used in this document: 159 PCEP Tunnel: 161 The object identified by the PLSP-ID, see 162 [I-D.koldychev-pce-operational] for more details. 164 3. Motivation 166 This extension is motivated by the use-cases described below. 168 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 170 The Candidate-Path of an SR Policy is the unit of report/update in 171 PCEP, see [I-D.ietf-pce-segment-routing-policy-cp]. Each Candidate- 172 Path can contain multiple Segment-Lists and each Segment-List is 173 encoded by one ERO. However, each PCEP LSP can contain only a single 174 ERO, which prevents us from encoding multiple Segment- Lists within 175 the same SR Candidate-Path. 177 With the help of the protocol extensions defined in this document, 178 this limitation is overcome. 180 3.2. Splitting of Requested Bandwidth 182 A PCC may request a path with 80 Gbps of bandwidth, but all links in 183 the network have only 50 Gbps capacity. The PCE can return two 184 paths, that can together carry 80 Gbps. The PCC can then equally or 185 unequally split the incoming 80 Gbps of traffic among the two paths. 186 Section 4.3 introduces a new TLV that carries the path weight that 187 allows for distribution of incoming traffic on to the multiple paths. 189 3.3. Providing Backup path for Protection 191 It is desirable for the PCE to compute and signal to the PCC a backup 192 path that is used to protect a primary path within the multipaths in 193 a given LSP. 195 Note that [RFC8745] specify the Path Protection association among 196 LSPs. The use of [RFC8745] with multipath is out of scope of this 197 document and is for future study. 199 When multipath is used, a backup path may protect one or more primary 200 paths. For this reason, primary and backup path identifiers are 201 needed to indicate which backup path(s) protect which primary 202 path(s). Section 4.4 introduces a new TLV that carries the required 203 information. 205 3.4. Reverse Path Information 207 Certain applications, such as Circuit Style SR Policy 208 [I-D.schmutzer-pce-cs-sr-policy], require the head-end to know both 209 forward and reverse paths for each of the segment lists of an SR 210 Policy in order to run OAM/PM/BFD protocols on each Segment List as a 211 separate circuit. 213 4. Protocol Extensions 215 4.1. Multipath Capability TLV 217 We define the MULTIPATH-CAP TLV that MAY be present in the OPEN 218 object and/or the LSP object. The purpose of this TLV is two-fold: 220 1. From PCC: it tells how many multipaths per PCEP Tunnel, the PCC 221 can install in forwarding. 223 2. From PCE: it tells that the PCE supports this standard and how 224 many multipaths per PCEP Tunnel, the PCE can compute. 226 Only the first instance of this TLV can be processed, subsequent 227 instances SHOULD be ignored. 229 Section 5 specify the usage of this TLV with Open message (within the 230 OPEN object) and other PCEP messages (within the LSP object). 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type | Length | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Number of Multipaths | Flags |O|B|W| 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 Figure 1: MULTIPATH-CAP TLV format 242 Type: TBD1 for "MULTIPATH-CAP" TLV. 244 Length: 4. 246 Number of Multipaths: the maximum number of multipaths per PCEP 247 Tunnel. The value 0 indicates unlimited number. 249 W-flag: whether MULTIPATH-WEIGHT-TLV is supported. 251 B-flag: whether MULTIPATH-BACKUP-TLV is supported. 253 O-flag: whether MULTIPATH-OPPDIR-PATH-TLV is supported. 255 4.2. Path Attributes Object 257 We define the PATH-ATTRIB object that is used to carry per-path 258 information and to act as a separator between several ERO/RRO objects 259 in the / RBNF element. The PATH-ATTRIB 260 object always precedes the ERO/RRO that it applies to. If multiple 261 ERO/RRO objects are present, then each ERO/RRO object MUST be 262 preceded by an PATH-ATTRIB object that describes it. 264 The PATH-ATTRIB Object-Class value is TBD2. 266 The PATH-ATTRIB Object-Type value is 1. 268 0 1 2 3 269 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 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | Flags |R| O | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Path ID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 ~ Optional TLVs ~ 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 2: PATH-ATTRIB object format 280 O (Operational - 3 bits): operational state of the path, same values 281 as the identically named field in the LSP object [RFC8231]. 283 R (Reverse): Indicates this path is reverse, i.e., it originates on 284 the Tunnel destination and terminates on the Tunnel source (usually 285 the PCC headend itself). Paths with this flag set MUST NOT be 286 installed into forwarding, they serve only informational purposes. 288 Path ID: 4-octet identifier that identifies a path (encoded in the 289 ERO/RRO) within the set of multiple paths under the PCEP LSP. See 290 Section 5.2 for details. 292 TLVs that may be included in the PATH-ATTRIB object are described in 293 the following sections. Other optional TLVs could be defined by 294 future documents to be included within the PATH-ATTRIB object body. 296 4.3. Multipath Weight TLV 298 We define the MULTIPATH-WEIGHT TLV that MAY be present in the PATH- 299 ATTRIB object. 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type | Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Weight | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 3: MULTIPATH-WEIGHT TLV format 311 Type: TBD3 for "MULTIPATH-WEIGHT" TLV. 313 Length: 4. 315 Weight: weight of this path within the multipath, if W-ECMP is 316 desired. The fraction of flows a specific ERO/RRO carries is derived 317 from the ratio of its weight to the sum of all other multipath ERO/ 318 RRO weights. 320 When the MULTIPATH-WEIGHT TLV is absent from the PATH-ATTRIB object, 321 or the PATH-ATTRIB object is absent from the /, then the Weight of the corresponding path is taken to be "1". 324 4.4. Multipath Backup TLV 326 This document introduces a new MULTIPATH-BACKUP TLV that MAY be 327 present in the PATH-ATTRIB object. 329 This TLV is used to indicate the presence of a backup path that is 330 used for protection in case of failure of the primary path. The 331 format of the MULTIPATH-BACKUP TLV is: 333 0 1 2 3 334 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 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | Type | Length | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Backup Path Count | Flags |B| 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Backup Path ID 1 | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Backup Path ID 2 | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | ... | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Backup Path ID n | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 4: MULTIPATH-BACKUP TLV format 351 Type: TBD4 for "MULTIPATH-BACKUP" TLV 353 Length: 4 + (N * 4) (where N is the Backup Path Count) 355 Backup Path Count: Number of backup path(s). 357 B: If set, indicates a pure backup path. This is a path that only 358 carries rerouted traffic after the protected path fails. If this 359 flag is not set, or if the MULTIPATH-BACKUP TLV is absent, then the 360 path is assumed to be primary that carries normal traffic. 362 Backup Path ID(s): a series of 4-octet identifier(s) that identify 363 the backup path(s) in the set that protect this primary path. 365 4.5. Multipath Opposite Direction Path TLV 367 This document introduces a new MULTIPATH-OPPDIR-PATH TLV that MAY be 368 present in the PATH-ATTRIB object. This TLV encodes a many-to-many 369 mapping between forward and reverse paths within a PCEP Tunnel. 371 Many-to-many mapping means that a single forward path MAY map to 372 multiple reverse paths and conversely that a single reverse path MAY 373 map to multiple forward paths. Many-to-many mapping can happen for 374 an SR Policy, when a Segment List contains Node Segment(s) which 375 traverse parallel links at the midpoint. The reverse of this Segment 376 List may not be able to be expressed as a single Reverse Segment 377 List, but need to return multiple Reverse Segment Lists to cover all 378 the parallel links at the midpoint. 380 0 1 2 3 381 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 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 | Type | Length | 384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 | Reserved (MBZ) | Flags |L|N| 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Opposite Direction Path ID | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 Figure 5: MULTIPATH-OPPDIR-PATH TLV format 392 Type: TBD9 for "MULTIPATH-OPPDIR-PATH" TLV 394 Length: 16. 396 N (Node co-routed): If set, indicates this path is node co-routed 397 with its opposite direction path, specified in this TLV. Two 398 opposite direction paths are node co-routed if they traverse the same 399 nodes, but MAY traverse different links. 401 L (Link co-routed): If set, indicates this path is link co-routed 402 with its opposite directions path, specified in this TLV. Two 403 opposite direction paths are link co-routed if they traverse the same 404 links (but in the opposite directions). 406 Opposite Direction Path ID: Identifies a path that goes in the 407 opposite direction to this path. If no such path exists, then this 408 field MUST be set to 0x0, which is reserved to indicate the absense 409 of a Path ID. 411 Multiple instances of this TLV present in the same PATH-ATTRIB object 412 indicate that there are multiple opposite-direction paths 413 corresponding to the given path. This allows for many-to-many 414 relationship among the paths of two opposite direction Tunnels. 416 Whenever path A references another path B as being the opposite- 417 direction path, then path B typically also reference path A as its 418 own opposite-direction path. 420 See Section 7.4 for an example of usage. 422 4.6. Composite Candidate Path 424 SR Policy Architecture [I-D.ietf-spring-segment-routing-policy] 425 defines the concept of a Composite Candidate Path. Unlike a Non- 426 Composite Candidate Path, which contains Segment Lists, the Composite 427 Candidate Path contains Colors of other policies. The traffic that 428 is steered into a Composite Candidate Path is split among the 429 policies that are identified by the Colors contained in the Composite 430 Candidate Path. The split can be either ECMP or UCMP by adjusting 431 the weight of each color in the Composite Candidate Path, in the same 432 manner as the weight of each Segment List in the Non-Composite 433 Candidate Path is adjusted. 435 To signal the Composite Candidate Path, we make use of the COLOR TLV, 436 defined in [I-D.draft-rajagopalan-pce-pcep-color]. For a Composite 437 Candidate Path, the COLOR TLV is included in the PATH-ATTRIB Object, 438 thus allowing each Composite Candidate Path to do ECMP/UCMP among SR 439 Policies or Tunnels identified by its constituent Colors. Only one 440 COLOR TLV SHOULD be included into the PATH-ATTRIB object. If 441 multiple COLOR TLVs are contained in the PATH-ATTRIB object, only the 442 first one MUST be processed and the others SHOULD be ignored. 444 An empty ERO object MUST be included as per the existing RBNF, i.e., 445 ERO MUST contain no sub-objects. If the head-end receives a non- 446 empty ERO, then it MUST send PCError message with Error-Type 19 447 ("Invalid Operation") and Error-Value = TBD8 ("Non-empty path"). 449 See Section 7.3 for an example of the encoding. 451 5. Operation 453 5.1. Capability Negotiation 455 When the PCC wants to indicate to the PCE that it wants to get 456 multipaths for a PCEP Tunnel, instead of a single path, it can do 457 either (1) or both (1) and (2) of the following: 459 (1) Send the MULTIPATH-CAP TLV in the OPEN object during session 460 establishment. This applies to all PCEP Tunnels on the PCC, unless 461 overridden by PCEP Tunnel specific information. 463 (2) Additionally send the MULTIPATH-CAP TLV in the LSP object for a 464 particular PCEP Tunnel in the PCRpt or PCReq message. This applies 465 to the specified PCEP Tunnel and overrides the information from the 466 OPEN object. 468 When PCE computes the path for a PCEP Tunnel, it MUST NOT return more 469 multipaths than the corresponding value of "Number of Multipaths" 470 from the MULTIPATH-CAP TLV. If this TLV is absent (from both OPEN 471 and LSP objects), then the "Number of Multipaths" is assumed to be 1. 473 If the PCE supports this standard, then it MUST include the 474 MULTIPATH-CAP TLV in the OPEN object. This tells the PCC that it can 475 report multiple ERO/RRO objects per PCEP Tunnel to this PCE. If the 476 PCE does not include the MULTIPATH-CAP TLV in the OPEN object, then 477 the PCC MUST assume that the PCE does not support this standard and 478 fall back to reporting only a single ERO/RRO. 480 5.2. Path ID 482 The Path ID uniquely identifies a Path within the context of a PCEP 483 Tunnel. Note that when the PCEP Tunnel is an SR Policy Candidate 484 Path, the Paths within that tunnel are the Segment Lists of that 485 Candidate Path. 487 Value 0x0 is reserved to indicate the absense of a Path ID. The 488 value of 0x0 MAY be used when this Path is not being referenced and 489 the allocation of a Path ID is not necessary. 491 Path IDs are allocated by the PCEP peer that currently owns the 492 Tunnel. If the Tunnel is delegated to the PCE, then the PCE 493 allocates the Path IDs and sends them in the PCReply/PCUpd/PCInit 494 messages. If the Tunnel is locally computed on the PCC, then the PCC 495 allocates the Path IDs and sends them in the PCReq/PCRpt messages. 497 If a PCEP speaker detects that there are two Paths with the same Path 498 ID, then the PCEP speaker SHOULD send PCError message with Error-Type 499 = 1 ("Reception of an invalid object") and Error-Value = TBD5 500 ("Conflicting Path ID"). 502 5.3. Signaling Multiple Paths for Loadbalancing 504 The PATH-ATTRIB object can be used to signal multiple path(s) and 505 indicate (un)equal loadbalancing amongst the set of multipaths. In 506 this case, the PATH-ATTRIB is populated for each ERO as follows: 508 1. The PCE assigns a unique Path ID to each ERO path and populates 509 it inside the PATH-ATTRIB object. The Path ID is unique within 510 the context of a PLSP or PCEP Tunnel. 512 2. The MULTIPATH-WEIGHT TLV MAY be carried inside the PATH-ATTRIB 513 object. A weight is populated to reflect the relative loadshare 514 that is to be carried by the path. If the MULTIPATH-WEIGHT is 515 not carried inside a PATH-ATTRIB object, the default weight 1 516 MUST be assumed when computing the loadshare. 518 3. The fraction of flows carried by a specific primary path is 519 derived from the ratio of its weight to the sum of all other 520 multipath weights. 522 5.4. Signaling Multiple Paths for Protection 524 The PATH-ATTRIB object can be used to describe a set of backup 525 path(s) protecting a primary path within a PCEP Tunnel. In this 526 case, the PATH-ATTRIB is populated for each ERO as follows: 528 1. The PCE assigns a unique Path ID to each ERO path and populates 529 it inside the PATH-ATTRIB object. The Path ID is unique within 530 the context of a PLSP or PCEP Tunnel. 532 2. The MULTIPATH-BACKUP TLV MAY be added inside the PATH-ATTRIB 533 object for each ERO that is protected. The backup path ID(s) are 534 populated in the MULTIPATH-BACKUP TLV to reflect the set of 535 backup path(s) protecting the primary path. The Length field and 536 Backup Path Number in the MULTIPATH-BACKUP are updated according 537 to the number of backup path ID(s) included. 539 3. The MULTIPATH-BACKUP TLV MAY be added inside the PATH-ATTRIB 540 object for each ERO that is unprotected. In this case, 541 MULTIPATH-BACKUP does not carry any backup path IDs in the TLV. 542 If the path acts as a pure backup - i.e. the path only carries 543 rerouted traffic after the protected path(s) fail- then the B 544 flag MUST be set. 546 Note that primary paths which do not include the MULTIPATH-BACKUP TLV 547 are assumed to be protected by all the backup paths. I.e., omitting 548 the TLV is equivalent to including the TLV with all the backup path 549 IDs filled in. 551 Note that a given PCC may not support certain backup combinations, 552 such as a backup path that is itself protected by another backup 553 path, etc. If a PCC is not able to implement a requested backup 554 scenario, the PCC SHOULD send a PCError message with Error-Type = 19 555 ("Invalid Operation") and Error-Value = TBD7 ("Not supported path 556 backup"). 558 6. PCEP Message Extensions 560 The RBNF of PCReq, PCRep, PCRpt, PCUpd and PCInit messages currently 561 use a combination of and/or . As 562 specified in Section 6.1 of [RFC8231], is represented 563 by the ERO object and is represented by the RRO object: 565 ::= 567 ::= 569 In this standard, we extend these two elements to allow multiple ERO/ 570 RRO objects to be present in the /: 572 ::= (| 573 () 574 []) 576 ::= (| 577 () 578 []) 580 7. Examples 582 7.1. SR Policy Candidate-Path with Multiple Segment-Lists 584 Consider the following sample SR Policy, taken from 585 [I-D.ietf-spring-segment-routing-policy]. 587 SR policy POL1 588 Candidate-path CP1 590 Preference 200 591 Weight W1, SID-List1 592 Weight W2, SID-List2 593 Candidate-path CP2 595 Preference 100 596 Weight W3, SID-List3 597 Weight W4, SID-List4 599 As specified in [I-D.ietf-pce-segment-routing-policy-cp], CP1 and CP2 600 are signaled as separate state-report elements and each has a unique 601 PLSP-ID, assigned by the PCC. Let us assign PLSP-ID 100 to CP1 and 602 PLSP-ID 200 to CP2. 604 The state-report for CP1 can be encoded as: 606 = 607 608 609 610 > 611 612 > 613 615 The state-report for CP2 can be encoded as: 617 = 618 619 620 621 > 622 623 > 624 626 The above sample state-report elements only specify the minimum 627 mandatory objects, of course other objects like SRP, LSPA, METRIC, 628 etc., are allowed to be inserted. 630 Note that the syntax 632 > 634 , simply means that this is PATH-ATTRIB object with Path ID field set 635 to "1" and with a MULTIPATH-WEIGHT TLV carrying weight of "W1". 637 7.2. Two Primary Paths Protected by One Backup Path 639 Suppose there are 3 paths: A, B, C. Where A,B are primary and C is 640 to be used only when A or B fail. Suppose the Path IDs for A, B, C 641 are respectively 1, 2, 3. This would be encoded in a state-report 642 as: 644 = 645 646 647 648 > 649 650 > 651 652 > 653 655 Note that the syntax 657 > 659 , simply means that this is PATH-ATTRIB object with Path ID field set 660 to "1" and with a MULTIPATH-BACKUP TLV that has B-flag cleared and 661 contains a single backup path with Backup Path ID of 3. 663 7.3. Composite Candidate Path 665 Consider the following Composite Candidate Path, taken from 666 [I-D.ietf-spring-segment-routing-policy]. 668 SR policy POL100 669 Candidate-path CP1 671 Preference 200 672 Weight W1, SR policy 673 Weight W2, SR policy 675 This is signaled in PCEP as: 677 678 679 680 682 > 683 684 686 > 687 689 7.4. Opposite Direction Tunnels 691 Consider the two opposite-direction SR Policies between end-points H1 692 and E1. 694 SR policy POL1 695 Candidate-path CP1 696 Preference 200 697 Bidirectional Association = A1 698 SID-List = 699 SID-List = 700 Candidate-path CP2 701 Preference 100 702 Bidirectional Association = A2 703 SID-List = 704 SID-List = 706 SR policy POL2 707 Candidate-path CP1 708 Preference 200 709 Bidirectional Association = A1 710 SID-List = 711 SID-List = 712 Candidate-path CP2 713 Preference 100 714 Bidirectional Association = A2 715 SID-List = 717 The state-report for POL1, CP1 can be encoded as: 719 = 720 721 722 > 724 > 725 > 727 > 728 > 730 > 731 > 733 > 735 The state-report for POL1, CP2 can be encoded as: 737 = 738 739 740 > 742 > 743 > 745 > 746 > 748 > 750 The state-report for POL2, CP1 can be encoded as: 752 = 753 754 755 > 757 > 758 > 760 > 761 > 763 > 764 > 766 > 768 The state-report for POL2, CP2 can be encoded as: 770 = 771 772 773 > 775 > 776 > 778 > 779 > 781 > 783 8. Implementation Status 785 Note to the RFC Editor - remove this section before publication, as 786 well as remove the reference to [RFC7942]. 788 This section records the status of known implementations of the 789 protocol defined by this specification at the time of posting of this 790 Internet-Draft, and is based on a proposal described in [RFC7942]. 791 The description of implementations in this section is intended to 792 assist the IETF in its decision processes in progressing drafts to 793 RFCs. Please note that the listing of any individual implementation 794 here does not imply endorsement by the IETF. Furthermore, no effort 795 has been spent to verify the information presented here that was 796 supplied by IETF contributors. This is not intended as, and must not 797 be construed to be, a catalog of available implementations or their 798 features. Readers are advised to note that other implementations may 799 exist. 801 According to [RFC7942], "this will allow reviewers and working groups 802 to assign due consideration to documents that have the benefit of 803 running code, which may serve as evidence of valuable experimentation 804 and feedback that have made the implemented protocols more mature. 805 It is up to the individual working groups to use this information as 806 they see fit". 808 8.1. Cisco Systems 810 Organization: Cisco Systems 811 Implementation: IOS-XR PCC and PCE 812 Description: Circuit-Style SR Policies 813 Maturity Level: Supported feature 814 Coverage: Multiple Segment-Lists and reverse paths in SR Policy 815 Contact: mkoldych@cisco.com 817 8.2. Ciena Corp 819 Organization: Ciena Corp 820 Implementation: Head-end and controller 821 Maturity Level: Proof of concept 822 Coverage: Full 823 Contact: byadav@ciena.com 825 8.3. Huawei Technologies 826 Organization: Huawei Technologies Co.,Ltd. 827 Implementation: Huawei's Router and Controller 828 Maturity Level: Proof of concept 829 Coverage: Partial 830 Contact: tanren@huawei.com 832 9. IANA Considerations 834 9.1. PCEP Object 836 IANA is requested to make the assignment of a new value for the 837 existing "PCEP Objects" registry as follows: 839 +--------------+-------------+-------------------+-----------------+ 840 | Object-Class | Name | Object-Type | Reference | 841 | Value | | Value | | 842 +--------------+-------------+-------------------+-----------------+ 843 | 45 | PATH-ATTRIB | 1 | This document | 844 +--------------+-------------+-------------------+-----------------+ 846 9.2. PCEP TLV 848 IANA is requested to make the assignment of a new value for the 849 existing "PCEP TLV Type Indicators" registry as follows: 851 +------------+-----------------------------------+-----------------+ 852 | TLV Type | TLV Name | Reference | 853 | Value | | | 854 +------------+-----------------------------------+-----------------+ 855 | 60 | MULTIPATH-CAP | This document | 856 +------------+-----------------------------------+-----------------+ 857 | 61 | MULTIPATH-WEIGHT | This document | 858 +------------+-----------------------------------+-----------------+ 859 | 62 | MULTIPATH-BACKUP | This document | 860 +------------+-----------------------------------+-----------------+ 861 | 63 | MULTIPATH-OPPDIR-PATH | This document | 862 +------------+-----------------------------------+-----------------+ 864 9.3. PCEP-Error Object 866 IANA is requested to make the assignment of a new value for the 867 existing "PCEP-ERROR Object Error Types and Values" sub-registry of 868 the PCEP Numbers registry for the following errors: 870 +------------+-----------------------------------+-----------------+ 871 | Error-Type | Error-Value | Reference | 872 +------------+-----------------------------------+-----------------+ 873 | 10 | 38 - Conflicting Path ID | This document | 874 +------------+-----------------------------------+-----------------+ 875 | 19 | 20 - Not supported path backup | This document | 876 +------------+-----------------------------------+-----------------+ 877 | 19 | 21 - Non-empty path | This document | 878 +------------+-----------------------------------+-----------------+ 880 9.4. Flags in the Multipath Capability TLV 882 IANA is requested to create a new sub-registry to manage the Flag 883 field of the MULTIPATH-CAP TLV, called "Flags in MULTIPATH-CAP TLV". 884 New values are to be assigned by Standards Action [RFC8126] 886 +------------+-----------------------------------+-----------------+ 887 | Bit | Description | Reference | 888 +------------+-----------------------------------+-----------------+ 889 | 0-12 | Unassigned | This document | 890 +------------+-----------------------------------+-----------------+ 891 | 13 | 0-flag: support for processing | This document | 892 | | MULTIPATH-OPPDIR-PATH TLV | | 893 +------------+-----------------------------------+-----------------+ 894 | 14 | B-flag: support for processing | This document | 895 | | MULTIPATH-BACKUP TLV | | 896 +------------+-----------------------------------+-----------------+ 897 | 15 | W-flag: support for processing | This document | 898 | | MULTIPATH-WEIGHT TLV | | 899 +------------+-----------------------------------+-----------------+ 901 9.5. Flags in the Path Attribute Object 903 IANA is requested to create a new sub-registry to manage the Flag 904 field of the PATH-ATTRIBUTE object, called "Flags in PATH-ATTRIBUTE 905 Object". New values are to be assigned by Standards Action [RFC8126] 907 +------------+-----------------------------------+-----------------+ 908 | Bit | Description | Reference | 909 +------------+-----------------------------------+-----------------+ 910 | 0-12 | Unassigned | This document | 911 +------------+-----------------------------------+-----------------+ 912 | 13-15 | O-flag: Operational state | This document | 913 +------------+-----------------------------------+-----------------+ 915 9.6. Flags in the Multipath Backup TLV 917 IANA is requested to create a new sub-registry to manage the Flag 918 field of the MULTIPATH-BACKUP TLV, called "Flags in MULTIPATH-BACKUP 919 TLV". New values are to be assigned by Standards Action [RFC8126] 921 +------------+-----------------------------------+-----------------+ 922 | Bit | Description | Reference | 923 +------------+-----------------------------------+-----------------+ 924 | 0-14 | Unassigned | This document | 925 +------------+-----------------------------------+-----------------+ 926 | 15 | B-flag: Pure backup | This document | 927 +------------+-----------------------------------+-----------------+ 929 9.7. Flags in the Multipath Opposite Direction Path TLV 931 IANA is requested to create a new sub-registry to manage the flag 932 fields of the MULTIPATH-OPPDIR-PATH TLV, called "Flags in the 933 MULTIPATH-OPPDIR-PATH TLV". New values are to be assigned by 934 Standards Action [RFC8126] 936 +------------+-----------------------------------+-----------------+ 937 | Bit | Description | Reference | 938 +------------+-----------------------------------+-----------------+ 939 | 0-12 | Unassigned | This document | 940 +------------+-----------------------------------+-----------------+ 941 | 14 | L-flag: Link co-routed | This document | 942 +------------+-----------------------------------+-----------------+ 943 | 15 | N-flag: Node co-routed | This document | 944 +------------+-----------------------------------+-----------------+ 946 10. Security Considerations 948 None at this time. 950 11. Acknowledgement 952 Thanks to Dhruv Dhody for ideas and discussion. 954 12. Contributors 956 Andrew Stone 957 Nokia 959 Email: andrew.stone@nokia.com 961 13. References 962 13.1. Normative References 964 [I-D.draft-rajagopalan-pce-pcep-color] 965 Rajagopalan, B., Beeram, V. P., Peng, S., Xiong, Q., 966 Koldychev, M., and G. Mishra, "Path Computation Element 967 Protocol(PCEP) Extension for Color", Work in Progress, 968 Internet-Draft, draft-rajagopalan-pce-pcep-color-01, 14 969 November 2021, . 972 [I-D.ietf-pce-segment-routing-policy-cp] 973 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 974 Bidgoli, "PCEP extension to support Segment Routing Policy 975 Candidate Paths", Work in Progress, Internet-Draft, draft- 976 ietf-pce-segment-routing-policy-cp-07, 21 April 2022, 977 . 980 [I-D.ietf-spring-segment-routing-policy] 981 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 982 P. Mattes, "Segment Routing Policy Architecture", Work in 983 Progress, Internet-Draft, draft-ietf-spring-segment- 984 routing-policy-22, 22 March 2022, 985 . 988 [I-D.koldychev-pce-operational] 989 Koldychev, M., Sivabalan, S., Peng, S., Achaval, D., and 990 H. Kotni, "PCEP Operational Clarification", Work in 991 Progress, Internet-Draft, draft-koldychev-pce-operational- 992 05, 19 February 2022, . 995 [I-D.schmutzer-pce-cs-sr-policy] 996 Schmutzer, C., Filsfils, C., Ali, Z., Clad, F., 997 Maheshwari, P., Rokui, R., Stone, A., Jalil, L., Peng, S., 998 Saad, T., and D. Voyer, "Circuit Style Segment Routing 999 Policies", Work in Progress, Internet-Draft, draft- 1000 schmutzer-pce-cs-sr-policy-02, 5 May 2022, 1001 . 1004 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1005 Requirement Levels", BCP 14, RFC 2119, 1006 DOI 10.17487/RFC2119, March 1997, 1007 . 1009 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1010 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1011 DOI 10.17487/RFC5440, March 2009, 1012 . 1014 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1015 Code: The Implementation Status Section", BCP 205, 1016 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1017 . 1019 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1020 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1021 May 2017, . 1023 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1024 Computation Element Communication Protocol (PCEP) 1025 Extensions for Stateful PCE", RFC 8231, 1026 DOI 10.17487/RFC8231, September 2017, 1027 . 1029 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1030 Computation Element Communication Protocol (PCEP) 1031 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1032 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1033 . 1035 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1036 and J. Hardwick, "Path Computation Element Communication 1037 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1038 DOI 10.17487/RFC8664, December 2019, 1039 . 1041 13.2. Informative References 1043 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1044 Computation Element (PCE)-Based Architecture", RFC 4655, 1045 DOI 10.17487/RFC4655, August 2006, 1046 . 1048 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1049 Writing an IANA Considerations Section in RFCs", BCP 26, 1050 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1051 . 1053 [RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., 1054 and M. Negi, "Path Computation Element Communication 1055 Protocol (PCEP) Extensions for Associating Working and 1056 Protection Label Switched Paths (LSPs) with Stateful PCE", 1057 RFC 8745, DOI 10.17487/RFC8745, March 2020, 1058 . 1060 Authors' Addresses 1062 Mike Koldychev 1063 Cisco Systems, Inc. 1064 Email: mkoldych@cisco.com 1066 Siva Sivabalan 1067 Ciena Corporation 1068 Email: ssivabal@ciena.com 1070 Tarek Saad 1071 Juniper Networks, Inc. 1072 Email: tsaad@juniper.net 1074 Vishnu Pavan Beeram 1075 Juniper Networks, Inc. 1076 Email: vbeeram@juniper.net 1078 Hooman Bidgoli 1079 Nokia 1080 Email: hooman.bidgoli@nokia.com 1082 Bhupendra Yadav 1083 Ciena 1084 Email: byadav@ciena.com 1086 Shuping Peng 1087 Huawei Technologies 1088 Email: pengshuping@huawei.com 1090 Gyan Mishra 1091 Verizon Inc. 1092 Email: gyan.s.mishra@verizon.com