idnits 2.17.1 draft-koldychev-pce-operational-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 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 24, 2020) is 1522 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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 S. Sivabalan 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: August 27, 2020 M. Negi 6 Huawei Technologies 7 D. Achaval 8 Nokia 9 H. Kotni 10 Juniper Networks, Inc 11 February 24, 2020 13 PCEP Operational Clarification 14 draft-koldychev-pce-operational-01 16 Abstract 18 This document is meant to provide better clarity about how PCEP 19 operates and hence to facilitate better interoperability between 20 different equipment vendors. The content of this document has been 21 compiled based on the feedback from several multi-vendor interop 22 exercises. Several constructs are introduced to facilitate this, 23 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 August 27, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. PCEP LSP Database . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Synchronization . . . . . . . . . . . . . . . . . . . . . 5 72 3.3. Stateful Bringup . . . . . . . . . . . . . . . . . . . . 5 73 3.4. Successful MBB . . . . . . . . . . . . . . . . . . . . . 7 74 3.5. Aborted MBB . . . . . . . . . . . . . . . . . . . . . . . 8 75 4. PCEP Association Database . . . . . . . . . . . . . . . . . . 9 76 4.1. 2 LSPs in same Association . . . . . . . . . . . . . . . 9 77 4.2. Switch Association during MBB . . . . . . . . . . . . . . 10 78 5. Computation Constraints . . . . . . . . . . . . . . . . . . . 11 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 81 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 12 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 84 9.2. Informative References . . . . . . . . . . . . . . . . . 13 85 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 13 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 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 it 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 some time, the PCC decides to destroy the old LSP. PCC sends 338 PCRpt(R-FLAG=1, PLSP-ID=100, LSP-ID=2). 340 +---------------------------------------------------------------+ 341 | TUNNEL | LSP | 342 +-----------------+---------------------------------------------+ 343 | PLSP-ID=100 | LSP-ID=3, ERO={B}, OPER=UP | 344 +---------------------------------------------------------------+ 346 Figure 5: Content of LSP DB 348 3.5. Aborted MBB 350 The MBB process can abort when the newly created LSP is destroyed 351 before it is installed as traffic carrying. This scenario is 352 described below. 354 PCC has an existing LSP in UP state, with LSP-ID=2. PCC sends 355 PCRpt(R-FLAG=0, OPER-FLAG=UP, PLSP-ID=100, LSP-ID=2). 357 +---------------------------------------------------------------+ 358 | TUNNEL | LSP | 359 +-----------------+---------------------------------------------+ 360 | PLSP-ID=100 | LSP-ID=2, OPER=UP | 361 +---------------------------------------------------------------+ 363 Figure 6: Content of LSP DB 365 MBB procedure is initiated, a new LSP is created with LSP-ID=3. LSP 366 is currently being established, so its oper state is DOWN. PCC sends 367 PCRpt(R-FLAG=0, OPER-FLAG=DOWN, PLSP-ID=100, LSP-ID=3). 369 +---------------------------------------------------------------+ 370 | TUNNEL | LSP | 371 +-----------------+---------------------------------------------+ 372 | PLSP-ID=100 | LSP-ID=2, OPER=UP | 373 | | LSP-ID=3, OPER=DOWN | 374 +---------------------------------------------------------------+ 376 Figure 7: Content of LSP DB 378 MBB procedure is aborted. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, 379 LSP-ID=3). 381 +---------------------------------------------------------------+ 382 | TUNNEL | LSP | 383 +-----------------+---------------------------------------------+ 384 | PLSP-ID=100 | LSP-ID=2, OPER=UP | 385 +---------------------------------------------------------------+ 387 Figure 8: Content of LSP DB 389 4. PCEP Association Database 391 PCEP Association is a group of zero or more LSPs. 393 The PCE ASSO DB is populated by PCRpt messages and MAY also be 394 populated via configuration on the PCE itself. An Association is 395 identified by the Association Parameters. The Association parameters 396 contain many fields, so for convenience we will group all the fields 397 into a single value. We will use ASSO_PARAM=A, ASSO_PARAM=B, to 398 refer to different PCEP Associations: A and B, respectively. 400 4.1. 2 LSPs in same Association 402 Below, we give an example of LSPs joining the same Association. 404 PCC creates the first LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, 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 +---------------------------------------------------------------+ 413 Figure 9: Content of PCE ASSO DB 415 PCC creates the second LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=200, 416 LSP-ID=1, ASSO_PARAM=A, ASSO_R_FLAG=0). 418 +---------------------------------------------------------------+ 419 | ASSO | LSP | 420 +-----------------+---------------------------------------------+ 421 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 422 | | PLSP-ID=200, LSP-ID=1 | 423 +---------------------------------------------------------------+ 425 Figure 10: Content of PCE ASSO DB 427 PCC updates the first LSP, the PCC is NOT REQUIRED to send the 428 ASSOCIATION object in this PCRpt, since the LSP is already in the 429 Association. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=1). The 430 content of the PCE ASSO DB is unchanged. Note that the PCC MUST send 431 the ASSOCIATION OBJECT in the first PCRpt during SYNC state, even if 432 it has already issued a PCRpt with the association object sometime in 433 the past with this PCE. The synchronization steps outlined in 434 [RFC8697] are to be followed. 436 +---------------------------------------------------------------+ 437 | ASSO | LSP | 438 +-----------------+---------------------------------------------+ 439 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 440 | | PLSP-ID=200, LSP-ID=1 | 441 +---------------------------------------------------------------+ 443 Figure 11: Content of PCE ASSO DB 445 PCC decides to delete the second LSP. PCC sends PCRpt(R-FLAG=1, 446 PLSP-ID=200, LSP-ID=1). 448 +---------------------------------------------------------------+ 449 | ASSO | LSP | 450 +-----------------+---------------------------------------------+ 451 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 452 +---------------------------------------------------------------+ 454 Figure 12: Content of PCE ASSO DB 456 PCC decides to remove the first LSP from the Association, but not 457 delete the LSP itself. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, LSP- 458 ID=1, ASSO_PARAM=A, ASSO_R_FLAG=1). The PCE ASSO DB is now empty. 460 +---------------------------------------------------------------+ 461 | ASSO | LSP | 462 +-----------------+---------------------------------------------+ 463 | ASSO_PARAM=A | | 464 +---------------------------------------------------------------+ 466 Figure 13: Content of PCE ASSO DB 468 4.2. Switch Association during MBB 470 Each new LSP (identified by the LSP-ID) does not inherit the 471 Association membership of any previous LSPs within the same Tunnel. 472 This is done so that a Tunnel can have two LSPs that are in different 473 Associations, this may be required when switching from one 474 Association to another. 476 Below, we give an example a Tunnel going through MBB and switching 477 from Association A to Association B. 479 PCC creates the first LSP. PCC sends PCRpt(R-FLAG=0, PLSP-ID=100, 480 LSP-ID=1, ASSO_PARAM=A, ASSO_R_FLAG=0). 482 +---------------------------------------------------------------+ 483 | ASSO | LSP | 484 +-----------------+---------------------------------------------+ 485 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 486 +---------------------------------------------------------------+ 488 Figure 14: Content of PCE ASSO DB 490 PCC creates the MBB LSP in a different Association. PCC sends 491 PCRpt(R-FLAG=0, PLSP-ID=100, LSP-ID=2, ASSO_PARAM=B, ASSO_R_FLAG=0). 493 +---------------------------------------------------------------+ 494 | ASSO | LSP | 495 +-----------------+---------------------------------------------+ 496 | ASSO_PARAM=A | PLSP-ID=100, LSP-ID=1 | 497 +---------------------------------------------------------------+ 498 | ASSO_PARAM=B | PLSP-ID=100, LSP-ID=2 | 499 +---------------------------------------------------------------+ 501 Figure 15: Content of PCE ASSO DB 503 PCC deletes the old LSP. PCC sends PCRpt(R-FLAG=1, PLSP-ID=100, LSP- 504 ID=1). 506 +---------------------------------------------------------------+ 507 | ASSO | LSP | 508 +-----------------+---------------------------------------------+ 509 | ASSO_PARAM=B | PLSP-ID=100, LSP-ID=2 | 510 +---------------------------------------------------------------+ 512 Figure 16: Content of PCE ASSO DB 514 5. Computation Constraints 516 For any PCEP object that does not have an explicit removal flag, the 517 absence of that object indicates removal of the constraint specified 518 by that object. For example, suppose the first state-report contains 519 an LSPA object with some affinity constraints. Then if a subsequent 520 state-report does not contain an LSPA object, then this means that 521 the previously specified affinity constraints do not apply anymore. 522 Same applies to all PCEP objects, like METRIC, BANDWIDTH, etc., which 523 do not have an explicit flag for removal. This simply ensures that 524 it is possible to remove a constraint without using an explicit 525 removal flag. 527 6. Security Considerations 529 None at this time. 531 7. IANA Considerations 533 None at this time. 535 8. Acknowledgement 537 9. References 539 9.1. Normative References 541 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 542 Requirement Levels", BCP 14, RFC 2119, 543 DOI 10.17487/RFC2119, March 1997, 544 . 546 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 547 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 548 DOI 10.17487/RFC5440, March 2009, 549 . 551 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 552 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 553 May 2017, . 555 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 556 Computation Element Communication Protocol (PCEP) 557 Extensions for Stateful PCE", RFC 8231, 558 DOI 10.17487/RFC8231, September 2017, 559 . 561 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 562 Computation Element Communication Protocol (PCEP) 563 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 564 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 565 . 567 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 568 Dhody, D., and Y. Tanaka, "Path Computation Element 569 Communication Protocol (PCEP) Extensions for Establishing 570 Relationships between Sets of Label Switched Paths 571 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 572 . 574 9.2. Informative References 576 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 577 Element (PCE)-Based Architecture", RFC 4655, 578 DOI 10.17487/RFC4655, August 2006, 579 . 581 Appendix A. Contributors 583 Dhruv Dhody 584 Huawei Technologies 585 Divyashree Techno Park, Whitefield 586 Bangalore, Karnataka 560066 587 India 589 Email: dhruv.ietf@gmail.com 591 Andrew Stone 592 Nokia 593 Ottawa, Canada 595 Email: andrew.stone@nokia.com 597 Authors' Addresses 599 Mike Koldychev 600 Cisco Systems, Inc. 601 2000 Innovation Drive 602 Kanata, Ontario K2K 3E8 603 Canada 605 Email: mkoldych@cisco.com 607 Siva Sivabalan 608 Cisco Systems, Inc. 609 2000 Innovation Drive 610 Kanata, Ontario K2K 3E8 611 Canada 613 Email: msiva@cisco.com 614 Mahendra Singh Negi 615 Huawei Technologies 617 Email: mahendrasingh@huawei.com 619 Diego Achaval 620 Nokia 622 Email: diego.achaval@nokia.com 624 Hari Kotni 625 Juniper Networks, Inc 627 Email: hkotni@juniper.net