idnits 2.17.1 draft-koldychev-pce-multipath-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 21, 2020) is 1498 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 (-06) exists of draft-barth-pce-segment-routing-policy-cp-04 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-06 == Outdated reference: A later version (-07) exists of draft-koldychev-pce-operational-00 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Koldychev 3 Internet-Draft S. Sivabalan 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 24, 2020 T. Saad 6 V. Beeram 7 Juniper Networks, Inc. 8 H. Bidgoli 9 Nokia 10 B. Yadav 11 Ciena 12 February 21, 2020 14 PCEP Extensions for Signaling Multipath Information 15 draft-koldychev-pce-multipath-01 17 Abstract 19 Current PCEP standards allow only one intended and/or actual path to 20 be present in a PCEP report or update. Applications that require 21 multipath support such as SR Policy require an extension to allow 22 signaling multiple intended and/or actual paths within a single PCEP 23 message. This document introduces such an extension. Encoding of 24 multiple intended and/or actual paths is done by encoding multiple 25 Explicit Route Objects (EROs) and/or multiple Record Route Objects 26 (RROs). A special separator object is defined in this document, to 27 facilitate this. This mechanism is applicable to SR-TE and RSVP-TE 28 and is dataplane agnostic. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on August 24, 2020. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2.1. Terms and Abbreviations . . . . . . . . . . . . . . . . . 3 67 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 4 69 3.2. Splitting of Requested Bandwidth . . . . . . . . . . . . 4 70 3.3. Providing Backup path for Protection . . . . . . . . . . 4 71 4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 4 72 4.1. Multipath Capability TLV . . . . . . . . . . . . . . . . 4 73 4.2. Path Attributes Object . . . . . . . . . . . . . . . . . 5 74 4.3. Multipath Weight TLV . . . . . . . . . . . . . . . . . . 6 75 4.4. Multipath Backup TLV . . . . . . . . . . . . . . . . . . 7 76 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 5.1. Signaling Multiple Paths for Loadbalancing . . . . . . . 8 78 5.2. Signaling Multiple Paths for Protection . . . . . . . . . 9 79 6. PCEP Message Extensions . . . . . . . . . . . . . . . . . . . 9 80 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 7.1. SR Policy Candidate-Path with Multiple Segment-Lists . . 10 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 84 10. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 11 85 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 88 12.2. Informative References . . . . . . . . . . . . . . . . . 12 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 91 1. Introduction 93 Path Computation Element (PCE) Communication Protocol (PCEP) 94 [RFC5440] enables the communication between a Path Computation Client 95 (PCC) and a Path Control Element (PCE), or between two PCEs based on 96 the PCE architecture [RFC4655]. 98 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 99 of extensions to PCEP that enable active control of Multiprotocol 100 Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS 101 (GMPLS) tunnels. [RFC8281] describes the setup and teardown of PCE- 102 initiated LSPs under the active stateful PCE model, without the need 103 for local configuration on the PCC, thus allowing for dynamic 104 centralized control of a network. 106 PCEP Extensions for Segment Routing [I-D.ietf-pce-segment-routing] 107 specifies extensions to the Path Computation Element Protocol (PCEP) 108 that allow a stateful PCE to compute and initiate Traffic Engineering 109 (TE) paths, as well as for a PCC to request a path subject to certain 110 constraint(s) and optimization criteria in SR networks. 112 Segment Routing Policy for Traffic Engineering 113 [I-D.ietf-spring-segment-routing-policy] details the concepts of SR 114 Policy and approaches to steering traffic into an SR Policy. In 115 particular, it describes the SR candidate-path as a collection of one 116 or more Segment-Lists. The current PCEP standards only allow for 117 signaling of one Segment-List per Candidate-Path. PCEP extension to 118 support Segment Routing Policy Candidate Paths 119 [I-D.barth-pce-segment-routing-policy-cp] specifically avoids 120 defining how to signal multipath information, and states that this 121 will be defined in another document. 123 This document defines the required extensions that allow the 124 signaling of multipath information via PCEP. 126 2. Terminology 128 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 129 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 130 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 131 [RFC2119]. 133 2.1. Terms and Abbreviations 135 The following terms are used in this document: 137 PCEP Tunnel: 139 The object identified by the PLSP-ID, see 140 [I-D.koldychev-pce-operational] for more details. 142 3. Motivation 144 This extension is motivated by the use-cases described below. 146 3.1. Signaling Multiple Segment-Lists of an SR Candidate-Path 148 The Candidate-Path of an SR Policy is the unit of report/update in 149 PCEP, see [I-D.barth-pce-segment-routing-policy-cp]. Each Candidate- 150 Path can contain multiple Segment-Lists and each Segment-List is 151 encoded by one SR-ERO object. However, each PCEP LSP can contain 152 only a single SR-ERO object, which prevents us from encoding multiple 153 Segment- Lists within the same SR Candidate-Path. 155 With the help of the protocol extensions defined in this document, 156 this limitation is overcome. 158 3.2. Splitting of Requested Bandwidth 160 A PCC may request a path with 100 Gbps of bandwidth, but all links in 161 the network have only 50 Gbps capacity. The PCE can return two 162 paths, that can each carry 50 Gbps. The PCC can then equally or 163 unequally split the incoming 100 Gbps of traffic among the two 50 164 Gbps paths. Section 4.3 introduces a new TLV that carries the path 165 weight that allows for distribution of incoming traffic on to the 166 multiple paths. 168 3.3. Providing Backup path for Protection 170 It is desirable for the PCE to compute and signal to the PCC a backup 171 path that is used to protect a primary path. 173 When multipath is used, a backup path may protect one or more primary 174 paths. For this reason, a primary and backup path identifiers are 175 needed to indicate which backup path(s) protect which primary 176 path(s). Section 4.4 introduces a new TLV that carries the required 177 information. 179 4. Protocol Extensions 181 4.1. Multipath Capability TLV 183 We define the MULTIPATH-CAP TLV that MAY be present in the OPEN 184 object and/or the LSP object. The purpose of this TLV is two-fold: 186 1. From PCC: it tells how many multipaths the PCC can install in 187 forwarding. 189 2. From PCE: it tells that the PCE supports this standard and how 190 many multipaths the PCE can compute. 192 Only the first instance of this TLV can be processed, subsequent 193 instances SHOULD be ignored. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type | Length | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Number of Multipaths | Reserved |B|W| 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 Figure 1: MULTIPATH-CAP TLV format 205 Type: TBD1 for "MULTIPATH-CAP" TLV. 207 Length: 4. 209 Number of Multipaths: the maximum number of multipaths that a PCE can 210 return. The value 0 indicates unlimited number. 212 B-flag: whether MULTIPATH-BACKUP-TLV is supported. 214 W-flag: whether MULTIPATH-WEIGHT-TLV is supported. 216 Reserved: zero on transmit, ignore on receipt. 218 4.2. Path Attributes Object 220 We define the PATH-ATTRIB object that is used to carry per-path 221 information and to act as a separator between several ERO/RRO objects 222 in the intended-path/actual-path RBNF element. The PATH-ATTRIB 223 object always precedes the ERO/RRO that it applies to. If multiple 224 ERO/RRO objects are present, then each ERO/RRO object MUST be 225 preceded by an PATH-ATTRIB object that describes it. 227 0 1 2 3 228 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 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Flags | Oper| 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Path ID. | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 ~ Optional TLVs ~ 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 Figure 2: PATH-ATTRIB object format 239 Flags: to be extended in the future. 241 Oper: operational state of the path, same values as the identically 242 named field in the LSP object. 244 Path ID: 4-octet identifier that identifies a path in the set of 245 multiple paths. 247 4.3. Multipath Weight TLV 249 We define the MULTIPATH-WEIGHT TLV that MAY be present in the PATH- 250 ATTRIB object. 252 0 1 2 3 253 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Type | Length | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Weight | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 Figure 3: MULTIPATH-WEIGHT TLV format 262 Type: TBD2 for "MULTIPATH-WEIGHT" TLV. 264 Length: 4. 266 Weight: weight of this path within the multipath, if W-ECMP is 267 desired. The fraction of flows a specific ERO/RRO carries is derived 268 from the ratio of its weight to the sum of all other multipath ERO/ 269 RRO weights. 271 4.4. Multipath Backup TLV 273 This document introduces a new MULTIPATH-BACKUP TLV that is optional 274 and can be present in the PATH-ATTRIB object. 276 This TLV is used to indicate the presence of a backup path that is 277 used for protection in case of failure of the primary path. The 278 format of the MULTIPATH-BACKUP TLV is: 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Type | Length | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Backup Path Number | Flags | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Backup Path ID 1 | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Backup Path ID 2 | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | ... | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Backup Path ID n | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Figure 4: MULTIPATH-BACKUP TLV format 298 Type: TBD3 for "MULTIPATH-BACKUP" TLV 300 Length: variable - multiple of 4-octets 302 Backup Path Number: Number of backup path(s). 304 Flags: 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 |B| Reserved | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 B: If set, indicates a pure backup path. This is a path that only 311 carries rerouted traffic after the protected path fails. If this 312 flag is not set, or if the MULTIPATH-BACKUP TLV is not carried in 313 the PATH-ATTRIB object of an ERO or SERO, then the path is assumed 314 to be primary that carries normal traffic. 316 Backup Path ID(s): a series of 4-octet identifier(s) that identify 317 the backup path(s) in the set that protect this primary path. 319 5. Operation 321 When the PCC wants to indicate to the PCE that it wants to get 322 multipaths instead of a single path, it can do one or both of the 323 following: 325 1. Send the MULTIPATH-CAP TLV in the OPEN object during session 326 establishment. This applies to all PCEP Tunnels on the PCC, 327 unless overridden by PCEP Tunnel specific information. 329 2. Send the MULTIPATH-CAP TLV in the LSP object for a particular 330 PCEP Tunnel in the PCRpt message. This applies to the specified 331 PCEP Tunnel and overrides the information from the OPEN object. 333 When PCE computes the path for a PCEP Tunnel, it MUST NOT return more 334 multipaths than the corresponding value of "Number of Multipaths" 335 from the MULTIPATH-CAP TLV. If this TLV is absent (from both OPEN 336 and LSP objects), then the "Number of Multipaths" is assumed to be 1. 338 If the PCE supports this standard, then it MUST include the 339 MULTIPATH-CAP TLV in the OPEN object. This tells the PCC that it can 340 report multiple ERO/RRO objects to this PCE. If the PCE does not 341 include the MULTIPATH-CAP TLV in the OPEN object, then the PCC MUST 342 assume that the PCE does not support this standard and fall back to 343 reporting only a single ERO/RRO. 345 5.1. Signaling Multiple Paths for Loadbalancing 347 The PATH-ATTRIB object can be used to signal multiple path(s) and 348 indicate (un)equal loadbalancing amongst the set of multipaths. In 349 this case, the PATH-ATTRIB is populated for each ERO or SERO as 350 follows: 352 1. The PCE assigns a unique Path ID to each ERO or SERO path and 353 populates it inside the PATH-ATTRIB object. The Path ID is 354 unique within the context of a PLSP or PCEP Tunnel. 356 2. The MULTIPATH-WEIGHT TLV MAY be carried inside the PATH-ATTRIB 357 object. A weight is populated to reflect the relative loadshare 358 that is to be carried by the path. If the MULTIPATH-WEIGHT is 359 not carried inside a PATH-ATTRIB object, the default weight 1 360 MUST be assumed when computing the loadshare. 362 3. The fraction of flows carried by a specific primary path is 363 derived from the ratio of its weight to the sum of all other 364 multipath weights. 366 5.2. Signaling Multiple Paths for Protection 368 The PATH-ATTRIB object can be used to describe a set of backup 369 path(s) protecting a primary path. In this case, the PATH-ATTRIB is 370 populated for each ERO or SERO as follows: 372 1. The PCE assigns a unique Path ID to each ERO or SERO path and 373 populates it inside the PATH-ATTRIB object. The Path ID is 374 unique within the context of a PLSP or PCEP Tunnel. 376 2. The MULTIPATH-BACKUP TLV MUST be added inside the PATH-ATTRIB 377 object for each ERO or SERO that is protected. The backup path 378 ID(s) are populated in the MULTIPATH-BACKUP TLV to reflect the 379 set of backup path(s) protecting the primary path. The Length 380 field and Backup Path Number in the MULTIPATH-BACKUP are updated 381 according to the number of backup path ID(s) included. 383 3. The MULTIPATH-BACKUP TLV MAY be added inside the PATH-ATTRIB 384 object for each ERO or SERO that is unprotected. In this case, 385 MULTIPATH-BACKUP does not carry any backup path IDs in the TLV. 386 If the path acts as a pure backup - i.e. the path only carries 387 rerouted traffic after the protected path(s) fail- then the B 388 flag MUST be set. 390 6. PCEP Message Extensions 392 The RBNF of PCReq, PCRep, PCRpt, PCUpd and PCInit messages currently 393 use intended-path and/or actual-path: 395 ::= (|) 396 [] 398 ::= (|) 399 [] 401 In this standard, we extend these two elements: 403 ::= [](|) 404 [] 406 ::= [](|) 407 [] 409 7. Examples 410 7.1. SR Policy Candidate-Path with Multiple Segment-Lists 412 Consider how the following sample SR Policy, taken from 413 [I-D.ietf-spring-segment-routing-policy], would be represented in a 414 PCRpt message. 416 SR policy POL1 417 Candidate-path CP1 419 Preference 200 420 Weight W1, SID-List1 421 Weight W2, SID-List2 422 Candidate-path CP2 424 Preference 100 425 Weight W3, SID-List3 426 Weight W4, SID-List4 428 As specified in [I-D.barth-pce-segment-routing-policy-cp], CP1 and 429 CP2 are signaled as separate state-report elements and each has a 430 unique PLSP-ID, assigned by the PCC. Let us assign PLSP-ID 100 to 431 CP1 and PLSP-ID 200 to CP2. 433 The state-report for CP1 can be encoded as: 435 = 436 437 438 439 440 441 443 The state-report for CP2 can be encoded as: 445 = 446 447 448 449 450 451 453 The above sample state-report elements only specify the minimum 454 mandatory objects, of course other objects like SRP, LSPA, METRIC, 455 etc., are allowed to be inserted. 457 Note that the syntax 458 460 , simply means that this is PATH-ATTRIB object with PATH_ID field set 461 to "1" and with a Weight TLV carrying weight of "W1". 463 8. IANA Considerations 465 IANA is requested to make the assignment of a new value for the 466 existing "PCEP TLV Type Indicators" registry as follows: 468 +------------+-----------------------------------+-----------------+ 469 | TLV Type | TLV Name | Reference | 470 | Value | | | 471 +------------+-----------------------------------+-----------------+ 472 | TBD1 | MULTIPATH-CAP | This document | 473 +------------+-----------------------------------+-----------------+ 474 | TBD2 | MULTIPATH-WEIGHT | This document | 475 +------------+-----------------------------------+-----------------+ 476 | TBD3 | MULTIPATH-BACKUP | This document | 477 +------------+-----------------------------------+-----------------+ 479 9. Security Considerations 481 None at this time. 483 10. Acknowledgement 485 Thanks to Dhruv Dhody for ideas and discussion. 487 11. Contributors 489 Andrew Stone 490 Nokia 492 Email: andrew.stone@nokia.com 494 12. References 496 12.1. Normative References 498 [I-D.barth-pce-segment-routing-policy-cp] 499 Koldychev, M., Sivabalan, S., Barth, C., Li, C., and H. 500 Bidgoli, "PCEP extension to support Segment Routing Policy 501 Candidate Paths", draft-barth-pce-segment-routing-policy- 502 cp-04 (work in progress), October 2019. 504 [I-D.ietf-pce-segment-routing] 505 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 506 and J. Hardwick, "PCEP Extensions for Segment Routing", 507 draft-ietf-pce-segment-routing-16 (work in progress), 508 March 2019. 510 [I-D.ietf-spring-segment-routing-policy] 511 Filsfils, C., Sivabalan, S., Voyer, D., Bogdanov, A., and 512 P. Mattes, "Segment Routing Policy Architecture", draft- 513 ietf-spring-segment-routing-policy-06 (work in progress), 514 December 2019. 516 [I-D.koldychev-pce-operational] 517 Koldychev, M., Sivabalan, S., Negi, M., Achaval, D., and 518 H. Kotni, "PCEP Operational Clarification", draft- 519 koldychev-pce-operational-00 (work in progress), July 520 2019. 522 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 523 Requirement Levels", BCP 14, RFC 2119, 524 DOI 10.17487/RFC2119, March 1997, 525 . 527 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 528 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 529 DOI 10.17487/RFC5440, March 2009, 530 . 532 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 533 Computation Element Communication Protocol (PCEP) 534 Extensions for Stateful PCE", RFC 8231, 535 DOI 10.17487/RFC8231, September 2017, 536 . 538 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 539 Computation Element Communication Protocol (PCEP) 540 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 541 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 542 . 544 12.2. Informative References 546 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 547 Element (PCE)-Based Architecture", RFC 4655, 548 DOI 10.17487/RFC4655, August 2006, 549 . 551 Authors' Addresses 553 Mike Koldychev 554 Cisco Systems, Inc. 556 Email: mkoldych@cisco.com 558 Siva Sivabalan 559 Cisco Systems, Inc. 561 Email: msiva@cisco.com 563 Tarek Saad 564 Juniper Networks, Inc. 566 Email: tsaad@juniper.net 568 Vishnu Pavan Beeram 569 Juniper Networks, Inc. 571 Email: vbeeram@juniper.net 573 Hooman Bidgoli 574 Nokia 576 Email: hooman.bidgoli@nokia.com 578 Bhupendra Yadav 579 Ciena 581 Email: byadav@ciena.com