idnits 2.17.1 draft-koldychev-pce-operational-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document date (February 2022) is 801 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 (-25) exists of draft-ietf-pce-segment-routing-ipv6-11 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). 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: 23 August 2022 Ciena Corporation 6 S. Peng 7 Huawei Technologies 8 D. Achaval 9 Nokia 10 H. Kotni 11 Juniper Networks, Inc 12 February 2022 14 PCEP Operational Clarification 15 draft-koldychev-pce-operational-05 17 Abstract 19 This document proposes some important simplifications to the original 20 PCEP protocol and also serves to clarify certain aspects of PCEP 21 operation. The content of this document has been compiled based on 22 the feedback from several multi-vendor interop exercises. Several 23 constructs are introduced, such as the LSP-DB and the ASSO-DB. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 29 "OPTIONAL" in this document are to be interpreted as described in BCP 30 14 [RFC2119] [RFC8174] when, and only when, they appear in all 31 capitals, as shown here. 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 5 August 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. PCEP LSP Database . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Synchronization . . . . . . . . . . . . . . . . . . . . . 4 71 3.3. Stateful Bringup . . . . . . . . . . . . . . . . . . . . 5 72 3.4. Successful MBB . . . . . . . . . . . . . . . . . . . . . 7 73 3.5. Aborted MBB . . . . . . . . . . . . . . . . . . . . . . . 8 74 4. PCEP Association Database . . . . . . . . . . . . . . . . . . 8 75 4.1. 2 LSPs in same Association . . . . . . . . . . . . . . . 9 76 4.2. Switch Association during MBB . . . . . . . . . . . . . . 10 77 5. Computation Constraints . . . . . . . . . . . . . . . . . . . 11 78 6. Use of RRO, SR-RRO and SRv6-RRO objects . . . . . . . . . . . 12 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 82 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 83 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 The PCEP protocol started off being purely stateless with PCReq and 89 PCReply messages, as described in Path Computation Element (PCE) 90 Communication Protocol (PCEP) [RFC5440]. Stateless PCEP operates in 91 a "pull" model, i.e., PCC has to periodically ask the PCE for updates 92 to the path, even if the path has not changed. 94 Stateful PCEP was later introduced in PCEP Extensions for the 95 Stateful PCE Model [RFC8231]. Stateful PCEP operates in a "push" 96 model, where the PCC can register with PCE to receive future updates 97 about the path, and there is no need to ask the PCE periodically. 99 The current document serves to optimize the original procedure in 100 [RFC8231] to drop the PCReq and PCReply exchange, which greatly 101 simplifies implementation and optimizes the protocol. 103 Due to different interpretations of PCEP standards, it was found that 104 implementations often had to adjust their behavior in order to 105 interoperate. The current document serves to clarify certain aspects 106 of PCEP to make it easier to produce interoperable implementations of 107 PCEP. 109 2. Terminology 111 The following terminologies are used in this document: 113 PCC: Path Computation Client. Any client application requesting a 114 path computation to be performed by a Path Computation Element. 116 PCE: Path Computation Element. An entity (component, application, 117 or network node) that is capable of computing a network path or 118 route based on a network graph and applying computational 119 constraints. 121 PCEP: Path Computation Element Protocol. 123 MBB: Make-Before-Break. A procedure during which the head-end of a 124 traffic-engineered path wishes to move traffic to a new path 125 without losing any traffic, by first "making" a new path and then 126 "breaking" the old path. 128 Association parameters: As described in [RFC8697], the combination 129 of the mandatory fields Association type, Association ID and 130 Association Source in the ASSOCIATION object uniquely identify the 131 association group. If the optional TLVs - Global Association 132 Source or Extended Association ID are included, then they MUST be 133 included in combination with mandatory fields to uniquely identify 134 the association group. 136 Association information: As described in [RFC8697], the ASSOCIATION 137 object could also include other optional TLVs based on the 138 association types, that provides 'information' related to the 139 association type. 141 ERO: Explicit Route Object is the path of the LSP encoded into a 142 PCEP object. To represent an empty ERO object, i.e., without any 143 subobjects, we use the notation "ERO={}". To represent an ERO 144 object containing some given sequence of subobjects, we use the 145 notation "ERO={A}". 147 3. PCEP LSP Database 149 We introduce the concept of the LSP-DB, as a database of actual LSP 150 state in the network. This concept is not explicitly defined in 151 [RFC8231], but is fully compatible with it. We use the LSP-DB to 152 describe how certain actions are performed, because it is easier to 153 define actions as a function of database state, rather than as a 154 function of previously received messages. The structure and format 155 of the LSP-DB MUST be common among all dataplane types (i.e., RSVP- 156 TE/SR-TE/SRv6), all instantiation methods (i.e., PCC-initiated/PCE- 157 initiated), all destination types (i.e., point-to-point/point-to- 158 multipoint). 160 Note that we use the term "Tunnel" somewhat loosely here, to mean 161 "the object identified by the PLSP-ID". It may or may not be an 162 actual tunnel in the implementation. For example, working and 163 protect paths can be implemented as one tunnel interface, but in PCEP 164 we would refer to them as two different Tunnels, because they would 165 have different PLSP-IDs. 167 Note that the term "LSP", which stands for "Label Switched Path", if 168 taken too literally would restrict our discussion to MPLS dataplane 169 only. In this document, we allow the term "LSP" to refer to any 170 path, regardless of the dataplane format. So that an LSP can refer 171 to MPLS and SRv6 dataplane paths. 173 3.1. Structure 175 [RFC8231] states that the LSP-IDENTIFIERS TLV contains the key that 176 MUST be used to differentiate different LSPs during make before break 177 procedure. We further clarify here that PCEP LSPs exist in a 2-tier 178 structure. The top tier is the "Tunnel", identified by the PLSP-ID 179 and/or SYMBOLIC-NAME, while the lower tier is the "LSP", identified 180 by the values in LSP-IDENTIFIERS TLV. A single Tunnel may contain 181 multiple LSPs at the same time, i.e., a Tunnel is a container for 182 LSPs. A Tunnel MUST have at least one LSP and when the last LSP is 183 removed from the Tunnel, the Tunnel itself is removed. 185 3.2. Synchronization 187 The stateful PCE MUST maintain the PCE LSP-DB, which stores Tunnels 188 and LSPs. The PCE LSP DB is only modified by PCRpt messages. No 189 other PCEP message may modify the PCE LSP DB. The PCC MUST also 190 maintain the PCC LSP DB, which it MUST synchronize with the PCE LSP 191 DB by sending PCRpt messages. 193 The PCC adds/removes entries to/from its LSP-DB based on what LSPs it 194 creates/destroys in the network. There can be many trigger types for 195 updating the PCC LSP-DB, some examples include PCUpd messages, local 196 computation on the PCC, local configuration on the PCC, etc. The 197 trigger type does not affect the content of the PCC LSP-DB, i.e., the 198 content of the PCC LSP-DB is updated identically regardless of the 199 trigger type. 201 Whenever a PCC modifies an entry in its PCC LSP-DB, it MUST send a 202 PCRpt message to the PCE (or multiple PCEs), to synchronize this 203 change. Ensuring this synchronization is always in place allows one 204 to define behavior as a function of LSP-DB state, instead of defining 205 behavior as a function of what PCEP messages were sent or received. 207 The PCE MUST always act on the latest state of the PCE LSP DB. Note 208 that this does not mean that the PCE cannot use information from 209 outside of LSP-DB. For example, the PCE can use other mechanisms to 210 collect traffic statistics and use them in the computation. However, 211 these traffic statistics are not part of the LSP-DB, but only 212 reference it. 214 The LSP-DB on both the PCC and the PCE only stores the actual state 215 in the network, it does not store the desired state. For example, 216 consider the case of PCE Initiated LSP, configured on the PCE. When 217 the operator modifies the configuration of this LSP, that is a change 218 in desired state. The actual state has not yet changed, so LSP-DB is 219 not modified yet. The LSP-DB is only modified after the PCE sends 220 PCInit/PCUpd message to the PCC and the PCC decides to act on that 221 message. When the PCC acts on message, it would update its own PCC 222 LSP DB and immediately send PCRpt to the PCE to synchronize the 223 change. When the PCE receives the PCRpt msg, it updates its own PCE 224 LSP DB. After this, the PCC LSP DB and PCE LSP DB are in sync. 226 3.3. Stateful Bringup 228 [RFC8231] in section 5.8.2, allows delegation of an LSP in 229 operationally down state, but at the same time mandates the use of 230 PCReq, before sending PCRpt. In this document, we would like to make 231 it clear that sending PCReq is optional. 233 We shall refer to the process of sending PCReq before PCRpt as 234 "stateless bringup". In reality, stateless bringup introduces 235 overhead and is not possible to enforce from the PCE, because the 236 stateless PCE is not supposed to keep any per-LSP state about 237 previous PCReq messages. It was found that many vendors choose to 238 ignore this requirement and send the PCRpt directly, without going 239 through PCReq. This section will serve to explain and to validate 240 this behavior. 242 Even though all the major vendors today are moving to the stateful 243 PCE model, it does not deprecate the need for stateless PCEP. The 244 key property of stateless PCEP is that PCReq messages MUST NOT modify 245 the state of the PCE LSP-DB in any way. Therefore, PCReq messages 246 are useful for many OAM ping/traceroute applications where the PCC 247 wishes to probe the network without having any effect on the existing 248 LSPs. 250 The PCC MAY delegate an empty LSP to the PCE and then wait for the 251 PCE to send PCUpd, without sending PCReq. We shall refer to this 252 process as "stateful bringup". The PCE MUST support the original 253 stateless bringup, for backward compatibility purposes. Supporting 254 stateful bringup should not require introducing any new behavior on 255 the PCE, because as mentioned earlier, the PCE MUST NOT modify LSP-DB 256 state based on PCReq messages. So whether the PCE has received a 257 PCReq or not, it MUST process the PCRpt all the same. 259 An example of stateful bringup follows. In our example the PCC 260 starts off by using LSP-ID of 0. The value 0 does not hold any 261 special meaning, any other 16-bit value could have been used. 263 PCC has no LSP yet, but wants to establish a path. PCC sends 264 PCRpt(R-FLAG=0, D-flag=1, OPER-FLAG=DOWN, PLSP-ID=100, LSP-ID=0, 265 ERO={}). 267 +---------------------------------------------------------------+ 268 | TUNNEL | LSP | 269 +-----------------+---------------------------------------------+ 270 | PLSP-ID=100 | LSP-ID=0, D-flag=1, OPER=DOWN, ERO={} | 271 +---------------------------------------------------------------+ 273 Figure 1: Content of LSP DB 275 PCC received a PCUpd from the PCE and has decided to install the 276 ERO={A} from that PCUpd. PCC sends PCRpt(R-FLAG=0, D-flag=1, OPER- 277 FLAG=UP, PLSP-ID=100, LSP-ID=0, ERO={A}). 279 +---------------------------------------------------------------+ 280 | TUNNEL | LSP | 281 +-----------------+---------------------------------------------+ 282 | PLSP-ID=100 | LSP-ID=0, D-flag=1, OPER=UP, ERO={A} | 283 +---------------------------------------------------------------+ 285 Figure 2: Content of LSP DB 287 3.4. Successful MBB 289 Below we give an example of doing MBB to switch the Tunnel from one 290 path to another. We represent the path encoded into the ERO object 291 as ERO={A} and ERO={B}. 293 PCC has an existing LSP in UP state, with LSP-ID=2. PCC sends 294 PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=2, ERO={A}, OPER-FLAG=UP). 296 +---------------------------------------------------------------+ 297 | TUNNEL | LSP | 298 +-----------------+---------------------------------------------+ 299 | PLSP-ID=100 | LSP-ID=2, ERO={A}, OPER=UP | 300 +---------------------------------------------------------------+ 302 Figure 3: Content of LSP DB 304 PCC initiates the MBB procedure by creating a new LSP with LSP-ID=3. 305 It does not matter what triggered the creation of the new LSP, it 306 could have been due to a new path received via PCUpd (if the given 307 Tunnel is delegated), or it could have been local computation on the 308 PCC (if the Tunnel is locally computed on the PCC), or it could have 309 been a change in configuration on the PCC (if the Tunnel's path is 310 explicitly configured on the PCC). It is important to emphasize that 311 the procedure for updating the LSP-DB is common, regardless of the 312 trigger that caused the change. 314 PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=3, ERO={B}, OPER- 315 FLAG=UP). 317 +---------------------------------------------------------------+ 318 | TUNNEL | LSP | 319 +-----------------+---------------------------------------------+ 320 | PLSP-ID=100 | LSP-ID=2, ERO={A}, OPER=UP | 321 | | LSP-ID=3, ERO={B}, OPER=UP | 322 +---------------------------------------------------------------+ 324 Figure 4: Content of LSP DB 326 After traffic has successfully switched to the new LSP, the PCC 327 cleans up the old LSP. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, LSP- 328 ID=2). 330 +---------------------------------------------------------------+ 331 | TUNNEL | LSP | 332 +-----------------+---------------------------------------------+ 333 | PLSP-ID=100 | LSP-ID=3, ERO={B}, OPER=UP | 334 +---------------------------------------------------------------+ 335 Figure 5: Content of LSP DB 337 3.5. Aborted MBB 339 The MBB process can abort when the newly created LSP is destroyed 340 before it is installed as traffic carrying. This scenario is 341 described below. 343 PCC has an existing LSP in UP state, with LSP-ID=2. PCC sends 344 PCRpt(R-FLAG=0, OPER-FLAG=UP, PLSP-ID=100, LSP-ID=2). 346 +---------------------------------------------------------------+ 347 | TUNNEL | LSP | 348 +-----------------+---------------------------------------------+ 349 | PLSP-ID=100 | LSP-ID=2, OPER=UP | 350 +---------------------------------------------------------------+ 352 Figure 6: Content of LSP DB 354 MBB procedure is initiated, a new LSP is created with LSP-ID=3. LSP 355 is currently being established, so its oper state is DOWN. PCC sends 356 PCRpt(R-FLAG=0, OPER-FLAG=DOWN, PLSP-ID=100, LSP-ID=3). 358 +---------------------------------------------------------------+ 359 | TUNNEL | LSP | 360 +-----------------+---------------------------------------------+ 361 | PLSP-ID=100 | LSP-ID=2, OPER=UP | 362 | | LSP-ID=3, OPER=DOWN | 363 +---------------------------------------------------------------+ 365 Figure 7: Content of LSP DB 367 MBB procedure is aborted. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, 368 LSP-ID=3). 370 +---------------------------------------------------------------+ 371 | TUNNEL | LSP | 372 +-----------------+---------------------------------------------+ 373 | PLSP-ID=100 | LSP-ID=2, OPER=UP | 374 +---------------------------------------------------------------+ 376 Figure 8: Content of LSP DB 378 4. PCEP Association Database 380 PCEP Association is a group of zero or more LSPs. 382 The PCE ASSO DB is populated by PCRpt messages and MAY also be 383 populated via configuration on the PCE itself. An Association is 384 identified by the Association Parameters. The Association parameters 385 contain many fields, so for convenience we will group all the fields 386 into a single value. We will use ASSO_PARAM=A, ASSO_PARAM=B, to 387 refer to different PCEP Associations: A and B, respectively. 389 4.1. 2 LSPs in same Association 391 Below, we give an example of LSPs joining the same Association. 393 PCC creates the first LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, 394 LSP-ID=1, ASSO_PARAM=A, ASSO_R_FLAG=0). 396 +---------------------------------------------------------------+ 397 | ASSO | LSP | 398 +-----------------+---------------------------------------------+ 399 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 400 +---------------------------------------------------------------+ 402 Figure 9: Content of PCE ASSO DB 404 PCC creates the second LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=200, 405 LSP-ID=1, ASSO_PARAM=A, ASSO_R_FLAG=0). 407 +---------------------------------------------------------------+ 408 | ASSO | LSP | 409 +-----------------+---------------------------------------------+ 410 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 411 | | PLSP-ID=200, LSP-ID=1 | 412 +---------------------------------------------------------------+ 414 Figure 10: Content of PCE ASSO DB 416 PCC updates the first LSP, the PCC is NOT REQUIRED to send the 417 ASSOCIATION object in this PCRpt, since the LSP is already in the 418 Association. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=1). The 419 content of the PCE ASSO DB is unchanged. Note that the PCC MUST send 420 the ASSOCIATION OBJECT in the first PCRpt during SYNC state, even if 421 it has already issued a PCRpt with the association object sometime in 422 the past with this PCE. The synchronization steps outlined in 423 [RFC8697] are to be followed. 425 +---------------------------------------------------------------+ 426 | ASSO | LSP | 427 +-----------------+---------------------------------------------+ 428 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 429 | | PLSP-ID=200, LSP-ID=1 | 430 +---------------------------------------------------------------+ 432 Figure 11: Content of PCE ASSO DB 434 PCC decides to delete the second LSP. PCC sends PCRpt(R-FLAG=1, 435 PLSP-ID=200, LSP-ID=1). 437 +---------------------------------------------------------------+ 438 | ASSO | LSP | 439 +-----------------+---------------------------------------------+ 440 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 441 +---------------------------------------------------------------+ 443 Figure 12: Content of PCE ASSO DB 445 PCC decides to remove the first LSP from the Association, but not 446 delete the LSP itself. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP- 447 ID=1, ASSO_PARAM=A, ASSO_R_FLAG=1). The PCE ASSO DB is now empty. 449 +---------------------------------------------------------------+ 450 | ASSO | LSP | 451 +-----------------+---------------------------------------------+ 452 | ASSO_PARAM=A | | 453 +---------------------------------------------------------------+ 455 Figure 13: Content of PCE ASSO DB 457 4.2. Switch Association during MBB 459 Each new LSP (identified by the LSP-ID) does not inherit the 460 Association membership of any previous LSPs within the same Tunnel. 461 This is done so that a Tunnel can have two LSPs that are in different 462 Associations, this may be required when switching from one 463 Association to another. 465 Below, we give an example a Tunnel going through MBB and switching 466 from Association A to Association B. 468 PCC creates the first LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, 469 LSP-ID=1, ASSO_PARAM=A, ASSO_R_FLAG=0). 471 +---------------------------------------------------------------+ 472 | ASSO | LSP | 473 +-----------------+---------------------------------------------+ 474 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 475 +---------------------------------------------------------------+ 477 Figure 14: Content of PCE ASSO DB 479 PCC creates the MBB LSP in a different Association. PCC sends 480 PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=2, ASSO_PARAM=B, ASSO_R_FLAG=0). 482 +---------------------------------------------------------------+ 483 | ASSO | LSP | 484 +-----------------+---------------------------------------------+ 485 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 486 +---------------------------------------------------------------+ 487 | ASSO_PARAM=B | PLSP-ID=100, LSP-ID=2 | 488 +---------------------------------------------------------------+ 490 Figure 15: Content of PCE ASSO DB 492 PCC deletes the old LSP. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, LSP- 493 ID=1). 495 +---------------------------------------------------------------+ 496 | ASSO | LSP | 497 +-----------------+---------------------------------------------+ 498 | ASSO_PARAM=B | PLSP-ID=100, LSP-ID=2 | 499 +---------------------------------------------------------------+ 501 Figure 16: Content of PCE ASSO DB 503 5. Computation Constraints 505 For any PCEP object that does not have an explicit removal flag, the 506 absence of that object indicates removal of the constraint specified 507 by that object. For example, suppose the first state-report contains 508 an LSPA object with some affinity constraints. Then if a subsequent 509 state-report does not contain an LSPA object, then this means that 510 the previously specified affinity constraints do not apply anymore. 511 Same applies to all PCEP objects, like METRIC, BANDWIDTH, etc., which 512 do not have an explicit flag for removal. This simply ensures that 513 it is possible to remove a constraint without using an explicit 514 removal flag. 516 6. Use of RRO, SR-RRO and SRv6-RRO objects 518 [RFC8231] defines a PCRpt message which contains 519 known as the ERO object and known as the RRO object. 520 [RFC8664] defines SR-ERO and SR-RRO objects for SR-TE LSPs. 521 [I-D.ietf-pce-segment-routing-ipv6] further defines SRv6-ERO and 522 SRv6-RRO objects for SRv6-TE paths. 524 In practice RRO data set is the result of signalling of the intended 525 path defined in the ERO via protocol such as RSVP. The ERO and RRO 526 values may be different as the path encoded in the ERO may differ 527 than the RRO such as during protection conditions or if the ERO 528 contains loose hops which are expanded upon. As Segment Routing LSP 529 does not perform any signalling, the values of an SR-ERO/SRv6-ERO and 530 SR-RRO/SRv6-RRO (respectively) are in practice the same, therefore 531 some implementations have omitted the SR-RRO/SRv6-RRO when reporting 532 a SR-TE LSP while others continue to send both SR-ERO/SRv6-ERO and 533 SR-RRO/SRv6-RRO values. 535 A PCC MUST send an (possibly empty) ERO/SR-ERO/SRv6-ERO in the PCRpt 536 message for every LSP. A PCC MAY send an SR-RRO/SRv6-RRO for an SR- 537 TE/SRv6-TE LSP (respectively). A PCE SHOULD interpret the RRO/SR- 538 RRO/SRv6-RRO as the actual path the LSP is taking but MAY interpret 539 only the ERO/SR-ERO/SRv6-ERO as the actual path. In the absence of 540 an RRO/SR-RRO/SRv6-RRO a PCE SHOULD interpret the ERO/SR-ERO/SRv6-ERO 541 (respectively) as the actual path for the LSP. 543 7. Security Considerations 545 None at this time. 547 8. IANA Considerations 549 None at this time. 551 9. Acknowledgement 553 10. Normative References 555 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 556 Requirement Levels", BCP 14, RFC 2119, 557 DOI 10.17487/RFC2119, March 1997, 558 . 560 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 561 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 562 DOI 10.17487/RFC5440, March 2009, 563 . 565 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 566 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 567 May 2017, . 569 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 570 Computation Element Communication Protocol (PCEP) 571 Extensions for Stateful PCE", RFC 8231, 572 DOI 10.17487/RFC8231, September 2017, 573 . 575 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 576 and J. Hardwick, "Path Computation Element Communication 577 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 578 DOI 10.17487/RFC8664, December 2019, 579 . 581 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 582 Dhody, D., and Y. Tanaka, "Path Computation Element 583 Communication Protocol (PCEP) Extensions for Establishing 584 Relationships between Sets of Label Switched Paths 585 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 586 . 588 [I-D.ietf-pce-segment-routing-ipv6] 589 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 590 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 591 Routing leveraging the IPv6 data plane", Work in Progress, 592 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-11, 10 593 January 2022, . 596 Appendix A. Contributors 598 Dhruv Dhody 599 Huawei Technologies 600 Divyashree Techno Park, Whitefield 601 Bangalore, Karnataka 560066 602 India 604 Email: dhruv.ietf@gmail.com 606 Andrew Stone 607 Nokia 608 Ottawa, Canada 610 Email: andrew.stone@nokia.com 611 Samuel Sidor 612 Cisco Systems 613 Bratislava, Slovakia 615 Email: ssidor@cisco.com 617 Mahendra Singh Negi 618 RtBrick Inc 619 N-17L, 18th Cross Rd, HSR Layout 620 Bangalore, Karnataka 560102 621 India 623 Email: mahend.ietf@gmail.com 625 Authors' Addresses 627 Mike Koldychev 628 Cisco Systems, Inc. 629 2000 Innovation Drive 630 Kanata Ontario K2K 3E8 631 Canada 632 Email: mkoldych@cisco.com 634 Siva Sivabalan 635 Ciena Corporation 636 385 Terry Fox Dr. 637 Kanata Ontario K2K 0L1 638 Canada 639 Email: ssivabal@ciena.com 641 Shuping Peng 642 Huawei Technologies 643 Huawei Campus, No. 156 Beiqing Rd. 644 Beijing 645 100095 646 China 647 Email: pengshuping@huawei.com 649 Diego Achaval 650 Nokia 651 Email: diego.achaval@nokia.com 653 Hari Kotni 654 Juniper Networks, Inc 655 Email: hkotni@juniper.net