idnits 2.17.1 draft-dhody-pce-stateful-pce-optional-06.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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8231, but the abstract doesn't seem to directly say this. It does mention RFC8231 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 09, 2020) is 1386 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) -- Obsolete informational reference (is this intentional?): RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-14 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 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: January 10, 2021 Cisco 7 July 09, 2020 9 Extension for Stateful PCE to allow Optional Processing of PCEP Objects 10 draft-dhody-pce-stateful-pce-optional-06 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 the 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 January 10, 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 a dynamic network. 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 on unknown objects as per the 133 setting of the P flag for the PCReq message. Further [RFC8231] 134 defined the usage of LSP Error Code TLV in PCRpt message in response 135 to failed LSP Update Request via PCUpd message (for example, due to 136 an unsupported object/TLV). 138 This document clarifies the procedure for 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 that 152 this limiting constraint can be relaxed by the PCE in case it cannot 153 find a path. Similarly in case of an association groups [RFC8697] 154 such as Disjoint Association [I-D.ietf-pce-association-diversity], 155 the PCE may need to completely relax the disjointness constraint in 156 order to provide a path to all the LSPs that are part of the 157 association. In these case it would be useful to mark the objects as 158 'optional' and it could be ignored by the PCEP peer. Also it would 159 be useful for the PCEP speaker to learn if the PCEP peer has relaxed 160 the constraint and 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 exchanges. 166 3. PCEP Extension 168 3.1. STATEFUL-PCE-CAPABILITY TLV 170 A PCEP speaker indicates its ability to support for handling of the P 171 and I flag during the stateful PCEP message exchanges during the PCEP 172 initialization phase, as follows. When the PCEP session is created, 173 it sends an Open message with an OPEN object that contains the 174 STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new flag, 175 the R (RELAX) flag, is introduced to this TLV to indicate support for 176 relaxing the processing of some objects via the use of P and I flag 177 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 handling of P and I flags in the PCEP common object 182 header for stateful PCE messages. In case the bit is unset, it 183 indicates that the PCEP Speaker would not handle P and I flags in the 184 PCEP 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 handling of P and I flag in the PCEP common object header to 188 allow relaxing some constraints by marking objects as optional to 189 process. If the PCEP speaker that did not set R flag but receives 190 PCEP objects with P or I bit set, MUST behave as per the processing 191 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 just optional. When the P flag is set in PCRpt message received 201 on a PCEP session on which R bit was set by both peers, the object 202 MUST be taken into account by the PCE. Conversely, when the P flag 203 is cleared, the object is optional and the PCE is free to ignore it. 204 The P flag for the mandatory objects LSP and ERO (intended path) MUST 205 be set in the PCRpt message. If the mandatory object is received 206 with the P flag set incorrectly according to the rules stated above, 207 the receiving peer MUST send a PCErr message with Error-Type=10 208 (Reception of an invalid object) and Error-value=1 (reception of an 209 object with P flag not set). On a PCEP session on which R bit was 210 set by both peers, the PCC SHOULD set the P flag by default, unless a 211 local configuration or local policy indicates that some constraints 212 (corresponding PCEP objects) can be marked as optional and could be 213 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 just 220 optional. When the P flag is set in 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 SRP, LSP and ERO MUST be 225 set in the PCUpd/PCInitiate message. If the mandatory object is 226 received with the P flag set incorrectly according to the rules 227 stated above, the receiving peer MUST send a PCErr message with 228 Error-Type=10 (Reception of an invalid object) and Error-value=1 229 (reception of an object with P flag not set). By default, the PCE 230 SHOULD set the P flag, unless a local configuration or local policy 231 indicates that some constraints (corresponding PCEP objects) can be 232 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 LSP parameters on one or more LSPs of a PCC as described 266 in [RFC8051]. Note that for the delegated LSPs, the PCE can update 267 and 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 except 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 the 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 documents clarifies how the already existing P and I flag in 296 PCEP common object header could be used during stateful PCEP 297 exchanges. It updates the unknown object error handling in stateful 298 PCEP message exchange. These changes on its own do not add any new 299 security concerns. The security considerations identified in 300 [RFC5440], [RFC8231], and [RFC8281]. 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 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 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 392 Element (PCE)-Based Architecture", RFC 4655, 393 DOI 10.17487/RFC4655, August 2006, 394 . 396 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 397 "Recommendations for Secure Use of Transport Layer 398 Security (TLS) and Datagram Transport Layer Security 399 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 400 2015, . 402 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 403 Stateful Path Computation Element (PCE)", RFC 8051, 404 DOI 10.17487/RFC8051, January 2017, 405 . 407 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 408 "Extensions to the Path Computation Element Communication 409 Protocol (PCEP) to Compute Service-Aware Label Switched 410 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 411 2017, . 413 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 414 "PCEPS: Usage of TLS to Provide a Secure Transport for the 415 Path Computation Element Communication Protocol (PCEP)", 416 RFC 8253, DOI 10.17487/RFC8253, October 2017, 417 . 419 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 420 Computation Element Communication Protocol (PCEP) 421 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 422 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 423 . 425 [RFC8697] Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 426 Dhody, D., and Y. Tanaka, "Path Computation Element 427 Communication Protocol (PCEP) Extensions for Establishing 428 Relationships between Sets of Label Switched Paths 429 (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020, 430 . 432 [I-D.ietf-pce-pcep-yang] 433 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 434 YANG Data Model for Path Computation Element 435 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 436 yang-14 (work in progress), July 2020. 438 [I-D.ietf-pce-association-diversity] 439 Litkowski, S., Sivabalan, S., Barth, C., and M. Negi, 440 "Path Computation Element Communication Protocol (PCEP) 441 Extension for LSP Diversity Constraint Signaling", draft- 442 ietf-pce-association-diversity-15 (work in progress), June 443 2020. 445 Appendix A. Contributors 447 Dhruv Dhody 448 Huawei Technologies 449 Divyashree Techno Park, Whitefield 450 Bangalore, Karnataka 560066 451 India 453 Email: dhruv.ietf@gmail.com 455 Authors' Addresses 457 Cheng Li 458 Huawei Technologies 459 Huawei Campus, No. 156 Beiqing Rd. 460 Beijing 100095 461 China 463 EMail: c.l@huawei.com 465 Haomian Zheng 466 Huawei Technologies 467 H1, Huawei Xiliu Beipo Village, Songshan Lake 468 Dongguan, Guangdong 523808 469 China 471 EMail: zhenghaomian@huawei.com 473 Stephane Litkowski 474 Cisco 476 EMail: slitkows.ietf@gmail.com