idnits 2.17.1 draft-koldychev-pce-operational-04.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 (August 2021) is 986 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-09 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: 20 February 2022 Ciena Corporation 6 S. Peng 7 Huawei Technologies 8 D. Achaval 9 Nokia 10 H. Kotni 11 Juniper Networks, Inc 12 August 2021 14 PCEP Operational Clarification 15 draft-koldychev-pce-operational-04 17 Abstract 19 This document provides clarity about how PCEP operates and hence to 20 facilitates interoperability between different equipment vendors. 21 The content of this document has been compiled based on the feedback 22 from several multi-vendor interop exercises. Several constructs are 23 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 2 February 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . 5 71 3.3. Stateful Bringup . . . . . . . . . . . . . . . . . . . . 5 72 3.4. Successful MBB . . . . . . . . . . . . . . . . . . . . . 7 73 3.5. Aborted MBB . . . . . . . . . . . . . . . . . . . . . . . 8 74 4. PCEP Association Database . . . . . . . . . . . . . . . . . . 9 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. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 10.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 14 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 Path Computation Element (PCE) Communication Protocol (PCEP) 91 [RFC5440] enables the communication between a Path Computation Client 92 (PCC) and a Path Control Element (PCE), or between two PCEs based on 93 the PCE architecture [RFC4655]. 95 PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set 96 of extensions to PCEP to enable active control of Multiprotocol Label 97 Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) 98 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 99 LSPs under the active stateful PCE model, without the need for local 100 configuration on the PCC, thus allowing for dynamic centralized 101 control of a network. 103 PCEP Extensions for Establishing Relationships Between Sets of LSPs 104 [RFC8697] introduces a generic mechanism to create a grouping of LSPs 105 which can then be used to define associations between a set of LSPs 106 and a set of attributes (such as configuration parameters or 107 behaviors) and is equally applicable to stateful PCE (active and 108 passive modes) and stateless PCE. 110 The PCEP protocol has evolved from a simple stateless model into a 111 stateful model with more features being added. Due to subtle 112 differences in interpretation of existing PCEP standards, it was 113 found that networking equipment vendors often had to adjust their 114 implementations, in order to interoperate. This informational 115 document is meant to clarify these subtle differences and agree on a 116 final model that all major vendors have agreed on and that all other 117 vendors can adopt. This document applies to RSVP-TE and Segment- 118 Routing. 120 2. Terminology 122 The following terminologies are used in this document: 124 PCC: Path Computation Client. Any client application requesting a 125 path computation to be performed by a Path Computation Element. 127 PCE: Path Computation Element. An entity (component, application, 128 or network node) that is capable of computing a network path or 129 route based on a network graph and applying computational 130 constraints. 132 PCEP: Path Computation Element Protocol. 134 MBB: Make-Before-Break. A procedure during which the head-end of a 135 traffic-engineered path wishes to move traffic to a new path 136 without losing any traffic, by first "making" a new path and then 137 "breaking" the old path. 139 Association parameters: As described in [RFC8697], the combination 140 of the mandatory fields Association type, Association ID and 141 Association Source in the ASSOCIATION object uniquely identify the 142 association group. If the optional TLVs - Global Association 143 Source or Extended Association ID are included, then they MUST be 144 included in combination with mandatory fields to uniquely identify 145 the association group. 147 Association information: As described in [RFC8697], the ASSOCIATION 148 object could also include other optional TLVs based on the 149 association types, that provides 'information' related to the 150 association type. 152 ERO: Explicit Route Object is the path of the LSP encoded into a 153 PCEP object. To represent an empty ERO object, i.e., without any 154 subobjects, we use the notation "ERO={}". To represent an ERO 155 object containing some given sequence of subobjects, we use the 156 notation "ERO={A}". 158 3. PCEP LSP Database 160 We introduce the concept of the LSP-DB, as a database of actual LSP 161 state in the network. This concept is not explicitly defined in 162 [RFC8231], but is fully compatible with it. We use the LSP-DB to 163 describe how certain actions are performed, because it is easier to 164 define actions as a function of database state, rather than as a 165 function of previously received messages. The structure and format 166 of the LSP-DB MUST be common among all dataplane types (i.e., RSVP- 167 TE/SR-TE/SRv6), all instantiation methods (i.e., PCC-initiated/PCE- 168 initiated), all destination types (i.e., point-to-point/point-to- 169 multipoint). 171 Note that we use the term "Tunnel" somewhat loosely here, to mean 172 "the object identified by the PLSP-ID". It may or may not be an 173 actual tunnel in the implementation. For example, working and 174 protect paths can be implemented as one tunnel interface, but in PCEP 175 we would refer to them as two different Tunnels, because they would 176 have different PLSP-IDs. 178 Note that the term "LSP", which stands for "Label Switched Path", if 179 taken too literally would restrict our discussion to MPLS dataplane 180 only. In this document, we allow the term "LSP" to refer to any 181 path, regardless of the dataplane format. So that an LSP can refer 182 to MPLS and SRv6 dataplane paths. 184 3.1. Structure 186 [RFC8231] states that the LSP-IDENTIFIERS TLV contains the key that 187 MUST be used to differentiate different LSPs during make before break 188 procedure. We further clarify here that PCEP LSPs exist in a 2-tier 189 structure. The top tier is the "Tunnel", identified by the PLSP-ID 190 and/or SYMBOLIC-NAME, while the lower tier is the "LSP", identified 191 by the values in LSP-IDENTIFIERS TLV. A single Tunnel may contain 192 multiple LSPs at the same time, i.e., a Tunnel is a container for 193 LSPs. A Tunnel MUST have at least one LSP and when the last LSP is 194 removed from the Tunnel, the Tunnel itself is removed. 196 3.2. Synchronization 198 The stateful PCE MUST maintain the PCE LSP-DB, which stores Tunnels 199 and LSPs. The PCE LSP DB is only modified by PCRpt messages. No 200 other PCEP message may modify the PCE LSP DB. The PCC MUST also 201 maintain the PCC LSP DB, which it MUST synchronize with the PCE LSP 202 DB by sending PCRpt messages. 204 The PCC adds/removes entries to/from its LSP-DB based on what LSPs it 205 creates/destroys in the network. There can be many trigger types for 206 updating the PCC LSP-DB, some examples include PCUpd messages, local 207 computation on the PCC, local configuration on the PCC, etc. The 208 trigger type does not affect the content of the PCC LSP-DB, i.e., the 209 content of the PCC LSP-DB is updated identically regardless of the 210 trigger type. 212 Whenever a PCC modifies an entry in its PCC LSP-DB, it MUST send a 213 PCRpt message to the PCE (or multiple PCEs), to synchronize this 214 change. Ensuring this synchronization is always in place allows one 215 to define behavior as a function of LSP-DB state, instead of defining 216 behavior as a function of what PCEP messages were sent or received. 218 The PCE MUST always act on the latest state of the PCE LSP DB. Note 219 that this does not mean that the PCE cannot use information from 220 outside of LSP-DB. For example, the PCE can use other mechanisms to 221 collect traffic statistics and use them in the computation. However, 222 these traffic statistics are not part of the LSP-DB, but only 223 reference it. 225 The LSP-DB on both the PCC and the PCE only stores the actual state 226 in the network, it does not store the desired state. For example, 227 consider the case of PCE Initiated LSP, configured on the PCE. When 228 the operator modifies the configuration of this LSP, that is a change 229 in desired state. The actual state has not yet changed, so LSP-DB is 230 not modified yet. The LSP-DB is only modified after the PCE sends 231 PCInit/PCUpd message to the PCC and the PCC decides to act on that 232 message. When the PCC acts on message, it would update its own PCC 233 LSP DB and immediately send PCRpt to the PCE to synchronize the 234 change. When the PCE receives the PCRpt msg, it updates its own PCE 235 LSP DB. After this, the PCC LSP DB and PCE LSP DB are in sync. 237 3.3. Stateful Bringup 239 [RFC8231] in section 5.8.2, allows delegation of an LSP in 240 operationally down state, but at the same time mandates the use of 241 PCReq, before sending PCRpt. In this document, we would like to make 242 it clear that sending PCReq is optional. 244 We shall refer to the process of sending PCReq before PCRpt as 245 "stateless bringup". In reality, stateless bringup introduces 246 overhead and is not possible to enforce from the PCE, because the 247 stateless PCE is not supposed to keep any per-LSP state about 248 previous PCReq messages. It was found that many vendors choose to 249 ignore this requirement and send the PCRpt directly, without going 250 through PCReq. This section will serve to explain and to validate 251 this behavior. 253 Even though all the major vendors today are moving to the stateful 254 PCE model, it does not deprecate the need for stateless PCEP. The 255 key property of stateless PCEP is that PCReq messages MUST NOT modify 256 the state of the PCE LSP-DB in any way. Therefore, PCReq messages 257 are useful for many OAM ping/traceroute applications where the PCC 258 wishes to probe the network without having any effect on the existing 259 LSPs. 261 The PCC MAY delegate an empty LSP to the PCE and then wait for the 262 PCE to send PCUpd, without sending PCReq. We shall refer to this 263 process as "stateful bringup". The PCE MUST support the original 264 stateless bringup, for backward compatibility purposes. Supporting 265 stateful bringup should not require introducing any new behavior on 266 the PCE, because as mentioned earlier, the PCE MUST NOT modify LSP-DB 267 state based on PCReq messages. So whether the PCE has received a 268 PCReq or not, it MUST process the PCRpt all the same. 270 An example of stateful bringup follows. In our example the PCC 271 starts off by using LSP-ID of 0. The value 0 does not hold any 272 special meaning, any other 16-bit value could have been used. 274 PCC has no LSP yet, but wants to establish a path. PCC sends 275 PCRpt(R-FLAG=0, D-flag=1, OPER-FLAG=DOWN, PLSP-ID=100, LSP-ID=0, 276 ERO={}). 278 +---------------------------------------------------------------+ 279 | TUNNEL | LSP | 280 +-----------------+---------------------------------------------+ 281 | PLSP-ID=100 | LSP-ID=0, D-flag=1, OPER=DOWN, ERO={} | 282 +---------------------------------------------------------------+ 284 Figure 1: Content of LSP DB 286 PCC received a PCUpd from the PCE and has decided to install the 287 ERO={A} from that PCUpd. PCC sends PCRpt(R-FLAG=0, D-flag=1, OPER- 288 FLAG=UP, PLSP-ID=100, LSP-ID=0, ERO={A}). 290 +---------------------------------------------------------------+ 291 | TUNNEL | LSP | 292 +-----------------+---------------------------------------------+ 293 | PLSP-ID=100 | LSP-ID=0, D-flag=1, OPER=UP, ERO={A} | 294 +---------------------------------------------------------------+ 296 Figure 2: Content of LSP DB 298 3.4. Successful MBB 300 Below we give an example of doing MBB to switch the Tunnel from one 301 path to another. We represent the path encoded into the ERO object 302 as ERO={A} and ERO={B}. 304 PCC has an existing LSP in UP state, with LSP-ID=2. PCC sends 305 PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=2, ERO={A}, OPER-FLAG=UP). 307 +---------------------------------------------------------------+ 308 | TUNNEL | LSP | 309 +-----------------+---------------------------------------------+ 310 | PLSP-ID=100 | LSP-ID=2, ERO={A}, OPER=UP | 311 +---------------------------------------------------------------+ 313 Figure 3: Content of LSP DB 315 PCC initiates the MBB procedure by creating a new LSP with LSP-ID=3. 316 It does not matter what triggered the creation of the new LSP, it 317 could have been due to a new path received via PCUpd (if the given 318 Tunnel is delegated), or it could have been local computation on the 319 PCC (if the Tunnel is locally computed on the PCC), or it could have 320 been a change in configuration on the PCC (if the Tunnel's path is 321 explicitly configured on the PCC). It is important to emphasize that 322 the procedure for updating the LSP-DB is common, regardless of the 323 trigger that caused the change. 325 PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=3, ERO={B}, OPER- 326 FLAG=UP). 328 +---------------------------------------------------------------+ 329 | TUNNEL | LSP | 330 +-----------------+---------------------------------------------+ 331 | PLSP-ID=100 | LSP-ID=2, ERO={A}, OPER=UP | 332 | | LSP-ID=3, ERO={B}, OPER=UP | 333 +---------------------------------------------------------------+ 335 Figure 4: Content of LSP DB 337 After traffic has successfully switched to the new LSP, the PCC 338 cleans up the old LSP. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, LSP- 339 ID=2). 341 +---------------------------------------------------------------+ 342 | TUNNEL | LSP | 343 +-----------------+---------------------------------------------+ 344 | PLSP-ID=100 | LSP-ID=3, ERO={B}, OPER=UP | 345 +---------------------------------------------------------------+ 347 Figure 5: Content of LSP DB 349 3.5. Aborted MBB 351 The MBB process can abort when the newly created LSP is destroyed 352 before it is installed as traffic carrying. This scenario is 353 described below. 355 PCC has an existing LSP in UP state, with LSP-ID=2. PCC sends 356 PCRpt(R-FLAG=0, OPER-FLAG=UP, PLSP-ID=100, LSP-ID=2). 358 +---------------------------------------------------------------+ 359 | TUNNEL | LSP | 360 +-----------------+---------------------------------------------+ 361 | PLSP-ID=100 | LSP-ID=2, OPER=UP | 362 +---------------------------------------------------------------+ 364 Figure 6: Content of LSP DB 366 MBB procedure is initiated, a new LSP is created with LSP-ID=3. LSP 367 is currently being established, so its oper state is DOWN. PCC sends 368 PCRpt(R-FLAG=0, OPER-FLAG=DOWN, PLSP-ID=100, LSP-ID=3). 370 +---------------------------------------------------------------+ 371 | TUNNEL | LSP | 372 +-----------------+---------------------------------------------+ 373 | PLSP-ID=100 | LSP-ID=2, OPER=UP | 374 | | LSP-ID=3, OPER=DOWN | 375 +---------------------------------------------------------------+ 377 Figure 7: Content of LSP DB 379 MBB procedure is aborted. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, 380 LSP-ID=3). 382 +---------------------------------------------------------------+ 383 | TUNNEL | LSP | 384 +-----------------+---------------------------------------------+ 385 | PLSP-ID=100 | LSP-ID=2, OPER=UP | 386 +---------------------------------------------------------------+ 388 Figure 8: Content of LSP DB 390 4. PCEP Association Database 392 PCEP Association is a group of zero or more LSPs. 394 The PCE ASSO DB is populated by PCRpt messages and MAY also be 395 populated via configuration on the PCE itself. An Association is 396 identified by the Association Parameters. The Association parameters 397 contain many fields, so for convenience we will group all the fields 398 into a single value. We will use ASSO_PARAM=A, ASSO_PARAM=B, to 399 refer to different PCEP Associations: A and B, respectively. 401 4.1. 2 LSPs in same Association 403 Below, we give an example of LSPs joining the same Association. 405 PCC creates the first LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, 406 LSP-ID=1, ASSO_PARAM=A, ASSO_R_FLAG=0). 408 +---------------------------------------------------------------+ 409 | ASSO | LSP | 410 +-----------------+---------------------------------------------+ 411 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 412 +---------------------------------------------------------------+ 414 Figure 9: Content of PCE ASSO DB 416 PCC creates the second LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=200, 417 LSP-ID=1, ASSO_PARAM=A, ASSO_R_FLAG=0). 419 +---------------------------------------------------------------+ 420 | ASSO | LSP | 421 +-----------------+---------------------------------------------+ 422 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 423 | | PLSP-ID=200, LSP-ID=1 | 424 +---------------------------------------------------------------+ 426 Figure 10: Content of PCE ASSO DB 428 PCC updates the first LSP, the PCC is NOT REQUIRED to send the 429 ASSOCIATION object in this PCRpt, since the LSP is already in the 430 Association. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=1). The 431 content of the PCE ASSO DB is unchanged. Note that the PCC MUST send 432 the ASSOCIATION OBJECT in the first PCRpt during SYNC state, even if 433 it has already issued a PCRpt with the association object sometime in 434 the past with this PCE. The synchronization steps outlined in 435 [RFC8697] are to be followed. 437 +---------------------------------------------------------------+ 438 | ASSO | LSP | 439 +-----------------+---------------------------------------------+ 440 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 441 | | PLSP-ID=200, LSP-ID=1 | 442 +---------------------------------------------------------------+ 444 Figure 11: Content of PCE ASSO DB 446 PCC decides to delete the second LSP. PCC sends PCRpt(R-FLAG=1, 447 PLSP-ID=200, LSP-ID=1). 449 +---------------------------------------------------------------+ 450 | ASSO | LSP | 451 +-----------------+---------------------------------------------+ 452 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 453 +---------------------------------------------------------------+ 455 Figure 12: Content of PCE ASSO DB 457 PCC decides to remove the first LSP from the Association, but not 458 delete the LSP itself. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP- 459 ID=1, ASSO_PARAM=A, ASSO_R_FLAG=1). The PCE ASSO DB is now empty. 461 +---------------------------------------------------------------+ 462 | ASSO | LSP | 463 +-----------------+---------------------------------------------+ 464 | ASSO_PARAM=A | | 465 +---------------------------------------------------------------+ 467 Figure 13: Content of PCE ASSO DB 469 4.2. Switch Association during MBB 471 Each new LSP (identified by the LSP-ID) does not inherit the 472 Association membership of any previous LSPs within the same Tunnel. 473 This is done so that a Tunnel can have two LSPs that are in different 474 Associations, this may be required when switching from one 475 Association to another. 477 Below, we give an example a Tunnel going through MBB and switching 478 from Association A to Association B. 480 PCC creates the first LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, 481 LSP-ID=1, ASSO_PARAM=A, ASSO_R_FLAG=0). 483 +---------------------------------------------------------------+ 484 | ASSO | LSP | 485 +-----------------+---------------------------------------------+ 486 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 487 +---------------------------------------------------------------+ 489 Figure 14: Content of PCE ASSO DB 491 PCC creates the MBB LSP in a different Association. PCC sends 492 PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=2, ASSO_PARAM=B, ASSO_R_FLAG=0). 494 +---------------------------------------------------------------+ 495 | ASSO | LSP | 496 +-----------------+---------------------------------------------+ 497 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 498 +---------------------------------------------------------------+ 499 | ASSO_PARAM=B | PLSP-ID=100, LSP-ID=2 | 500 +---------------------------------------------------------------+ 502 Figure 15: Content of PCE ASSO DB 504 PCC deletes the old LSP. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, LSP- 505 ID=1). 507 +---------------------------------------------------------------+ 508 | ASSO | LSP | 509 +-----------------+---------------------------------------------+ 510 | ASSO_PARAM=B | PLSP-ID=100, LSP-ID=2 | 511 +---------------------------------------------------------------+ 513 Figure 16: Content of PCE ASSO DB 515 5. Computation Constraints 517 For any PCEP object that does not have an explicit removal flag, the 518 absence of that object indicates removal of the constraint specified 519 by that object. For example, suppose the first state-report contains 520 an LSPA object with some affinity constraints. Then if a subsequent 521 state-report does not contain an LSPA object, then this means that 522 the previously specified affinity constraints do not apply anymore. 523 Same applies to all PCEP objects, like METRIC, BANDWIDTH, etc., which 524 do not have an explicit flag for removal. This simply ensures that 525 it is possible to remove a constraint without using an explicit 526 removal flag. 528 6. Use of RRO, SR-RRO and SRv6-RRO objects 530 [RFC8231] defines a PCRpt message which contains 531 known as the ERO object and known as the RRO object. 532 [RFC8664] defines SR-ERO and SR-RRO objects for SR-TE LSPs. 533 [I-D.ietf-pce-segment-routing-ipv6] further defines SRv6-ERO and 534 SRv6-RRO objects for SRv6-TE paths. 536 In practice RRO data set is the result of signalling of the intended 537 path defined in the ERO via protocol such as RSVP. The ERO and RRO 538 values may be different as the path encoded in the ERO may differ 539 than the RRO such as during protection conditions or if the ERO 540 contains loose hops which are expanded upon. As Segment Routing LSP 541 does not perform any signalling, the values of an SR-ERO/SRv6-ERO and 542 SR-RRO/SRv6-RRO (respectively) are in practice the same, therefore 543 some implementations have omitted the SR-RRO/SRv6-RRO when reporting 544 a SR-TE LSP while others continue to send both SR-ERO/SRv6-ERO and 545 SR-RRO/SRv6-RRO values. 547 A PCC MUST send an (possibly empty) ERO/SR-ERO/SRv6-ERO in the PCRpt 548 message for every LSP. A PCC MAY send an SR-RRO/SRv6-RRO for an SR- 549 TE/SRv6-TE LSP (respectively). A PCE SHOULD interpret the RRO/SR- 550 RRO/SRv6-RRO as the actual path the LSP is taking but MAY interpret 551 only the ERO/SR-ERO/SRv6-ERO as the actual path. In the absence of 552 an RRO/SR-RRO/SRv6-RRO a PCE SHOULD interpret the ERO/SR-ERO/SRv6-ERO 553 (respectively) as the actual path for the LSP. 555 7. Security Considerations 557 None at this time. 559 8. IANA Considerations 561 None at this time. 563 9. Acknowledgement 565 10. References 567 10.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, 571 DOI 10.17487/RFC2119, March 1997, 572 . 574 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 575 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 576 DOI 10.17487/RFC5440, March 2009, 577 . 579 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 580 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 581 May 2017, . 583 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 584 Computation Element Communication Protocol (PCEP) 585 Extensions for Stateful PCE", RFC 8231, 586 DOI 10.17487/RFC8231, September 2017, 587 . 589 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 590 Computation Element Communication Protocol (PCEP) 591 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 592 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 593 . 595 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 596 and J. Hardwick, "Path Computation Element Communication 597 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 598 DOI 10.17487/RFC8664, December 2019, 599 . 601 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 602 Dhody, D., and Y. Tanaka, "Path Computation Element 603 Communication Protocol (PCEP) Extensions for Establishing 604 Relationships between Sets of Label Switched Paths 605 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 606 . 608 [I-D.ietf-pce-segment-routing-ipv6] 609 Li, C., Negi, M., Sivabalan, S., Koldychev, M., 610 Kaladharan, P., and Y. Zhu, "PCEP Extensions for Segment 611 Routing leveraging the IPv6 data plane", Work in Progress, 612 Internet-Draft, draft-ietf-pce-segment-routing-ipv6-09, 27 613 May 2021, . 616 10.2. Informative References 618 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 619 Computation Element (PCE)-Based Architecture", RFC 4655, 620 DOI 10.17487/RFC4655, August 2006, 621 . 623 Appendix A. Contributors 625 Dhruv Dhody 626 Huawei Technologies 627 Divyashree Techno Park, Whitefield 628 Bangalore, Karnataka 560066 629 India 631 Email: dhruv.ietf@gmail.com 633 Andrew Stone 634 Nokia 635 Ottawa, Canada 637 Email: andrew.stone@nokia.com 639 Mahendra Singh Negi 640 RtBrick Inc 641 N-17L, 18th Cross Rd, HSR Layout 642 Bangalore, Karnataka 560102 643 India 645 Email: mahend.ietf@gmail.com 647 Authors' Addresses 649 Mike Koldychev 650 Cisco Systems, Inc. 651 2000 Innovation Drive 652 Kanata Ontario K2K 3E8 653 Canada 655 Email: mkoldych@cisco.com 657 Siva Sivabalan 658 Ciena Corporation 659 385 Terry Fox Dr. 660 Kanata Ontario K2K 0L1 661 Canada 663 Email: ssivabal@ciena.com 665 Shuping Peng 666 Huawei Technologies 667 Huawei Campus, No. 156 Beiqing Rd. 668 Beijing 669 100095 670 China 672 Email: pengshuping@huawei.com 674 Diego Achaval 675 Nokia 677 Email: diego.achaval@nokia.com 679 Hari Kotni 680 Juniper Networks, Inc 682 Email: hkotni@juniper.net