idnits 2.17.00 (12 Aug 2021) /tmp/idnits48556/draft-ietf-pce-multipath-05.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 document date (30 March 2022) is 45 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 (-07) exists of draft-ietf-pce-segment-routing-policy-cp-06 == Outdated reference: A later version (-02) exists of draft-schmutzer-pce-cs-sr-policy-01 ** 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 (~~), 2 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: 1 October 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 30 March 2022 19 PCEP Extensions for Signaling Multipath Information 20 draft-ietf-pce-multipath-05 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 1 October 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 . . . . . . . . . . 4 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 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 9.1. PCEP Object . . . . . . . . . . . . . . . . . . . . . . . 18 97 9.2. PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . . 19 98 9.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 19 99 9.4. Flags in the Multipath Capability TLV . . . . . . . . . . 19 100 9.5. Flags in the Path Attribute Object . . . . . . . . . . . 20 101 9.6. Flags in the Multipath Backup TLV . . . . . . . . . . . . 20 102 9.7. Flags in the Multipath Opposite Direction Path TLV . . . 21 103 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 104 11. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 21 105 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 106 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 107 13.1. Normative References . . . . . . . . . . . . . . . . . . 21 108 13.2. Informative References . . . . . . . . . . . . . . . . . 23 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 111 1. Introduction 113 Path Computation Element (PCE) Communication Protocol (PCEP) 114 [RFC5440] enables the communication between a Path Computation Client 115 (PCC) and a Path Control Element (PCE), or between two PCEs based on 116 the PCE architecture [RFC4655]. 118 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 119 of extensions to PCEP that enable active control of Multiprotocol 120 Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS 121 (GMPLS) tunnels. [RFC8281] describes the setup and teardown of PCE- 122 initiated LSPs under the active stateful PCE model, without the need 123 for local configuration on the PCC, thus allowing for dynamic 124 centralized control of a network. 126 PCEP Extensions for Segment Routing [RFC8664] specifies extensions to 127 the Path Computation Element Protocol (PCEP) that allow a stateful 128 PCE to compute and initiate Traffic Engineering (TE) paths, as well 129 as for a PCC to request a path subject to certain constraint(s) and 130 optimization criteria in SR networks. 132 Segment Routing Policy for Traffic Engineering 133 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 134 Policy and approaches to steering traffic into an SR Policy. In 135 particular, it describes the SR candidate-path as a collection of one 136 or more Segment-Lists. The current PCEP standards only allow for 137 signaling of one Segment-List per Candidate-Path. PCEP extension to 138 support Segment Routing Policy Candidate Paths 139 [I-D.ietf-pce-segment-routing-policy-cp] specifically avoids defining 140 how to signal multipath information, and states that this will be 141 defined in another document. 143 This document defines the required extensions that allow the 144 signaling of multipath information via PCEP. 146 2. Terminology 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in BCP 151 14 [RFC2119] [RFC8174] when, and only when, they appear in all 152 capitals, as shown here. 154 2.1. Terms and Abbreviations 156 The following terms are used in this document: 158 PCEP Tunnel: 160 The object identified by the PLSP-ID, see 161 [I-D.koldychev-pce-operational] for more details. 163 3. Motivation 165 This extension is motivated by the use-cases described below. 167 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 169 The Candidate-Path of an SR Policy is the unit of report/update in 170 PCEP, see [I-D.ietf-pce-segment-routing-policy-cp]. Each Candidate- 171 Path can contain multiple Segment-Lists and each Segment-List is 172 encoded by one ERO. However, each PCEP LSP can contain only a single 173 ERO, which prevents us from encoding multiple Segment- Lists within 174 the same SR Candidate-Path. 176 With the help of the protocol extensions defined in this document, 177 this limitation is overcome. 179 3.2. Splitting of Requested Bandwidth 181 A PCC may request a path with 80 Gbps of bandwidth, but all links in 182 the network have only 50 Gbps capacity. The PCE can return two 183 paths, that can together carry 80 Gbps. The PCC can then equally or 184 unequally split the incoming 80 Gbps of traffic among the two paths. 185 Section 4.3 introduces a new TLV that carries the path weight that 186 allows for distribution of incoming traffic on to the multiple paths. 188 3.3. Providing Backup path for Protection 190 It is desirable for the PCE to compute and signal to the PCC a backup 191 path that is used to protect a primary path within the multipaths in 192 a given LSP. 194 Note that [RFC8745] specify the Path Protection association among 195 LSPs. The use of [RFC8745] with multipath is out of scope of this 196 document and is for future study. 198 When multipath is used, a backup path may protect one or more primary 199 paths. For this reason, primary and backup path identifiers are 200 needed to indicate which backup path(s) protect which primary 201 path(s). Section 4.4 introduces a new TLV that carries the required 202 information. 204 3.4. Reverse Path Information 206 Certain applications, such as Circuit Style SR Policy 207 [I-D.schmutzer-pce-cs-sr-policy], require the head-end to know both 208 forward and reverse paths for each of the segment lists of an SR 209 Policy in order to run OAM/PM/BFD protocols on each Segment List as a 210 separate circuit. 212 4. Protocol Extensions 214 4.1. Multipath Capability TLV 216 We define the MULTIPATH-CAP TLV that MAY be present in the OPEN 217 object and/or the LSP object. The purpose of this TLV is two-fold: 219 1. From PCC: it tells how many multipaths per PCEP Tunnel, the PCC 220 can install in forwarding. 222 2. From PCE: it tells that the PCE supports this standard and how 223 many multipaths per PCEP Tunnel, the PCE can compute. 225 Only the first instance of this TLV can be processed, subsequent 226 instances SHOULD be ignored. 228 Section 5 specify the usage of this TLV with Open message (within the 229 OPEN object) and other PCEP messages (within the LSP object). 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Type | Length | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Number of Multipaths | Flags |O|B|W| 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 1: MULTIPATH-CAP TLV format 241 Type: TBD1 for "MULTIPATH-CAP" TLV. 243 Length: 4. 245 Number of Multipaths: the maximum number of multipaths per PCEP 246 Tunnel. The value 0 indicates unlimited number. 248 W-flag: whether MULTIPATH-WEIGHT-TLV is supported. 250 B-flag: whether MULTIPATH-BACKUP-TLV is supported. 252 O-flag: whether MULTIPATH-OPPDIR-PATH-TLV is supported. 254 4.2. Path Attributes Object 256 We define the PATH-ATTRIB object that is used to carry per-path 257 information and to act as a separator between several ERO/RRO objects 258 in the / RBNF element. The PATH-ATTRIB 259 object always precedes the ERO/RRO that it applies to. If multiple 260 ERO/RRO objects are present, then each ERO/RRO object MUST be 261 preceded by an PATH-ATTRIB object that describes it. 263 The PATH-ATTRIB Object-Class value is TBD2. 265 The PATH-ATTRIB Object-Type value is 1. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Flags |R| O | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Path ID | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 ~ Optional TLVs ~ 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 Figure 2: PATH-ATTRIB object format 279 O (Operational - 3 bits): operational state of the path, same values 280 as the identically named field in the LSP object [RFC8231]. 282 R (Reverse): Indicates this path is reverse, i.e., it originates on 283 the Tunnel destination and terminates on the Tunnel source (usually 284 the PCC headend itself). Paths with this flag set MUST NOT be 285 installed into forwarding, they serve only informational purposes. 287 Path ID: 4-octet identifier that identifies a path (encoded in the 288 ERO/RRO) within the set of multiple paths under the PCEP LSP. See 289 Section 5.2 for details. 291 TLVs that may be included in the PATH-ATTRIB object are described in 292 the following sections. Other optional TLVs could be defined by 293 future documents to be included within the PATH-ATTRIB object body. 295 4.3. Multipath Weight TLV 297 We define the MULTIPATH-WEIGHT TLV that MAY be present in the PATH- 298 ATTRIB object. 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Type | Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Weight | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 3: MULTIPATH-WEIGHT TLV format 310 Type: TBD3 for "MULTIPATH-WEIGHT" TLV. 312 Length: 4. 314 Weight: weight of this path within the multipath, if W-ECMP is 315 desired. The fraction of flows a specific ERO/RRO carries is derived 316 from the ratio of its weight to the sum of all other multipath ERO/ 317 RRO weights. 319 When the MULTIPATH-WEIGHT TLV is absent from the PATH-ATTRIB object, 320 or the PATH-ATTRIB object is absent from the /, then the Weight of the corresponding path is taken to be "1". 323 4.4. Multipath Backup TLV 325 This document introduces a new MULTIPATH-BACKUP TLV that MAY be 326 present in the PATH-ATTRIB object. 328 This TLV is used to indicate the presence of a backup path that is 329 used for protection in case of failure of the primary path. The 330 format of the MULTIPATH-BACKUP TLV is: 332 0 1 2 3 333 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 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | Type | Length | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Backup Path Count | Flags |B| 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Backup Path ID 1 | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Backup Path ID 2 | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | ... | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Backup Path ID n | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 4: MULTIPATH-BACKUP TLV format 350 Type: TBD4 for "MULTIPATH-BACKUP" TLV 352 Length: 4 + (N * 4) (where N is the Backup Path Count) 354 Backup Path Count: Number of backup path(s). 356 B: If set, indicates a pure backup path. This is a path that only 357 carries rerouted traffic after the protected path fails. If this 358 flag is not set, or if the MULTIPATH-BACKUP TLV is absent, then the 359 path is assumed to be primary that carries normal traffic. 361 Backup Path ID(s): a series of 4-octet identifier(s) that identify 362 the backup path(s) in the set that protect this primary path. 364 4.5. Multipath Opposite Direction Path TLV 366 This document introduces a new MULTIPATH-OPPDIR-PATH TLV that MAY be 367 present in the PATH-ATTRIB object. This TLV encodes a many-to-many 368 mapping between forward and reverse paths within a PCEP Tunnel. 370 Many-to-many mapping means that a single forward path MAY map to 371 multiple reverse paths and conversely that a single reverse path MAY 372 map to multiple forward paths. Many-to-many mapping can happen for 373 an SR Policy, when a Segment List contains Node Segment(s) which 374 traverse parallel links at the midpoint. The reverse of this Segment 375 List may not be able to be expressed as a single Reverse Segment 376 List, but need to return multiple Reverse Segment Lists to cover all 377 the parallel links at the midpoint. 379 0 1 2 3 380 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 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Type | Length | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Reserved (MBZ) | Flags |L|N| 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | Opposite Direction Path ID | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 Figure 5: MULTIPATH-OPPDIR-PATH TLV format 391 Type: TBD9 for "MULTIPATH-OPPDIR-PATH" TLV 393 Length: 16. 395 N (Node co-routed): If set, indicates this path is node co-routed 396 with its opposite direction path, specified in this TLV. Two 397 opposite direction paths are node co-routed if they traverse the same 398 nodes, but MAY traverse different links. 400 L (Link co-routed): If set, indicates this path is link co-routed 401 with its opposite directions path, specified in this TLV. Two 402 opposite direction paths are link co-routed if they traverse the same 403 links (but in the opposite directions). 405 Opposite Direction Path ID: Identifies a path that goes in the 406 opposite direction to this path. If no such path exists, then this 407 field MUST be set to 0x0, which is reserved to indicate the absense 408 of a Path ID. 410 Multiple instances of this TLV present in the same PATH-ATTRIB object 411 indicate that there are multiple opposite-direction paths 412 corresponding to the given path. This allows for many-to-many 413 relationship among the paths of two opposite direction Tunnels. 415 Whenever path A references another path B as being the opposite- 416 direction path, then path B typically also reference path A as its 417 own opposite-direction path. 419 See Section 7.4 for an example of usage. 421 4.6. Composite Candidate Path 423 SR Policy Architecture [I-D.ietf-spring-segment-routing-policy] 424 defines the concept of a Composite Candidate Path. Unlike a Non- 425 Composite Candidate Path, which contains Segment Lists, the Composite 426 Candidate Path contains Colors of other policies. The traffic that 427 is steered into a Composite Candidate Path is split among the 428 policies that are identified by the Colors contained in the Composite 429 Candidate Path. The split can be either ECMP or UCMP by adjusting 430 the weight of each color in the Composite Candidate Path, in the same 431 manner as the weight of each Segment List in the Non-Composite 432 Candidate Path is adjusted. 434 To signal the Composite Candidate Path, we make use of the COLOR TLV, 435 defined in [I-D.draft-rajagopalan-pce-pcep-color]. For a Composite 436 Candidate Path, the COLOR TLV is included in the PATH-ATTRIB Object, 437 thus allowing each Composite Candidate Path to do ECMP/UCMP among SR 438 Policies or Tunnels identified by its constituent Colors. Only one 439 COLOR TLV SHOULD be included into the PATH-ATTRIB object. If 440 multiple COLOR TLVs are contained in the PATH-ATTRIB object, only the 441 first one MUST be processed and the others SHOULD be ignored. 443 An empty ERO object MUST be included as per the existing RBNF, i.e., 444 ERO MUST contain no sub-objects. If the head-end receives a non- 445 empty ERO, then it MUST send PCError message with Error-Type 19 446 ("Invalid Operation") and Error-Value = TBD8 ("Non-empty path"). 448 See Section 7.3 for an example of the encoding. 450 5. Operation 452 5.1. Capability Negotiation 454 When the PCC wants to indicate to the PCE that it wants to get 455 multipaths for a PCEP Tunnel, instead of a single path, it can do 456 either (1) or both (1) and (2) of the following: 458 (1) Send the MULTIPATH-CAP TLV in the OPEN object during session 459 establishment. This applies to all PCEP Tunnels on the PCC, unless 460 overridden by PCEP Tunnel specific information. 462 (2) Additionally send the MULTIPATH-CAP TLV in the LSP object for a 463 particular PCEP Tunnel in the PCRpt or PCReq message. This applies 464 to the specified PCEP Tunnel and overrides the information from the 465 OPEN object. 467 When PCE computes the path for a PCEP Tunnel, it MUST NOT return more 468 multipaths than the corresponding value of "Number of Multipaths" 469 from the MULTIPATH-CAP TLV. If this TLV is absent (from both OPEN 470 and LSP objects), then the "Number of Multipaths" is assumed to be 1. 472 If the PCE supports this standard, then it MUST include the 473 MULTIPATH-CAP TLV in the OPEN object. This tells the PCC that it can 474 report multiple ERO/RRO objects per PCEP Tunnel to this PCE. If the 475 PCE does not include the MULTIPATH-CAP TLV in the OPEN object, then 476 the PCC MUST assume that the PCE does not support this standard and 477 fall back to reporting only a single ERO/RRO. 479 5.2. Path ID 481 The Path ID uniquely identifies a Path within the context of a PCEP 482 Tunnel. Note that when the PCEP Tunnel is an SR Policy Candidate 483 Path, the Paths within that tunnel are the Segment Lists of that 484 Candidate Path. 486 Value 0x0 is reserved to indicate the absense of a Path ID. The 487 value of 0x0 MAY be used when this Path is not being referenced and 488 the allocation of a Path ID is not necessary. 490 Path IDs are allocated by the PCEP peer that currently owns the 491 Tunnel. If the Tunnel is delegated to the PCE, then the PCE 492 allocates the Path IDs and sends them in the PCReply/PCUpd/PCInit 493 messages. If the Tunnel is locally computed on the PCC, then the PCC 494 allocates the Path IDs and sends them in the PCReq/PCRpt messages. 496 If a PCEP speaker detects that there are two Paths with the same Path 497 ID, then the PCEP speaker SHOULD send PCError message with Error-Type 498 = 1 ("Reception of an invalid object") and Error-Value = TBD5 499 ("Conflicting Path ID"). 501 5.3. Signaling Multiple Paths for Loadbalancing 503 The PATH-ATTRIB object can be used to signal multiple path(s) and 504 indicate (un)equal loadbalancing amongst the set of multipaths. In 505 this case, the PATH-ATTRIB is populated for each ERO as follows: 507 1. The PCE assigns a unique Path ID to each ERO path and populates 508 it inside the PATH-ATTRIB object. The Path ID is unique within 509 the context of a PLSP or PCEP Tunnel. 511 2. The MULTIPATH-WEIGHT TLV MAY be carried inside the PATH-ATTRIB 512 object. A weight is populated to reflect the relative loadshare 513 that is to be carried by the path. If the MULTIPATH-WEIGHT is 514 not carried inside a PATH-ATTRIB object, the default weight 1 515 MUST be assumed when computing the loadshare. 517 3. The fraction of flows carried by a specific primary path is 518 derived from the ratio of its weight to the sum of all other 519 multipath weights. 521 5.4. Signaling Multiple Paths for Protection 523 The PATH-ATTRIB object can be used to describe a set of backup 524 path(s) protecting a primary path within a PCEP Tunnel. In this 525 case, the PATH-ATTRIB is populated for each ERO as follows: 527 1. The PCE assigns a unique Path ID to each ERO path and populates 528 it inside the PATH-ATTRIB object. The Path ID is unique within 529 the context of a PLSP or PCEP Tunnel. 531 2. The MULTIPATH-BACKUP TLV MAY be added inside the PATH-ATTRIB 532 object for each ERO that is protected. The backup path ID(s) are 533 populated in the MULTIPATH-BACKUP TLV to reflect the set of 534 backup path(s) protecting the primary path. The Length field and 535 Backup Path Number in the MULTIPATH-BACKUP are updated according 536 to the number of backup path ID(s) included. 538 3. The MULTIPATH-BACKUP TLV MAY be added inside the PATH-ATTRIB 539 object for each ERO that is unprotected. In this case, 540 MULTIPATH-BACKUP does not carry any backup path IDs in the TLV. 541 If the path acts as a pure backup - i.e. the path only carries 542 rerouted traffic after the protected path(s) fail- then the B 543 flag MUST be set. 545 Note that primary paths which do not include the MULTIPATH-BACKUP TLV 546 are assumed to be protected by all the backup paths. I.e., omitting 547 the TLV is equivalent to including the TLV with all the backup path 548 IDs filled in. 550 Note that a given PCC may not support certain backup combinations, 551 such as a backup path that is itself protected by another backup 552 path, etc. If a PCC is not able to implement a requested backup 553 scenario, the PCC SHOULD send a PCError message with Error-Type = 19 554 ("Invalid Operation") and Error-Value = TBD7 ("Not supported path 555 backup"). 557 6. PCEP Message Extensions 559 The RBNF of PCReq, PCRep, PCRpt, PCUpd and PCInit messages currently 560 use a combination of and/or . As 561 specified in Section 6.1 of [RFC8231], is represented 562 by the ERO object and is represented by the RRO object: 564 ::= 566 ::= 568 In this standard, we extend these two elements to allow multiple ERO/ 569 RRO objects to be present in the /: 571 ::= (| 572 () 573 []) 575 ::= (| 576 () 577 []) 579 7. Examples 581 7.1. SR Policy Candidate-Path with Multiple Segment-Lists 583 Consider the following sample SR Policy, taken from 584 [I-D.ietf-spring-segment-routing-policy]. 586 SR policy POL1 587 Candidate-path CP1 589 Preference 200 590 Weight W1, SID-List1 591 Weight W2, SID-List2 592 Candidate-path CP2 594 Preference 100 595 Weight W3, SID-List3 596 Weight W4, SID-List4 598 As specified in [I-D.ietf-pce-segment-routing-policy-cp], CP1 and CP2 599 are signaled as separate state-report elements and each has a unique 600 PLSP-ID, assigned by the PCC. Let us assign PLSP-ID 100 to CP1 and 601 PLSP-ID 200 to CP2. 603 The state-report for CP1 can be encoded as: 605 = 606 607 608 609 > 610 611 > 612 614 The state-report for CP2 can be encoded as: 616 = 617 618 619 620 > 621 622 > 623 625 The above sample state-report elements only specify the minimum 626 mandatory objects, of course other objects like SRP, LSPA, METRIC, 627 etc., are allowed to be inserted. 629 Note that the syntax 631 > 633 , simply means that this is PATH-ATTRIB object with Path ID field set 634 to "1" and with a MULTIPATH-WEIGHT TLV carrying weight of "W1". 636 7.2. Two Primary Paths Protected by One Backup Path 638 Suppose there are 3 paths: A, B, C. Where A,B are primary and C is 639 to be used only when A or B fail. Suppose the Path IDs for A, B, C 640 are respectively 1, 2, 3. This would be encoded in a state-report 641 as: 643 = 644 645 646 647 > 648 649 > 650 651 > 652 654 Note that the syntax 656 > 658 , simply means that this is PATH-ATTRIB object with Path ID field set 659 to "1" and with a MULTIPATH-BACKUP TLV that has B-flag cleared and 660 contains a single backup path with Backup Path ID of 3. 662 7.3. Composite Candidate Path 664 Consider the following Composite Candidate Path, taken from 665 [I-D.ietf-spring-segment-routing-policy]. 667 SR policy POL100 668 Candidate-path CP1 670 Preference 200 671 Weight W1, SR policy 672 Weight W2, SR policy 674 This is signaled in PCEP as: 676 677 678 679 681 > 682 683 685 > 686 688 7.4. Opposite Direction Tunnels 690 Consider the two opposite-direction SR Policies between end-points H1 691 and E1. 693 SR policy POL1 694 Candidate-path CP1 695 Preference 200 696 Bidirectional Association = A1 697 SID-List = 698 SID-List = 699 Candidate-path CP2 700 Preference 100 701 Bidirectional Association = A2 702 SID-List = 703 SID-List = 705 SR policy POL2 706 Candidate-path CP1 707 Preference 200 708 Bidirectional Association = A1 709 SID-List = 710 SID-List = 711 Candidate-path CP2 712 Preference 100 713 Bidirectional Association = A2 714 SID-List = 716 The state-report for POL1, CP1 can be encoded as: 718 = 719 720 721 > 723 > 724 > 726 > 727 > 729 > 730 > 732 > 734 The state-report for POL1, CP2 can be encoded as: 736 = 737 738 739 > 741 > 742 > 744 > 745 > 747 > 749 The state-report for POL2, CP1 can be encoded as: 751 = 752 753 754 > 756 > 757 > 759 > 760 > 762 > 763 > 765 > 767 The state-report for POL2, CP2 can be encoded as: 769 = 770 771 772 > 774 > 775 > 777 > 778 > 780 > 782 8. Implementation Status 784 Note to the RFC Editor - remove this section before publication, as 785 well as remove the reference to [RFC7942]. 787 This section records the status of known implementations of the 788 protocol defined by this specification at the time of posting of this 789 Internet-Draft, and is based on a proposal described in [RFC7942]. 790 The description of implementations in this section is intended to 791 assist the IETF in its decision processes in progressing drafts to 792 RFCs. Please note that the listing of any individual implementation 793 here does not imply endorsement by the IETF. Furthermore, no effort 794 has been spent to verify the information presented here that was 795 supplied by IETF contributors. This is not intended as, and must not 796 be construed to be, a catalog of available implementations or their 797 features. Readers are advised to note that other implementations may 798 exist. 800 According to [RFC7942], "this will allow reviewers and working groups 801 to assign due consideration to documents that have the benefit of 802 running code, which may serve as evidence of valuable experimentation 803 and feedback that have made the implemented protocols more mature. 804 It is up to the individual working groups to use this information as 805 they see fit". 807 8.1. Cisco Systems 809 Organization: Cisco Systems 810 Implementation: IOS-XR PCC and PCE 811 Description: Circuit-Style SR Policies 812 Maturity Level: Supported feature 813 Coverage: Multiple Segment-Lists and reverse paths in SR Policy 814 Contact: mkoldych@cisco.com 816 8.2. Ciena Corp 818 Organization: Ciena Corp 819 Implementation: Head-end and controller 820 Maturity Level: Proof of concept 821 Coverage: Full 822 Contact: byadav@ciena.com 824 9. IANA Considerations 826 9.1. PCEP Object 828 IANA is requested to make the assignment of a new value for the 829 existing "PCEP Objects" registry as follows: 831 +--------------+-------------+-------------------+-----------------+ 832 | Object-Class | Name | Object-Type | Reference | 833 | Value | | Value | | 834 +--------------+-------------+-------------------+-----------------+ 835 | TBD2 | PATH-ATTRIB | 1 | This document | 836 +--------------+-------------+-------------------+-----------------+ 838 9.2. PCEP TLV 840 IANA is requested to make the assignment of a new value for the 841 existing "PCEP TLV Type Indicators" registry as follows: 843 +------------+-----------------------------------+-----------------+ 844 | TLV Type | TLV Name | Reference | 845 | Value | | | 846 +------------+-----------------------------------+-----------------+ 847 | TBD1 | MULTIPATH-CAP | This document | 848 +------------+-----------------------------------+-----------------+ 849 | TBD3 | MULTIPATH-WEIGHT | This document | 850 +------------+-----------------------------------+-----------------+ 851 | TBD4 | MULTIPATH-BACKUP | This document | 852 +------------+-----------------------------------+-----------------+ 853 | TBD9 | MULTIPATH-OPPDIR-PATH | This document | 854 +------------+-----------------------------------+-----------------+ 856 9.3. PCEP-Error Object 858 IANA is requested to make the assignment of a new value for the 859 existing "PCEP-ERROR Object Error Types and Values" sub-registry of 860 the PCEP Numbers registry for the following errors: 862 +------------+-----------------------------------+-----------------+ 863 | Error-Type | Error-Value | Reference | 864 +------------+-----------------------------------+-----------------+ 865 | 10 | TBD5 - Conflicting Path ID | This document | 866 +------------+-----------------------------------+-----------------+ 867 | 19 | TBD7 - Not supported path backup | This document | 868 +------------+-----------------------------------+-----------------+ 869 | 19 | TBD8 - Non-empty path | This document | 870 +------------+-----------------------------------+-----------------+ 872 9.4. Flags in the Multipath Capability TLV 874 IANA is requested to create a new sub-registry to manage the Flag 875 field of the MULTIPATH-CAP TLV, called "Flags in MULTIPATH-CAP TLV". 876 New values are to be assigned by Standards Action [RFC8126] 877 +------------+-----------------------------------+-----------------+ 878 | Bit | Description | Reference | 879 +------------+-----------------------------------+-----------------+ 880 | 0-12 | Unassigned | This document | 881 +------------+-----------------------------------+-----------------+ 882 | 13 | 0-flag: support for processing | This document | 883 | | MULTIPATH-OPPDIR-PATH TLV | | 884 +------------+-----------------------------------+-----------------+ 885 | 14 | B-flag: support for processing | This document | 886 | | MULTIPATH-BACKUP TLV | | 887 +------------+-----------------------------------+-----------------+ 888 | 15 | W-flag: support for processing | This document | 889 | | MULTIPATH-WEIGHT TLV | | 890 +------------+-----------------------------------+-----------------+ 892 9.5. Flags in the Path Attribute Object 894 IANA is requested to create a new sub-registry to manage the Flag 895 field of the PATH-ATTRIBUTE object, called "Flags in PATH-ATTRIBUTE 896 Object". New values are to be assigned by Standards Action [RFC8126] 898 +------------+-----------------------------------+-----------------+ 899 | Bit | Description | Reference | 900 +------------+-----------------------------------+-----------------+ 901 | 0-12 | Unassigned | This document | 902 +------------+-----------------------------------+-----------------+ 903 | 13-15 | O-flag: Operational state | This document | 904 +------------+-----------------------------------+-----------------+ 906 9.6. Flags in the Multipath Backup TLV 908 IANA is requested to create a new sub-registry to manage the Flag 909 field of the MULTIPATH-BACKUP TLV, called "Flags in MULTIPATH-BACKUP 910 TLV". New values are to be assigned by Standards Action [RFC8126] 912 +------------+-----------------------------------+-----------------+ 913 | Bit | Description | Reference | 914 +------------+-----------------------------------+-----------------+ 915 | 0-14 | Unassigned | This document | 916 +------------+-----------------------------------+-----------------+ 917 | 15 | B-flag: Pure backup | This document | 918 +------------+-----------------------------------+-----------------+ 920 9.7. Flags in the Multipath Opposite Direction Path TLV 922 IANA is requested to create a new sub-registry to manage the flag 923 fields of the MULTIPATH-OPPDIR-PATH TLV, called "Flags in the 924 MULTIPATH-OPPDIR-PATH TLV". New values are to be assigned by 925 Standards Action [RFC8126] 927 +------------+-----------------------------------+-----------------+ 928 | Bit | Description | Reference | 929 +------------+-----------------------------------+-----------------+ 930 | 0-12 | Unassigned | This document | 931 +------------+-----------------------------------+-----------------+ 932 | 14 | L-flag: Link co-routed | This document | 933 +------------+-----------------------------------+-----------------+ 934 | 15 | N-flag: Node co-routed | This document | 935 +------------+-----------------------------------+-----------------+ 937 10. Security Considerations 939 None at this time. 941 11. Acknowledgement 943 Thanks to Dhruv Dhody for ideas and discussion. 945 12. Contributors 947 Andrew Stone 948 Nokia 950 Email: andrew.stone@nokia.com 952 13. References 954 13.1. Normative References 956 [I-D.draft-rajagopalan-pce-pcep-color] 957 Rajagopalan, B., Beeram, V. P., Peng, S., Xiong, Q., 958 Koldychev, M., and G. Mishra, "Path Computation Element 959 Protocol(PCEP) Extension for Color", Work in Progress, 960 Internet-Draft, draft-rajagopalan-pce-pcep-color-01, 14 961 November 2021, . 964 [I-D.ietf-pce-segment-routing-policy-cp] 965 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 966 Bidgoli, "PCEP extension to support Segment Routing Policy 967 Candidate Paths", Work in Progress, Internet-Draft, draft- 968 ietf-pce-segment-routing-policy-cp-06, 22 October 2021, 969 . 972 [I-D.ietf-spring-segment-routing-policy] 973 Filsfils, C., Talaulikar, K., Voyer, D., Bogdanov, A., and 974 P. Mattes, "Segment Routing Policy Architecture", Work in 975 Progress, Internet-Draft, draft-ietf-spring-segment- 976 routing-policy-22, 22 March 2022, 977 . 980 [I-D.koldychev-pce-operational] 981 Koldychev, M., Sivabalan, S., Peng, S., Achaval, D., and 982 H. Kotni, "PCEP Operational Clarification", Work in 983 Progress, Internet-Draft, draft-koldychev-pce-operational- 984 05, 19 February 2022, . 987 [I-D.schmutzer-pce-cs-sr-policy] 988 Schmutzer, C., Filsfils, C., Ali, Z., Clad, F., and P. 989 Maheshwari, "Circuit Style Segment Routing Policies", Work 990 in Progress, Internet-Draft, draft-schmutzer-pce-cs-sr- 991 policy-01, 7 March 2022, . 994 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 995 Requirement Levels", BCP 14, RFC 2119, 996 DOI 10.17487/RFC2119, March 1997, 997 . 999 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1000 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 1001 DOI 10.17487/RFC5440, March 2009, 1002 . 1004 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1005 Code: The Implementation Status Section", BCP 205, 1006 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1007 . 1009 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1010 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1011 May 2017, . 1013 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 1014 Computation Element Communication Protocol (PCEP) 1015 Extensions for Stateful PCE", RFC 8231, 1016 DOI 10.17487/RFC8231, September 2017, 1017 . 1019 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1020 Computation Element Communication Protocol (PCEP) 1021 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1022 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1023 . 1025 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 1026 and J. Hardwick, "Path Computation Element Communication 1027 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 1028 DOI 10.17487/RFC8664, December 2019, 1029 . 1031 13.2. Informative References 1033 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 1034 Computation Element (PCE)-Based Architecture", RFC 4655, 1035 DOI 10.17487/RFC4655, August 2006, 1036 . 1038 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 1039 Writing an IANA Considerations Section in RFCs", BCP 26, 1040 RFC 8126, DOI 10.17487/RFC8126, June 2017, 1041 . 1043 [RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., 1044 and M. Negi, "Path Computation Element Communication 1045 Protocol (PCEP) Extensions for Associating Working and 1046 Protection Label Switched Paths (LSPs) with Stateful PCE", 1047 RFC 8745, DOI 10.17487/RFC8745, March 2020, 1048 . 1050 Authors' Addresses 1052 Mike Koldychev 1053 Cisco Systems, Inc. 1054 Email: mkoldych@cisco.com 1056 Siva Sivabalan 1057 Ciena Corporation 1058 Email: ssivabal@ciena.com 1059 Tarek Saad 1060 Juniper Networks, Inc. 1061 Email: tsaad@juniper.net 1063 Vishnu Pavan Beeram 1064 Juniper Networks, Inc. 1065 Email: vbeeram@juniper.net 1067 Hooman Bidgoli 1068 Nokia 1069 Email: hooman.bidgoli@nokia.com 1071 Bhupendra Yadav 1072 Ciena 1073 Email: byadav@ciena.com 1075 Shuping Peng 1076 Huawei Technologies 1077 Email: pengshuping@huawei.com 1079 Gyan Mishra 1080 Verizon Inc. 1081 Email: gyan.s.mishra@verizon.com