idnits 2.17.00 (12 Aug 2021) /tmp/idnits56960/draft-ietf-pce-stateful-pce-optional-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (21 April 2022) is 23 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 (~~), 0 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group C. Li 3 Internet-Draft H. Zheng 4 Updates: 8231 (if approved) Huawei Technologies 5 Intended status: Standards Track S. Litkowski 6 Expires: 23 October 2022 Cisco 7 21 April 2022 9 Extension for Stateful PCE to allow Optional Processing of PCEP Objects 10 draft-ietf-pce-stateful-pce-optional-03 12 Abstract 14 This document introduces a mechanism to mark some of the Path 15 Computation Element (PCE) Communication Protocol (PCEP) objects as 16 optional during PCEP messages exchange for the Stateful PCE model to 17 allow relaxing some constraints. This document introduces this 18 relaxation and updates RFC 8231. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 23 October 2022. 37 Copyright Notice 39 Copyright (c) 2022 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Usage Example . . . . . . . . . . . . . . . . . . . . . . 4 57 3. PCEP Extension . . . . . . . . . . . . . . . . . . . . . . . 4 58 3.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 5 59 3.2. Handling of P flag . . . . . . . . . . . . . . . . . . . 5 60 3.2.1. The PCRpt Message . . . . . . . . . . . . . . . . . . 5 61 3.2.2. The PCUpd Message and the PCInitiate Message . . . . 6 62 3.3. Handling of I flag . . . . . . . . . . . . . . . . . . . 6 63 3.3.1. The PCUpd Message . . . . . . . . . . . . . . . . . . 6 64 3.3.2. The PCRpt Message . . . . . . . . . . . . . . . . . . 6 65 3.3.3. The PCInitiate Message . . . . . . . . . . . . . . . 7 66 3.4. Delegation . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.5. Unknown Object Handling . . . . . . . . . . . . . . . . . 7 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 70 5.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 8 71 6. Manageability Considerations . . . . . . . . . . . . . . . . 8 72 6.1. Control of Function and Policy . . . . . . . . . . . . . 8 73 6.2. Information and Data Models . . . . . . . . . . . . . . . 8 74 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 9 75 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 9 76 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 9 77 6.6. Impact On Network Operations . . . . . . . . . . . . . . 9 78 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 8.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 [RFC5440] describes the Path Computation Element Communication 88 Protocol (PCEP) which enables the communication between a Path 89 Computation Client (PCC) and a Path Control Element (PCE), or between 90 two PCEs based on the PCE architecture [RFC4655]. 92 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 93 extensions to PCEP to enable active control of Multiprotocol Label 94 Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS) 95 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 96 LSPs under the active stateful PCE model, without the need for local 97 configuration on the PCC, thus allowing for dynamic control. 99 [RFC5440] defined the P flag (Processing-Rule) in the Common Object 100 Header to allow a PCC to specify in a Path Computation Request 101 (PCReq) message (sent to a PCE) whether the object must be taken into 102 account by the PCE during path computation or is optional. The I 103 flag (Ignore) is used by the PCE in a Path Computation Reply (PCRep) 104 message to indicate to a PCC whether or not an optional object was 105 considered by the PCE during path computation. Stateful PCE 106 [RFC8231] specified that the P and I flags of the PCEP objects 107 defined in [RFC8231] is to be set to zero on transmission and ignored 108 on receipt, since they are exclusively related to path computation 109 requests. The behavior for P and I flag in other messages defined in 110 [RFC5440] and other extension was not specified. This document 111 clarifies how the P and I flag could be used in the stateful PCE 112 model to identify optional objects in the Path Computation State 113 Report (PCRpt) [RFC8231], the Path Computation Update Request (PCUpd) 114 [RFC8231], and the LSP Initiate Request (PCInitiate) [RFC8281] 115 message. 117 This document updates [RFC8231] with respect to usage of the P and I 118 flag as well as the handling of unknown objects in the stateful PCEP 119 message exchange. 121 1.1. Requirements Language 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in BCP 126 14 [RFC2119] [RFC8174] when, and only when, they appear in all 127 capitals, as shown here. 129 2. Overview 131 [RFC5440] describes the handling of unknown objects as per the 132 setting of the P flag for the PCReq message. Further, [RFC8231] 133 defined the usage of the LSP Error Code TLV in the PCRpt message in 134 response to failed LSP Update Request via the PCUpd message (for 135 example, due to an unsupported object/TLV). 137 This document clarifies the procedure of marking some objects as 138 'optional to be processed' by the PCEP peer in the stateful PCEP 139 messages. Furthermore, this document updates the procedure for 140 handling unknown objects in the stateful PCEP messages based on the P 141 flag. 143 2.1. Usage Example 145 The PCRpt message is used to report the current state of an LSP. As 146 part of the message both the and is encoded (see [RFC8231]). For example, the 148 could include the METRIC object to indicate 149 a limiting constraint (B flag set) for the Path Delay Variation 150 metric [RFC8233]. In some scenarios, it would be useful to state 151 that this limiting constraint can be relaxed by the PCE in case it 152 cannot find a path. Similarly in the case of an association group 153 [RFC8697] such as Disjoint Association [RFC8800], the PCE may need to 154 completely relax the disjointness constraint in order to provide a 155 path to all the LSPs that are part of the association. In these case 156 it would be useful to mark the objects as 'optional' and it could be 157 ignored by the PCEP peer. Also, it would be useful for the PCEP 158 speaker to learn if the PCEP peer has relaxed the constraint and 159 ignored the processing of the PCEP object. 161 Thus, this document simply clarifies, how the already existing P and 162 I flag in the PCEP common object header could be used during the 163 stateful PCEP message exchange. Further it should be noted that 164 similar to handling of P and I flag in [RFC5440], the flag is 165 applicable to full PCEP Object and could not be applied to the 166 granularity of an optional TLV encoded in the PCEP Object. 168 3. PCEP Extension 169 3.1. STATEFUL-PCE-CAPABILITY TLV 171 A PCEP speaker indicates its ability to support the handling of the P 172 and I flag in the stateful PCEP message exchange during the PCEP 173 initialization phase, as follows. When the PCEP session is 174 established, a PCC sends an Open message with an OPEN object that 175 contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A 176 new flag, the R (RELAX) flag, is added in this TLV to indicate the 177 support for relaxing the processing of some objects via the use of 178 the P and I flag in the PCEP common object header. 180 R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag 181 indicates that the PCEP Speaker is willing to send and receive PCEP 182 objects with the P and I flags in the PCEP common object header for 183 the stateful PCE messages. In case the bit is unset, it indicates 184 that the PCEP Speaker would not handle the P and I flags in the PCEP 185 common object header for stateful PCE messages. 187 The R flag MUST be set by both a PCC and a PCE to indicate support 188 for the handling of the P and I flag in the PCEP common object header 189 to allow relaxing some constraints by marking objects as optional to 190 process. If the PCEP speaker did not set the R flag but receives 191 PCEP objects with P or I bit set, it MUST behave as per the 192 processing rule in [RFC8231] i.e., the bits are simply ignored. 194 3.2. Handling of P flag 196 3.2.1. The PCRpt Message 198 The P flag in the PCRpt message [RFC8231] allows a PCC to specify to 199 a PCE whether the object must be taken into account by the PCE 200 (during path computation, re-optimization, or state maintenance) or 201 is optional o process. When the P flag is set in the PCRpt message 202 received on a PCEP session on which R bit was set by both peers, the 203 object MUST be taken into account by the PCE. Conversely, when the P 204 flag is cleared, the object is optional and the PCE is free to ignore 205 it. The P flag for the mandatory objects such as the LSP and the ERO 206 object (intended path) MUST be set in the PCRpt message. If a 207 mandatory object is received with the P flag set incorrectly 208 according to the rules stated above, the receiving peer MUST send a 209 PCErr message with Error-Type=10 (Reception of an invalid object) and 210 Error-value=1 (reception of an object with P flag not set). On a 211 PCEP session on which R bit was set by both peers, the PCC SHOULD set 212 the P flag by default, unless a local configuration or local policy 213 indicates that some constraints (corresponding PCEP objects) can be 214 marked as optional and could be ignored by the PCE. 216 3.2.2. The PCUpd Message and the PCInitiate Message 218 The P flag in the PCUpd message [RFC8231] and the PCInitiate message 219 [RFC8281] allows a PCE to specify to a PCC whether the object must be 220 taken into account by the PCC (during path setup) or is optional to 221 process. When the P flag is set in the PCUpd/PCInitiate message 222 received on a PCEP session on which R bit was set by both peers, the 223 object MUST be taken into account by the PCC. Conversely, when the P 224 flag is cleared, the object is optional and the PCC is free to ignore 225 it. The P flag for the mandatory objects such as the SRP, the LSP 226 and the ERO MUST be set in the PCUpd/PCInitiate message. If a 227 mandatory object is received with the P flag set incorrectly 228 according to the rules stated above, the receiving peer MUST send a 229 PCErr message with Error-Type=10 (Reception of an invalid object) and 230 Error-value=1 (reception of an object with P flag not set). By 231 default, the PCE SHOULD set the P flag, unless a local configuration 232 or local policy indicates that some constraints (corresponding PCEP 233 objects) can be marked as optional and could be ignored by the PCC. 235 3.3. Handling of I flag 237 3.3.1. The PCUpd Message 239 The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to 240 a PCC whether or not an optional object was processed. The PCE MAY 241 include the ignored optional object in its update request and set the 242 I flag to indicate that the optional object was ignored. When the I 243 flag is cleared, the PCE indicates that the optional object was 244 processed. 246 Note that when a PCE is unable to find the path that meets all the 247 constraints as per the PCEP Object that cannot be ignored (i.e. P 248 flag is set), the PCUpd message MAY optionally include the PCEP 249 Objects that caused the path computation to fail along with the with 250 the empty ERO. 252 3.3.2. The PCRpt Message 254 The I flag in the PCRpt message [RFC8231] allows a PCC to indicate to 255 a PCE whether or not an optional object was processed in response to 256 an LSP Update Request (PCUpd) or LSP Initiate Request (PCInitiate). 257 The PCC MAY include the ignored optional object in its report and set 258 the I flag to indicate that the optional object was ignored at PCC. 259 When the I flag is cleared, the PCC indicates that the optional 260 object was processed. The I flag has no meaning if the PCRpt message 261 is not in response to a PCUpd or PCInitiate message (i.e. without the 262 SRP object in the PCRpt message). 264 Note that when a PCC is unable to setup the path that meets all the 265 parameters as per the PCEP Object that cannot be ignored (i.e. P 266 flag is set), the PCRpt message MAY optionally include the PCEP 267 Objects that caused the path setup to fail along with the LSP-ERROR- 268 CODE TLV [RFC8231] indicating the reason for the failure. 270 3.3.3. The PCInitiate Message 272 The I flag has no meaning in the PCinitiate message [RFC8281] and is 273 ignored. 275 3.4. Delegation 277 Delegation is an operation to grant a PCE temporary rights to modify 278 a subset of parameters on one or more LSPs by a PCC as described in 279 [RFC8051]. Note that for the delegated LSPs, the PCE can update and 280 mark some objects as ignored even when the PCC had set the P flag 281 during delegation. Similarly, the PCE can update and mark some 282 object as a must to process even when the PCC had not set the P flag 283 during delegation. 285 The PCC MUST acknowledge this by sending the PCRpt message with the P 286 flag set as per the PCE expectation for the corresponding object. In 287 case PCC cannot accept this, it would react as per the processing 288 rules of unacceptable update in [RFC8231]. 290 3.5. Unknown Object Handling 292 This document updates the handling of unknown objects in the stateful 293 PCEP messages as per the setting of the P flag in the common object 294 header in a similar way as [RFC5440], i.e. if a PCEP speaker does not 295 understand an object with the P flag set or understands the object 296 but decides to ignore the object, the entire stateful PCEP message 297 MUST be rejected and the PCE MUST send a PCErr message with Error- 298 Type="Unknown Object" or "Not supported Object" [RFC5440]. In case 299 the P flag is not set, the PCEP speaker is free to ignore the object 300 and continue with message processing as defined. 302 [RFC8231] defined LSP Error Code TLV to be carried in PCRpt message 303 in the LSP object to convey error information. This document does 304 not change that procedure. 306 4. Security Considerations 308 This document clarifies how the already existing P and I flag in PCEP 309 common object header could be used during stateful PCEP exchanges. 310 It updates the unknown object error handling in stateful PCEP message 311 exchange. These changes on their own do not add any new security 312 concerns. The security considerations identified in [RFC5440], 313 [RFC8231], and [RFC8281] continue to apply. 315 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 316 be activated on authenticated and encrypted sessions across PCEs and 317 PCCs belonging to the same administrative authority, using Transport 318 Layer Security (TLS) [RFC8253] as per the recommendations and best 319 current practices in [RFC7525] (unless explicitly set aside in 320 [RFC8253]). 322 5. IANA Considerations 324 5.1. STATEFUL-PCE-CAPABILITY TLV 326 [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA 327 created a "STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry to 328 manage the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field. 329 IANA is requested to allocate a new bit in the subregistry, as 330 follows: 332 Bit Description Reference 333 ------------------------------------------------- 334 TBD1 RELAX bit [This-I.D.] 336 6. Manageability Considerations 338 6.1. Control of Function and Policy 340 An operator MUST be allowed to configure the capability to support 341 relaxation of constraints in the stateful PCEP message exchange. 342 They SHOULD also allow configuration of related LSP constraints (or 343 parameters) that are optional to process. 345 6.2. Information and Data Models 347 An implementation SHOULD allow the operator to view the capability 348 defined in this document. To serve this purpose, the PCEP YANG 349 module [I-D.ietf-pce-pcep-yang] could be extended in the future. 351 6.3. Liveness Detection and Monitoring 353 Mechanisms defined in this document do not imply any new liveness 354 detection and monitoring requirements in addition to those already 355 listed in [RFC5440]. 357 6.4. Verify Correct Operations 359 Mechanisms defined in this document do not imply any new operation 360 verification requirements in addition to those already listed in 361 [RFC5440]. 363 6.5. Requirements On Other Protocols 365 Mechanisms defined in this document do not imply any new requirements 366 on other protocols. 368 6.6. Impact On Network Operations 370 Mechanisms defined in this document do not have any impact on network 371 operations in addition to those already listed in [RFC5440]. 373 7. Acknowledgments 375 Thanks to Jonathan Hardwick for discussion and suggestions around 376 this draft. 378 Thanks to Oscar Gonzalez de Dios and Mike Koldychev for the review 379 comments. 381 8. References 383 8.1. Normative References 385 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 386 Requirement Levels", BCP 14, RFC 2119, 387 DOI 10.17487/RFC2119, March 1997, 388 . 390 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 391 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 392 DOI 10.17487/RFC5440, March 2009, 393 . 395 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 396 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 397 May 2017, . 399 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 400 Computation Element Communication Protocol (PCEP) 401 Extensions for Stateful PCE", RFC 8231, 402 DOI 10.17487/RFC8231, September 2017, 403 . 405 8.2. Informative References 407 [I-D.ietf-pce-pcep-yang] 408 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 409 "A YANG Data Model for Path Computation Element 410 Communications Protocol (PCEP)", Work in Progress, 411 Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January 412 2022, . 415 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 416 Computation Element (PCE)-Based Architecture", RFC 4655, 417 DOI 10.17487/RFC4655, August 2006, 418 . 420 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 421 "Recommendations for Secure Use of Transport Layer 422 Security (TLS) and Datagram Transport Layer Security 423 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 424 2015, . 426 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 427 Stateful Path Computation Element (PCE)", RFC 8051, 428 DOI 10.17487/RFC8051, January 2017, 429 . 431 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 432 "Extensions to the Path Computation Element Communication 433 Protocol (PCEP) to Compute Service-Aware Label Switched 434 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 435 2017, . 437 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 438 "PCEPS: Usage of TLS to Provide a Secure Transport for the 439 Path Computation Element Communication Protocol (PCEP)", 440 RFC 8253, DOI 10.17487/RFC8253, October 2017, 441 . 443 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 444 Computation Element Communication Protocol (PCEP) 445 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 446 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 447 . 449 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 450 Dhody, D., and Y. Tanaka, "Path Computation Element 451 Communication Protocol (PCEP) Extensions for Establishing 452 Relationships between Sets of Label Switched Paths 453 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 454 . 456 [RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, 457 "Path Computation Element Communication Protocol (PCEP) 458 Extension for Label Switched Path (LSP) Diversity 459 Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800, 460 July 2020, . 462 Appendix A. Contributors 464 Dhruv Dhody 465 Huawei Technologies 466 Divyashree Techno Park, Whitefield 467 Bangalore, Karnataka 560066 468 India 470 Email: dhruv.ietf@gmail.com 472 Authors' Addresses 474 Cheng Li 475 Huawei Technologies 476 Huawei Campus, No. 156 Beiqing Rd. 477 Beijing 478 100095 479 China 480 Email: c.l@huawei.com 482 Haomian Zheng 483 Huawei Technologies 484 H1, Huawei Xiliu Beipo Village, Songshan Lake 485 Dongguan 486 Guangdong, 523808 487 China 488 Email: zhenghaomian@huawei.com 489 Stephane Litkowski 490 Cisco 491 Email: slitkows.ietf@gmail.com