idnits 2.17.1 draft-dhody-pce-stateful-pce-optional-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 1, 2020) is 1269 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 (-23) exists of draft-ietf-pce-pcep-yang-15 -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) 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 C. Li 3 Internet-Draft H. Zheng 4 Updates: 8231 (if approved) Huawei Technologies 5 Intended status: Standards Track S. Litkowski 6 Expires: May 5, 2021 Cisco 7 November 1, 2020 9 Extension for Stateful PCE to allow Optional Processing of PCEP Objects 10 draft-dhody-pce-stateful-pce-optional-07 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 May 5, 2021. 37 Copyright Notice 39 Copyright (c) 2020 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 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Usage Example . . . . . . . . . . . . . . . . . . . . . . 4 58 3. PCEP Extension . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 4 60 3.2. Handling of P flag . . . . . . . . . . . . . . . . . . . 5 61 3.2.1. The PCRpt Message . . . . . . . . . . . . . . . . . . 5 62 3.2.2. The PCUpd Message and the PCInitiate Message . . . . 5 63 3.3. Handling of I flag . . . . . . . . . . . . . . . . . . . 5 64 3.3.1. The PCUpd Message . . . . . . . . . . . . . . . . . . 5 65 3.3.2. The PCRpt Message . . . . . . . . . . . . . . . . . . 6 66 3.3.3. The PCInitiate Message . . . . . . . . . . . . . . . 6 67 3.4. Delegation . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.5. Unknown Object Handling . . . . . . . . . . . . . . . . . 6 69 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 5.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 7 72 6. Manageability Considerations . . . . . . . . . . . . . . . . 7 73 6.1. Control of Function and Policy . . . . . . . . . . . . . 7 74 6.2. Information and Data Models . . . . . . . . . . . . . . . 7 75 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 8 76 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 8 77 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 8 78 6.6. Impact On Network Operations . . . . . . . . . . . . . . 8 79 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 82 8.2. Informative References . . . . . . . . . . . . . . . . . 9 83 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 [RFC5440] describes the Path Computation Element Communication 89 Protocol (PCEP) which enables the communication between a Path 90 Computation Client (PCC) and a Path Control Element (PCE), or between 91 two PCEs based on the PCE architecture [RFC4655]. 93 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 94 extensions to PCEP to enable active control of Multiprotocol Label 95 Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS) 96 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 97 LSPs under the active stateful PCE model, without the need for local 98 configuration on the PCC, thus allowing for dynamic control. 100 [RFC5440] defined the P flag (Processing-Rule) in the Common Object 101 Header to allow a PCC to specify in a Path Computation Request 102 (PCReq) message (sent to a PCE) whether the object must be taken into 103 account by the PCE during path computation or is optional. The I 104 flag (Ignore) is used by the PCE in a Path Computation Reply (PCRep) 105 message to indicate to a PCC whether or not an optional object was 106 considered by the PCE during path computation. Stateful PCE 107 [RFC8231] specified that the P and I flags of the PCEP objects 108 defined in [RFC8231] is to be set to zero on transmission and ignored 109 on receipt, since they are exclusively related to path computation 110 requests. The behavior for P and I flag in other messages defined in 111 [RFC5440] and other extension was not specified. This document 112 clarifies how the P and I flag could be used in the stateful PCE 113 model to identify optional objects in the Path Computation State 114 Report (PCRpt) [RFC8231], the Path Computation Update Request (PCUpd) 115 [RFC8231], and the LSP Initiate Request (PCInitiate) [RFC8281] 116 message. 118 This document updates [RFC8231] with respect to usage of the P and I 119 flag as well as the handling of unknown objects in the stateful PCEP 120 message exchange. 122 1.1. Requirements Language 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 126 "OPTIONAL" in this document are to be interpreted as described in BCP 127 14 [RFC2119] [RFC8174] when, and only when, they appear in all 128 capitals, as shown here. 130 2. Overview 132 [RFC5440] describes the handling of unknown objects as per the 133 setting of the P flag for the PCReq message. Further, [RFC8231] 134 defined the usage of the LSP Error Code TLV in the PCRpt message in 135 response to failed LSP Update Request via the PCUpd message (for 136 example, due to an unsupported object/TLV). 138 This document clarifies the procedure of marking some objects as 139 'optional to be processed' by the PCEP peer in the stateful PCEP 140 messages. Furthermore, this document updates the procedure for 141 handling unknown objects in the stateful PCEP messages based on the P 142 flag. 144 2.1. Usage Example 146 The PCRpt message is used to report the current state of an LSP. As 147 part of the message both the and is encoded (see [RFC8231]). For example, the 149 could include the METRIC object to indicate 150 a limiting constraint (B flag set) for the Path Delay Variation 151 metric [RFC8233]. In some scenarios, it would be useful to state 152 that this limiting constraint can be relaxed by the PCE in case it 153 cannot find a path. Similarly in the case of an association group 154 [RFC8697] such as Disjoint Association [RFC8800], the PCE may need to 155 completely relax the disjointness constraint in order to provide a 156 path to all the LSPs that are part of the association. In these case 157 it would be useful to mark the objects as 'optional' and it could be 158 ignored by the PCEP peer. Also, it would be useful for the PCEP 159 speaker to learn if the PCEP peer has relaxed the constraint and 160 ignored the processing of the PCEP object. 162 Thus, this document simply clarifies, how the already existing P and 163 I flag in the PCEP common object header could be used during the 164 stateful PCEP message exchange. 166 3. PCEP Extension 168 3.1. STATEFUL-PCE-CAPABILITY TLV 170 A PCEP speaker indicates its ability to support the handling of the P 171 and I flag in the stateful PCEP message exchange during the PCEP 172 initialization phase, as follows. When the PCEP session is 173 established, a PCC sends an Open message with an OPEN object that 174 contains the STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A 175 new flag, the R (RELAX) flag, is added in this TLV to indicate the 176 support for relaxing the processing of some objects via the use of 177 the P and I flag in the PCEP common object header. 179 R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag 180 indicates that the PCEP Speaker is willing to send and receive PCEP 181 objects with the P and I flags in the PCEP common object header for 182 the stateful PCE messages. In case the bit is unset, it indicates 183 that the PCEP Speaker would not handle the P and I flags in the PCEP 184 common object header for stateful PCE messages. 186 The R flag MUST be set by both a PCC and a PCE to indicate support 187 for the handling of the P and I flag in the PCEP common object header 188 to allow relaxing some constraints by marking objects as optional to 189 process. If the PCEP speaker that did not set the R flag but 190 receives PCEP objects with P or I bit set, MUST behave as per the 191 processing rule in [RFC8231] i.e., the bits are simply ignored. 193 3.2. Handling of P flag 195 3.2.1. The PCRpt Message 197 The P flag in the PCRpt message [RFC8231] allows a PCC to specify to 198 a PCE whether the object must be taken into account by the PCE 199 (during path computation, re-optimization, or state maintenance) or 200 is optional o process. When the P flag is set in the PCRpt message 201 received on a PCEP session on which R bit was set by both peers, the 202 object MUST be taken into account by the PCE. Conversely, when the P 203 flag is cleared, the object is optional and the PCE is free to ignore 204 it. The P flag for the mandatory objects such as the LSP and the ERO 205 object (intended path) MUST be set in the PCRpt message. If a 206 mandatory object is received with the P flag set incorrectly 207 according to the rules stated above, the receiving peer MUST send a 208 PCErr message with Error-Type=10 (Reception of an invalid object) and 209 Error-value=1 (reception of an object with P flag not set). On a 210 PCEP session on which R bit was set by both peers, the PCC SHOULD set 211 the P flag by default, unless a local configuration or local policy 212 indicates that some constraints (corresponding PCEP objects) can be 213 marked as optional and could be ignored by the PCE. 215 3.2.2. The PCUpd Message and the PCInitiate Message 217 The P flag in the PCUpd message [RFC8231] and the PCInitiate message 218 [RFC8281] allows a PCE to specify to a PCC whether the object must be 219 taken into account by the PCC (during path setup) or is optional to 220 process. When the P flag is set in the PCUpd/PCInitiate message 221 received on a PCEP session on which R bit was set by both peers, the 222 object MUST be taken into account by the PCC. Conversely, when the P 223 flag is cleared, the object is optional and the PCC is free to ignore 224 it. The P flag for the mandatory objects such as the SRP, the LSP 225 and the ERO MUST be set in the PCUpd/PCInitiate message. If a 226 mandatory object is received with the P flag set incorrectly 227 according to the rules stated above, the receiving peer MUST send a 228 PCErr message with Error-Type=10 (Reception of an invalid object) and 229 Error-value=1 (reception of an object with P flag not set). By 230 default, the PCE SHOULD set the P flag, unless a local configuration 231 or local policy indicates that some constraints (corresponding PCEP 232 objects) can be marked as optional and could be ignored by the PCC. 234 3.3. Handling of I flag 236 3.3.1. The PCUpd Message 238 The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to 239 a PCC whether or not an optional object was processed. The PCE MAY 240 include the ignored optional object in its update request and set the 241 I flag to indicate that the optional object was ignored. When the I 242 flag is cleared, the PCE indicates that the optional object was 243 processed. 245 3.3.2. The PCRpt Message 247 The I flag in the PCRpt message [RFC8231] allows a PCC to indicate to 248 a PCE whether or not an optional object was processed in response to 249 an LSP Update Request (PCUpd) or LSP Initiate Request (PCInitiate). 250 The PCC MAY include the ignored optional object in its report and set 251 the I flag to indicate that the optional object was ignored at PCC. 252 When the I flag is cleared, the PCC indicates that the optional 253 object was processed. The I flag has no meaning if the PCRpt message 254 is not in response to a PCUpd or PCInitiate message (i.e. without the 255 SRP object in the PCRpt message). 257 3.3.3. The PCInitiate Message 259 The I flag has no meaning in the PCinitiate message [RFC8281] and is 260 ignored. 262 3.4. Delegation 264 Delegation is an operation to grant a PCE temporary rights to modify 265 a subset of parameters on one or more LSPs by a PCC as described in 266 [RFC8051]. Note that for the delegated LSPs, the PCE can update and 267 mark some object as ignored even when the PCC had set the P flag 268 during delegation. Similarly, the PCE can update and mark some 269 object as a must to process even when the PCC had not set the P flag 270 during delegation. 272 The PCC MUST acknowledge this by sending the PCRpt message with the P 273 flag set as per the PCE expectation for the corresponding object. In 274 case PCC cannot accept this, it would react as per the processing 275 rules of unacceptable update in [RFC8231]. 277 3.5. Unknown Object Handling 279 This document updates the handling of unknown objects in stateful 280 PCEP messages as per the setting of P flag in the common object 281 header in a similar way as [RFC5440], i.e. if a PCEP speaker does not 282 understand an object with the P flag set or understands the object 283 but decides to ignore the object, the entire stateful PCEP message 284 MUST be rejected and the PCE MUST send a PCErr message with Error- 285 Type="Unknown Object" or "Not supported Object" [RFC5440]. In case 286 the P flag is not set, the PCEP speaker is free to ignore the object 287 and continue with message processing as defined. 289 [RFC8231] defined LSP Error Code TLV to be carried in PCRpt message 290 in the LSP object to convey error information. This document does 291 not change that procedure. 293 4. Security Considerations 295 This document clarifies how the already existing P and I flag in PCEP 296 common object header could be used during stateful PCEP exchanges. 297 It updates the unknown object error handling in stateful PCEP message 298 exchange. These changes on its own do not add any new security 299 concerns. The security considerations identified in [RFC5440], 300 [RFC8231], and [RFC8281] continue to apply. 302 As per [RFC8231], it is RECOMMENDED that these PCEP extensions only 303 be activated on authenticated and encrypted sessions across PCEs and 304 PCCs belonging to the same administrative authority, using Transport 305 Layer Security (TLS) [RFC8253] as per the recommendations and best 306 current practices in [RFC7525] (unless explicitly set aside in 307 [RFC8253]). 309 5. IANA Considerations 311 5.1. STATEFUL-PCE-CAPABILITY TLV 313 [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA 314 created a "STATEFUL-PCE-CAPABILITY TLV Flag Field" subregistry to 315 manage the value of the STATEFUL-PCE-CAPABILITY TLV's Flag field. 316 IANA is requested to allocate a new bit in the subregistry, as 317 follows: 319 Bit Description Reference 320 ------------------------------------------------- 321 TBD1 RELAX bit [This-I.D.] 323 6. Manageability Considerations 325 6.1. Control of Function and Policy 327 An operator MUST be allowed to configure the capability to support 328 relaxation of constraints in the stateful PCEP message exchange. 329 They SHOULD also allow configuration of related LSP constraints (or 330 parameters) that are optional to process. 332 6.2. Information and Data Models 334 An implementation SHOULD allow the operator to view the capability 335 defined in this document. To serve this purpose, the PCEP YANG 336 module [I-D.ietf-pce-pcep-yang] could be extended in the future. 338 6.3. Liveness Detection and Monitoring 340 Mechanisms defined in this document do not imply any new liveness 341 detection and monitoring requirements in addition to those already 342 listed in [RFC5440]. 344 6.4. Verify Correct Operations 346 Mechanisms defined in this document do not imply any new operation 347 verification requirements in addition to those already listed in 348 [RFC5440]. 350 6.5. Requirements On Other Protocols 352 Mechanisms defined in this document do not imply any new requirements 353 on other protocols. 355 6.6. Impact On Network Operations 357 Mechanisms defined in this document do not have any impact on network 358 operations in addition to those already listed in [RFC5440]. 360 7. Acknowledgments 362 Thanks to Jonathan Hardwick for discussion and suggestions around 363 this draft. 365 8. References 367 8.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, 371 DOI 10.17487/RFC2119, March 1997, 372 . 374 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 375 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 376 DOI 10.17487/RFC5440, March 2009, 377 . 379 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 380 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 381 May 2017, . 383 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 384 Computation Element Communication Protocol (PCEP) 385 Extensions for Stateful PCE", RFC 8231, 386 DOI 10.17487/RFC8231, September 2017, 387 . 389 8.2. Informative References 391 [I-D.ietf-pce-pcep-yang] 392 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 393 YANG Data Model for Path Computation Element 394 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 395 yang-15 (work in progress), October 2020. 397 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 398 Element (PCE)-Based Architecture", RFC 4655, 399 DOI 10.17487/RFC4655, August 2006, 400 . 402 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 403 "Recommendations for Secure Use of Transport Layer 404 Security (TLS) and Datagram Transport Layer Security 405 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 406 2015, . 408 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 409 Stateful Path Computation Element (PCE)", RFC 8051, 410 DOI 10.17487/RFC8051, January 2017, 411 . 413 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 414 "Extensions to the Path Computation Element Communication 415 Protocol (PCEP) to Compute Service-Aware Label Switched 416 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 417 2017, . 419 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 420 "PCEPS: Usage of TLS to Provide a Secure Transport for the 421 Path Computation Element Communication Protocol (PCEP)", 422 RFC 8253, DOI 10.17487/RFC8253, October 2017, 423 . 425 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 426 Computation Element Communication Protocol (PCEP) 427 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 428 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 429 . 431 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 432 Dhody, D., and Y. Tanaka, "Path Computation Element 433 Communication Protocol (PCEP) Extensions for Establishing 434 Relationships between Sets of Label Switched Paths 435 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 436 . 438 [RFC8800] Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, 439 "Path Computation Element Communication Protocol (PCEP) 440 Extension for Label Switched Path (LSP) Diversity 441 Constraint Signaling", RFC 8800, DOI 10.17487/RFC8800, 442 July 2020, . 444 Appendix A. Contributors 446 Dhruv Dhody 447 Huawei Technologies 448 Divyashree Techno Park, Whitefield 449 Bangalore, Karnataka 560066 450 India 452 Email: dhruv.ietf@gmail.com 454 Authors' Addresses 456 Cheng Li 457 Huawei Technologies 458 Huawei Campus, No. 156 Beiqing Rd. 459 Beijing 100095 460 China 462 EMail: c.l@huawei.com 464 Haomian Zheng 465 Huawei Technologies 466 H1, Huawei Xiliu Beipo Village, Songshan Lake 467 Dongguan, Guangdong 523808 468 China 470 EMail: zhenghaomian@huawei.com 472 Stephane Litkowski 473 Cisco 475 EMail: slitkows.ietf@gmail.com