idnits 2.17.1 draft-koldychev-pce-multipath-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 06, 2020) is 1383 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-00 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-07 == Outdated reference: A later version (-07) exists of draft-koldychev-pce-operational-01 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: January 7, 2021 Ciena Corporation 6 T. Saad 7 V. Beeram 8 Juniper Networks, Inc. 9 H. Bidgoli 10 Nokia 11 B. Yadav 12 Ciena 13 S. Peng 14 Huawei Technologies 15 July 06, 2020 17 PCEP Extensions for Signaling Multipath Information 18 draft-koldychev-pce-multipath-03 20 Abstract 22 Current PCEP standards allow only one intended and/or actual path to 23 be present in a PCEP report or update. Applications that require 24 multipath support such as SR Policy require an extension to allow 25 signaling multiple intended and/or actual paths within a single PCEP 26 message. This document introduces such an extension. Encoding of 27 multiple intended and/or actual paths is done by encoding multiple 28 Explicit Route Objects (EROs) and/or multiple Record Route Objects 29 (RROs). A special separator object is defined in this document, to 30 facilitate this. This mechanism is applicable to SR-TE and RSVP-TE 31 and is dataplane agnostic. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 7, 2021. 50 Copyright Notice 52 Copyright (c) 2020 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (https://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 70 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 4 72 3.2. Splitting of Requested Bandwidth . . . . . . . . . . . . 4 73 3.3. Providing Backup path for Protection . . . . . . . . . . 4 74 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5 75 4.1. Multipath Capability TLV . . . . . . . . . . . . . . . . 5 76 4.2. Path Attributes Object . . . . . . . . . . . . . . . . . 6 77 4.3. Multipath Weight TLV . . . . . . . . . . . . . . . . . . 6 78 4.4. Multipath Backup TLV . . . . . . . . . . . . . . . . . . 7 79 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 80 5.1. Signaling Multiple Paths for Loadbalancing . . . . . . . 9 81 5.2. Signaling Multiple Paths for Protection . . . . . . . . . 9 82 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 10 83 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 7.1. SR Policy Candidate-Path with Multiple Segment-Lists . . 10 85 7.2. Two Primary Paths Protected by One Backup Path . . . . . 12 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 88 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 13 89 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 90 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 92 12.2. Informative References . . . . . . . . . . . . . . . . . 14 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 95 1. Introduction 97 Path Computation Element (PCE) Communication Protocol (PCEP) 98 [RFC5440] enables the communication between a Path Computation Client 99 (PCC) and a Path Control Element (PCE), or between two PCEs based on 100 the PCE architecture [RFC4655]. 102 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 103 of extensions to PCEP that enable active control of Multiprotocol 104 Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS 105 (GMPLS) tunnels. [RFC8281] describes the setup and teardown of PCE- 106 initiated LSPs under the active stateful PCE model, without the need 107 for local configuration on the PCC, thus allowing for dynamic 108 centralized control of a network. 110 PCEP Extensions for Segment Routing [RFC8664] specifies extensions to 111 the Path Computation Element Protocol (PCEP) that allow a stateful 112 PCE to compute and initiate Traffic Engineering (TE) paths, as well 113 as for a PCC to request a path subject to certain constraint(s) and 114 optimization criteria in SR networks. 116 Segment Routing Policy for Traffic Engineering 117 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 118 Policy and approaches to steering traffic into an SR Policy. In 119 particular, it describes the SR candidate-path as a collection of one 120 or more Segment-Lists. The current PCEP standards only allow for 121 signaling of one Segment-List per Candidate-Path. PCEP extension to 122 support Segment Routing Policy Candidate Paths 123 [I-D.ietf-pce-segment-routing-policy-cp] specifically avoids defining 124 how to signal multipath information, and states that this will be 125 defined in another document. 127 This document defines the required extensions that allow the 128 signaling of multipath information via PCEP. 130 2. Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 2.1. Terms and Abbreviations 140 The following terms are used in this document: 142 PCEP Tunnel: 144 The object identified by the PLSP-ID, see 145 [I-D.koldychev-pce-operational] for more details. 147 3. Motivation 149 This extension is motivated by the use-cases described below. 151 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 153 The Candidate-Path of an SR Policy is the unit of report/update in 154 PCEP, see [I-D.ietf-pce-segment-routing-policy-cp]. Each Candidate- 155 Path can contain multiple Segment-Lists and each Segment-List is 156 encoded by one ERO. However, each PCEP LSP can contain only a single 157 ERO (containing multiple SR-ERO subobject), which prevents us from 158 encoding multiple Segment- Lists within the same SR Candidate-Path. 160 With the help of the protocol extensions defined in this document, 161 this limitation is overcome. 163 3.2. Splitting of Requested Bandwidth 165 A PCC may request a path with 80 Gbps of bandwidth, but all links in 166 the network have only 50 Gbps capacity. The PCE can return two 167 paths, that can together carry 80 Gbps. The PCC can then equally or 168 unequally split the incoming 80 Gbps of traffic among the two paths. 169 Section 4.3 introduces a new TLV that carries the path weight that 170 allows for distribution of incoming traffic on to the multiple paths. 172 3.3. Providing Backup path for Protection 174 It is desirable for the PCE to compute and signal to the PCC a backup 175 path that is used to protect a primary path within the multipaths in 176 a given LSP. 178 Note that [RFC8745] specify the Path Protection association among 179 LSPs. The use of [RFC8745] with multipath is out of scope of this 180 document and is for future study. 182 When multipath is used, a backup path may protect one or more primary 183 paths. For this reason, primary and backup path identifiers are 184 needed to indicate which backup path(s) protect which primary 185 path(s). Section 4.4 introduces a new TLV that carries the required 186 information. 188 4. Protocol Extensions 190 4.1. Multipath Capability TLV 192 We define the MULTIPATH-CAP TLV that MAY be present in the OPEN 193 object and/or the LSP object. The purpose of this TLV is two-fold: 195 1. From PCC: it tells how many multipaths per PCEP Tunnel, the PCC 196 can install in forwarding. 198 2. From PCE: it tells that the PCE supports this standard and how 199 many multipaths per PCEP Tunnel, the PCE can compute. 201 Only the first instance of this TLV can be processed, subsequent 202 instances SHOULD be ignored. 204 Section 5 specify the usage of this TLV with Open message (within the 205 OPEN object) and other PCEP messages (within the LSP object). 207 0 1 2 3 208 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 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Type | Length | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Number of Multipaths | Flags |B|W| 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 Figure 1: MULTIPATH-CAP TLV format 217 Type: TBD1 for "MULTIPATH-CAP" TLV. 219 Length: 4. 221 Number of Multipaths: the maximum number of multipaths per PCEP 222 Tunnel. The value 0 indicates unlimited number. 224 Flags: Following bits are defined: 226 W-flag: whether MULTIPATH-WEIGHT-TLV is supported. 228 B-flag: whether MULTIPATH-BACKUP-TLV is supported. 230 Unassigned bits are for future use. They MUST be set to 0 on 231 transmission and MUST be ignored on receipt. 233 4.2. Path Attributes Object 235 We define the PATH-ATTRIB object that is used to carry per-path 236 information and to act as a separator between several ERO/RRO objects 237 in the intended-path/actual-path RBNF element. The PATH-ATTRIB 238 object always precedes the ERO/RRO that it applies to. If multiple 239 ERO/RRO objects are present, then each ERO/RRO object MUST be 240 preceded by an PATH-ATTRIB object that describes it. 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Flags | O | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Path ID | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 ~ Optional TLVs ~ 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 Figure 2: PATH-ATTRIB object format 254 Flags (32-bits): Following bits are assigned - 256 O (Operational - 3 bits): operational state of the path, same 257 values as the identically named field in the LSP object {{RFC8231}}. 259 Unassigned bits are for future use. They MUST be set to 0 on 260 transmission and MUST be ignored on receipt. 262 Path ID: 4-octet identifier that identifies a path in the set of 263 multiple paths. It uniquely identifies a path (encoded in the ERO/ 264 RRO) within the set of multiple paths under the PCEP LSP. Once a 265 path changes, a new Path ID is assigned. 267 TLVs that may be included in the PATH-ATTRIB object are described in 268 the following sections. Other optional TLVs could be defined by 269 future documents to be included within the PATH-ATTRIB object body. 271 4.3. Multipath Weight TLV 273 We define the MULTIPATH-WEIGHT TLV that MAY be present in the PATH- 274 ATTRIB object. 276 0 1 2 3 277 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 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Type | Length | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 | Weight | 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 Figure 3: MULTIPATH-WEIGHT TLV format 286 Type: TBD2 for "MULTIPATH-WEIGHT" TLV. 288 Length: 4. 290 Weight: weight of this path within the multipath, if W-ECMP is 291 desired. The fraction of flows a specific ERO/RRO carries is derived 292 from the ratio of its weight to the sum of all other multipath ERO/ 293 RRO weights. 295 4.4. Multipath Backup TLV 297 This document introduces a new MULTIPATH-BACKUP TLV that is optional 298 and can be present in the PATH-ATTRIB object. 300 This TLV is used to indicate the presence of a backup path that is 301 used for protection in case of failure of the primary path. The 302 format of the MULTIPATH-BACKUP TLV is: 304 0 1 2 3 305 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 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Type | Length | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Backup Path Count | Flags |B| 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Backup Path ID 1 | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Backup Path ID 2 | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | ... | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Backup Path ID n | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 Figure 4: MULTIPATH-BACKUP TLV format 322 Type: TBD3 for "MULTIPATH-BACKUP" TLV 323 Length: 4 + (N * 4) (where N is the Backup Path Count) 325 Backup Path Count: Number of backup path(s). 327 Flags (16 bits): a flag field. Currently a single flag "B bit" is 328 defined. 329 Unused flags MUST be set to zero while sending and ignored on 330 receipt. 332 B: If set, indicates a pure backup path. This is a path that only 333 carries rerouted traffic after the protected path fails. If this flag 334 is not set, or if the MULTIPATH-BACKUP TLV is not carried in the PATH-ATTRIB 335 object of an ERO or SERO, then the path is assumed to be primary that 336 carries normal traffic. 338 Backup Path ID(s): a series of 4-octet identifier(s) that identify 339 the backup path(s) in the set that protect this primary path. 341 5. Operation 343 When the PCC wants to indicate to the PCE that it wants to get 344 multipaths for a PCEP Tunnel, instead of a single path, it can do (1) 345 or both (1) and (2) of the following: 347 (1) Send the MULTIPATH-CAP TLV in the OPEN object during session 348 establishment. This applies to all PCEP Tunnels on the PCC, unless 349 overridden by PCEP Tunnel specific information. 351 (2) Additionally send the MULTIPATH-CAP TLV in the LSP object for a 352 particular PCEP Tunnel in the PCRpt or PCReq message. This applies 353 to the specified PCEP Tunnel and overrides the information from the 354 OPEN object. 356 When PCE computes the path for a PCEP Tunnel, it MUST NOT return more 357 multipaths than the corresponding value of "Number of Multipaths" 358 from the MULTIPATH-CAP TLV. If this TLV is absent (from both OPEN 359 and LSP objects), then the "Number of Multipaths" is assumed to be 1. 361 If the PCE supports this standard, then it MUST include the 362 MULTIPATH-CAP TLV in the OPEN object. This tells the PCC that it can 363 report multiple ERO/RRO objects per PCEP Tunnel to this PCE. If the 364 PCE does not include the MULTIPATH-CAP TLV in the OPEN object, then 365 the PCC MUST assume that the PCE does not support this standard and 366 fall back to reporting only a single ERO/RRO. The PCE MUST NOT 367 include MULTIPATH-CAP TLV in the LSP object in any other PCEP message 368 towards the PCC and the PCC MUST ignore it if received. 370 The Path ID of each ERO/RRO MUST be unique within that LSP. If a 371 PCEP speaker detects that there are two paths with the same Path ID, 372 then the PCEP speaker SHOULD send PCError message with Error-Type = 1 373 ("Reception of an invalid object") and Error-Value = TBD4 374 ("Conflicting Path ID"). 376 5.1. Signaling Multiple Paths for Loadbalancing 378 The PATH-ATTRIB object can be used to signal multiple path(s) and 379 indicate (un)equal loadbalancing amongst the set of multipaths. In 380 this case, the PATH-ATTRIB is populated for each ERO or SERO as 381 follows: 383 1. The PCE assigns a unique Path ID to each ERO or SERO path and 384 populates it inside the PATH-ATTRIB object. The Path ID is 385 unique within the context of a PLSP or PCEP Tunnel. 387 2. The MULTIPATH-WEIGHT TLV MAY be carried inside the PATH-ATTRIB 388 object. A weight is populated to reflect the relative loadshare 389 that is to be carried by the path. If the MULTIPATH-WEIGHT is 390 not carried inside a PATH-ATTRIB object, the default weight 1 391 MUST be assumed when computing the loadshare. 393 3. The fraction of flows carried by a specific primary path is 394 derived from the ratio of its weight to the sum of all other 395 multipath weights. 397 5.2. Signaling Multiple Paths for Protection 399 The PATH-ATTRIB object can be used to describe a set of backup 400 path(s) protecting a primary path within a PCEP Tunnel. In this 401 case, the PATH-ATTRIB is populated for each ERO or SERO as follows: 403 1. The PCE assigns a unique Path ID to each ERO or SERO path and 404 populates it inside the PATH-ATTRIB object. The Path ID is 405 unique within the context of a PLSP or PCEP Tunnel. 407 2. The MULTIPATH-BACKUP TLV MUST be added inside the PATH-ATTRIB 408 object for each ERO or SERO that is protected. The backup path 409 ID(s) are populated in the MULTIPATH-BACKUP TLV to reflect the 410 set of backup path(s) protecting the primary path. The Length 411 field and Backup Path Number in the MULTIPATH-BACKUP are updated 412 according to the number of backup path ID(s) included. 414 3. The MULTIPATH-BACKUP TLV MAY be added inside the PATH-ATTRIB 415 object for each ERO or SERO that is unprotected. In this case, 416 MULTIPATH-BACKUP does not carry any backup path IDs in the TLV. 417 If the path acts as a pure backup - i.e. the path only carries 418 rerouted traffic after the protected path(s) fail- then the B 419 flag MUST be set. 421 Note that if a given path has the B-flag set, then there MUST be some 422 other path within the same LSP that uses the given path as a backup. 423 If this condition is violated, then the PCEP speaker SHOULD send a 424 PCError message with Error-Type = 10 ("Reception of an invalid 425 object") and Error-Value = TBD5 ("No primary path for pure backup"). 427 Note that a given PCC may not support certain backup combinations, 428 such as a backup path that is itself protected by another backup 429 path, etc. If a PCC is not able to implement a requested backup 430 scenario, the PCC SHOULD send a PCError message with Error-Type = 19 431 ("Invalid Operation") and Error-Value = TBD6 ("Not supported path 432 backup"). 434 6. PCEP Message Extensions 436 The RBNF of PCReq, PCRep, PCRpt, PCUpd and PCInit messages currently 437 use intended-path and/or actual-path: 439 ::= (|) 440 [] 442 ::= (|) 443 [] 445 In this standard, we extend these two elements: 447 ::= ((|)| 448 ((|) 449 [])) 451 ::= ((|)| 452 ((|) 453 [])) 455 7. Examples 457 7.1. SR Policy Candidate-Path with Multiple Segment-Lists 459 Consider how the following sample SR Policy, taken from 460 [I-D.ietf-spring-segment-routing-policy], would be represented in a 461 PCRpt message. 463 SR policy POL1 464 Candidate-path CP1 466 Preference 200 467 Weight W1, SID-List1 468 Weight W2, SID-List2 469 Candidate-path CP2 471 Preference 100 472 Weight W3, SID-List3 473 Weight W4, SID-List4 475 As specified in [I-D.ietf-pce-segment-routing-policy-cp], CP1 and CP2 476 are signaled as separate state-report elements and each has a unique 477 PLSP-ID, assigned by the PCC. Let us assign PLSP-ID 100 to CP1 and 478 PLSP-ID 200 to CP2. 480 The state-report for CP1 can be encoded as: 482 = 483 484 485 486 > 487 488 > 489 491 The state-report for CP2 can be encoded as: 493 = 494 495 496 497 > 498 499 > 500 502 The above sample state-report elements only specify the minimum 503 mandatory objects, of course other objects like SRP, LSPA, METRIC, 504 etc., are allowed to be inserted. 506 Note that the syntax 508 > 509 , simply means that this is PATH-ATTRIB object with Path ID field set 510 to "1" and with a MULTIPATH-WEIGHT TLV carrying weight of "W1". 512 7.2. Two Primary Paths Protected by One Backup Path 514 Suppose there are 3 paths: A, B, C. Where A,B are primary and C is 515 to be used only when A or B fail. Suppose the Path IDs for A, B, C 516 are respectively 1, 2, 3. This would be encoded in a state-report 517 as: 519 = 520 521 522 523 > 524 525 > 526 527 > 528 530 Note that the syntax 532 > 534 , simply means that this is PATH-ATTRIB object with Path ID field set 535 to "1" and with a MULTIPATH-BACKUP TLV that has B-flag cleared and 536 contains a single backup path with Backup Path ID of 3. 538 8. IANA Considerations 540 IANA is requested to make the assignment of a new value for the 541 existing "PCEP TLV Type Indicators" registry as follows: 543 +------------+-----------------------------------+-----------------+ 544 | TLV Type | TLV Name | Reference | 545 | Value | | | 546 +------------+-----------------------------------+-----------------+ 547 | TBD1 | MULTIPATH-CAP | This document | 548 +------------+-----------------------------------+-----------------+ 549 | TBD2 | MULTIPATH-WEIGHT | This document | 550 +------------+-----------------------------------+-----------------+ 551 | TBD3 | MULTIPATH-BACKUP | This document | 552 +------------+-----------------------------------+-----------------+ 554 IANA is requested to make the assignment of a new value for the 555 existing "PCEP-ERROR Object Error Types and Values" registry as 556 follows: 558 +------------+-----------------------------------+-----------------+ 559 | Error-Type | Error-Value | Reference | 560 +------------+-----------------------------------+-----------------+ 561 | 10 | TBD4 - Conflicting Path ID | This document | 562 +------------+-----------------------------------+-----------------+ 563 | 10 | TBD5 - No primary path for pure | This document | 564 | | backup | | 565 +------------+-----------------------------------+-----------------+ 566 | 19 | TBD6 - Not supported path backup | This document | 567 +------------+-----------------------------------+-----------------+ 569 9. Security Considerations 571 None at this time. 573 10. Acknowledgement 575 Thanks to Dhruv Dhody for ideas and discussion. 577 11. Contributors 579 Andrew Stone 580 Nokia 582 Email: andrew.stone@nokia.com 584 12. References 586 12.1. Normative References 588 [I-D.ietf-pce-segment-routing-policy-cp] 589 Koldychev, M., Sivabalan, S., Barth, C., Peng, S., and H. 590 Bidgoli, "PCEP extension to support Segment Routing Policy 591 Candidate Paths", draft-ietf-pce-segment-routing-policy- 592 cp-00 (work in progress), June 2020. 594 [I-D.ietf-spring-segment-routing-policy] 595 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 596 P. Mattes, "Segment Routing Policy Architecture", draft- 597 ietf-spring-segment-routing-policy-07 (work in progress), 598 May 2020. 600 [I-D.koldychev-pce-operational] 601 Koldychev, M., Sivabalan, S., Negi, M., Achaval, D., and 602 H. Kotni, "PCEP Operational Clarification", draft- 603 koldychev-pce-operational-01 (work in progress), February 604 2020. 606 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 607 Requirement Levels", BCP 14, RFC 2119, 608 DOI 10.17487/RFC2119, March 1997, 609 . 611 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 612 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 613 DOI 10.17487/RFC5440, March 2009, 614 . 616 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 617 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 618 May 2017, . 620 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 621 Computation Element Communication Protocol (PCEP) 622 Extensions for Stateful PCE", RFC 8231, 623 DOI 10.17487/RFC8231, September 2017, 624 . 626 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 627 Computation Element Communication Protocol (PCEP) 628 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 629 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 630 . 632 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 633 and J. Hardwick, "Path Computation Element Communication 634 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 635 DOI 10.17487/RFC8664, December 2019, 636 . 638 12.2. Informative References 640 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 641 Element (PCE)-Based Architecture", RFC 4655, 642 DOI 10.17487/RFC4655, August 2006, 643 . 645 [RFC8745] Ananthakrishnan, H., Sivabalan, S., Barth, C., Minei, I., 646 and M. Negi, "Path Computation Element Communication 647 Protocol (PCEP) Extensions for Associating Working and 648 Protection Label Switched Paths (LSPs) with Stateful PCE", 649 RFC 8745, DOI 10.17487/RFC8745, March 2020, 650 . 652 Authors' Addresses 654 Mike Koldychev 655 Cisco Systems, Inc. 657 Email: mkoldych@cisco.com 659 Siva Sivabalan 660 Ciena Corporation 662 Email: ssivabal@ciena.com 664 Tarek Saad 665 Juniper Networks, Inc. 667 Email: tsaad@juniper.net 669 Vishnu Pavan Beeram 670 Juniper Networks, Inc. 672 Email: vbeeram@juniper.net 674 Hooman Bidgoli 675 Nokia 677 Email: hooman.bidgoli@nokia.com 679 Bhupendra Yadav 680 Ciena 682 Email: byadav@ciena.com 684 Shuping Peng 685 Huawei Technologies 687 Email: pengshuping@huawei.com