idnits 2.17.1 draft-dhody-pce-stateful-pce-optional-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC8231, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2018) is 2136 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-07 == Outdated reference: A later version (-10) exists of draft-ietf-pce-association-group-06 == Outdated reference: A later version (-15) exists of draft-ietf-pce-association-diversity-04 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group D. Dhody, Ed. 3 Internet-Draft Huawei Technologies 4 Updates: 8231 (if approved) S. Litkowski 5 Intended status: Standards Track Orange 6 Expires: December 22, 2018 June 20, 2018 8 Extension for Stateful PCE to allow Optional Processing of PCEP Objects. 9 draft-dhody-pce-stateful-pce-optional-01 11 Abstract 13 This document introduces a mechanism to mark some Path Computation 14 Element (PCE) Communication Protocol (PCEP) objects as optional 15 during PCEP messages exchange for the Stateful PCE model to allow 16 relaxing some constraints. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on December 22, 2018. 35 Copyright Notice 37 Copyright (c) 2018 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (https://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Usage Example . . . . . . . . . . . . . . . . . . . . . . 3 56 3. PCEP Extension . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 4 58 3.2. Handling of P flag . . . . . . . . . . . . . . . . . . . 4 59 3.2.1. The PCRpt message . . . . . . . . . . . . . . . . . . 4 60 3.2.2. The PCUpd message and the PCInitiate message . . . . 5 61 3.3. Handling of I flag . . . . . . . . . . . . . . . . . . . 5 62 3.3.1. The PCUpd message . . . . . . . . . . . . . . . . . . 5 63 3.3.2. The PCRpt message . . . . . . . . . . . . . . . . . . 5 64 3.3.3. The PCInitiate message . . . . . . . . . . . . . . . 6 65 3.4. Delegation . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.5. Unknown Object Handling . . . . . . . . . . . . . . . . . 6 67 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 5.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 7 70 6. Manageability Considerations . . . . . . . . . . . . . . . . 7 71 6.1. Control of Function and Policy . . . . . . . . . . . . . 7 72 6.2. Information and Data Models . . . . . . . . . . . . . . . 7 73 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 7 74 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 7 75 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 8 76 6.6. Impact On Network Operations . . . . . . . . . . . . . . 8 77 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 80 8.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction 85 [RFC5440] describes the Path Computation Element communication 86 Protocol (PCEP) which enables the communication between a Path 87 Computation Client (PCC) and a Path Control Element (PCE), or between 88 two PCEs based on the PCE architecture [RFC4655]. 90 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 91 extensions to PCEP to enable active control of Multiprotocol Label 92 Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS) 93 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 94 LSPs under the active stateful PCE model, without the need for local 95 configuration on the PCC, thus allowing for a dynamic network. 97 [RFC5440] defined P flag (Processing-Rule) as part of Common Object 98 Header to allow a PCC to specify in a PCReq message sent to a PCE 99 whether the object must be taken into account by the PCE during path 100 computation or is just optional. The I flag (Ignore) is used by a 101 PCE in a PCRep message to indicate to a PCC whether or not an 102 optional object was processed. Stateful PCE [RFC8231] specified that 103 P and I flags of the PCEP objects defined in [RFC8231] is to be set 104 to 0 on transmission and ignored on receipt since they are 105 exclusively related to path computation requests. The behavior for P 106 and I flag in other objects defined in [RFC5440] and other extension 107 was not specified. This document clarifies how the P and I flag 108 could be used in the stateful PCE model to identify optional objects 109 in the Path Computation State Report (PCRpt), the Path Computation 110 Update Request (PCUpd) and the LSP Initiate Request (PCInitiate) 111 message. 113 This document updates [RFC8231] with respect to usage of P and I flag 114 as well as handling of unknown objects in stateful PCEP message 115 exchanges. 117 1.1. Requirements Language 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 121 "OPTIONAL" in this document are to be interpreted as described in BCP 122 14 [RFC2119] [RFC8174] when, and only when, they appear in all 123 capitals, as shown here. 125 2. Overview 127 [RFC5440] describes the handling on unknown objects as per the 128 setting of the P flag for the PCReq message. Further [RFC8231] 129 defined the usage of LSP Error Code TLV in PCRpt message in response 130 to failed LSP Update Request via PCUpd message (for example, due to 131 an unsupported object or a TLV). 133 This document clarifies the procedure for marking some objects as 134 optional to be processed by the PCEP peer in the stateful PCEP 135 messages. Further this document updates the procedure for handling 136 unknown objects in the stateful PCEP messages based on the P flag. 138 2.1. Usage Example 140 The PCRpt message is used to report the current state of an LSP. As 141 part of the message both the and is encoded. The could 143 include the METRIC object to indicate a limiting constraint (B flag 144 set) for the Path Delay Variation metric [RFC8233]. In some 145 scenarios it would be useful to state that this limiting constraint 146 can be relaxed by the PCE, in case it cannot find a path. Similarly 147 in case of an association groups [I-D.ietf-pce-association-group] 148 such as Disjoint Association [I-D.ietf-pce-association-diversity], 149 the PCE may need to completely relax the disjointness constraint in 150 order to provide a path to all the LSPs that are part of the 151 association. In these case it would be useful to mark the objects as 152 'optional' and it could be ignored by the PCEP peer. Also it would 153 be used for the PCEP speaker to learn if the PCEP peer has relaxed 154 the constraint and ignored the processing of the PCEP object. 156 Thus, this document simply clarifies how the already existing P and I 157 flag in PCEP common object header could be used during stateful PCEP 158 exchanges. 160 3. PCEP Extension 162 3.1. STATEFUL-PCE-CAPABILITY TLV 164 A PCEP speaker indicates its ability to support for handling P and I 165 flag during the stateful PCEP message exchanges during the PCEP 166 initialization phase, as follows. When the PCEP session is created, 167 it sends an Open message with an OPEN object that contains the 168 STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new flag, 169 the R (RELAX) flag, is introduced to this TLV to indicate support for 170 relaxing the processing of some objects via the use of P and I flag 171 in PCEP common object header. 173 R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag 174 indicates that the PCEP Speaker is willing to send and receive PCEP 175 objects with handling of P and I flags in the PCEP common object 176 header. In case the bit is unset, it indicates that the PCEP Speaker 177 would not handle P and I flags in the PCEP common object header. 179 The R flag must be set by both a PCC and a PCE for handling of P and 180 I flag in the PCEP common object header to allow relaxing some 181 constraints by marking objects as optional to process. If the PCEP 182 speaker that did not set R flag but receives PCEP objects with P or I 183 bit set, would behave as per the processing rule in [RFC8231]. 185 3.2. Handling of P flag 187 3.2.1. The PCRpt message 189 The P flag in the PCRpt message [RFC8231] allows a PCC to specify to 190 a PCE whether the object must be taken into account by the PCE 191 (during path computation or re-optimization) or is just optional. 192 When the P flag is set in PCRpt message, the object MUST be taken 193 into account by the PCE. Conversely, when the P flag is cleared, the 194 object is optional and the PCE is free to ignore it. The P flag for 195 the mandatory objects LSP and ERO (intended path) MUST be set in the 196 PCRpt message. If the mandatory object is received with the P flag 197 set incorrectly according to the rules stated above, the receiving 198 peer MUST send a PCErr message with Error-Type=10 (Reception of an 199 invalid object) and Error-value=1 (reception of an object with P flag 200 not set). By default, the PCC SHOULD set the P flag, unless a local 201 configuration or local policy indicates that some constraints 202 (corresponding PCEP objects) can be marked as optional and could be 203 ignored by the PCE. 205 3.2.2. The PCUpd message and the PCInitiate message 207 The P flag in the PCUpd message [RFC8231] and the PCInitiate message 208 [RFC8281] allows a PCE to specify to a PCC whether the object must be 209 taken into account by the PCC (during path setup) or is just 210 optional. When the P flag is set in PCUpd/PCInitiate, the object 211 MUST be taken into account by the PCC. Conversely, when the P flag 212 is cleared, the object is optional and the PCC is free to ignore it. 213 The P flag for the mandatory objects SRP, LSP and ERO (intended path) 214 MUST be set in the PCUpd message. If the mandatory object is 215 received with the P flag set incorrectly according to the rules 216 stated above, the receiving peer MUST send a PCErr message with 217 Error-Type=10 (Reception of an invalid object) and Error-value=1 218 (reception of an object with P flag not set). By default, the PCE 219 SHOULD set the P flag, unless a local configuration or local policy 220 indicates that some constraints (corresponding PCEP objects) can be 221 marked as optional and could be ignored by the PCC. 223 3.3. Handling of I flag 225 3.3.1. The PCUpd message 227 The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to 228 a PCC whether or not an optional object was processed. The PCE MAY 229 include the ignored optional object in its update request and set the 230 I flag to indicate that the optional object was ignored. When the I 231 flag is cleared, the PCE indicates that the optional object was 232 processed. 234 3.3.2. The PCRpt message 236 The I flag in the PCRpt message [RFC8231] allows a PCC to indicate to 237 a PCE whether or not an optional object was processed in response to 238 an LSP Update Request or LSP Initiate Request. The PCC MAY include 239 the ignored optional object in its report and set the I flag to 240 indicate that the optional object was ignored at PCC. When the I 241 flag is cleared, the PCC indicates that the optional object was 242 processed. The I flag has no meaning if the PCRpt message is not in 243 response to a PCUpd or PCInitiate message (i.e. without the SRP 244 object in PCRpt message). 246 3.3.3. The PCInitiate message 248 The I flag has no meaning in the PCinitiate message [RFC8281]. 250 3.4. Delegation 252 Delegation is an operation to grant a PCE temporary rights to modify 253 a subset of LSP parameters on one or more LSPs of a PCC as described 254 in [RFC8051]. Note that for the delegated LSPs, the PCE can update 255 and mark some object as ignored even when the PCC had set the P flag 256 during delegation. Similarly, the PCE can update and mark some 257 object as a must to process even when the PCC had not set the P flag 258 during delegation. 260 The PCC MUST confirm this by sending the PCRpt message with the P 261 flag set as per the PCE expectation for the corresponding object. In 262 case PCC cannot except this, it would reach as per the processing 263 rules in [RFC8231]. 265 3.5. Unknown Object Handling 267 This document updates the handling of unknown objects in stateful 268 PCEP messages as per the setting of P flag in the common object 269 header in a similar way as [RFC5440], i.e. if a PCEP speaker does not 270 understand an object with the P flag set or understands the object 271 but decides to ignore the object, the entire stateful PCEP message 272 MUST be rejected and the PCE MUST send a PCErr message with Error- 273 Type="Unknown Object" or "Not supported Object" [RFC5440]. In case 274 the P flag is not set, the PCEP speaker is free to ignore the object 275 and continue with the message processing as defined. 277 [RFC8231] defined LSP Error Code TLV to be carried in PCRpt message 278 in the LSP object to convey error information. This document does 279 not change that procedure. 281 4. Security Considerations 283 This documents clarifies how the already existing P and I flag in 284 PCEP common object header could be used during stateful PCEP 285 exchanges. It updates the unknown object error handling in stateful 286 PCEP message exchange. These changes on its own do not add any new 287 security concerns. The security considerations identified in 288 [RFC5440], [RFC8231], and [RFC8281]. 290 As stated in [RFC6952], PCEP implementations SHOULD support the TCP- 291 AO [RFC5925] and not use TCP MD5 because of TCP MD5's known 292 vulnerabilities and weakness. PCEP also support Transport Layer 293 Security (TLS) [RFC8253] as per the recommendations and best current 294 practices in [RFC7525]. 296 5. IANA Considerations 298 5.1. STATEFUL-PCE-CAPABILITY TLV 300 [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA 301 created a registry to manage the value of the STATEFUL-PCE-CAPABILITY 302 TLV's Flag field. IANA has allocated a new bit in the STATEFUL-PCE- 303 CAPABILITY TLV Flag Field registry, as follows: 305 Bit Description Reference 306 ------------------------------------------------- 307 TBD1 RELAX bit [This I.D.] 309 6. Manageability Considerations 311 6.1. Control of Function and Policy 313 An operator MUST be allowed to configure the capability to support 314 relaxation of constraints in the stateful PCEP message exchange. 315 They SHOULD also allow configuration of related LSP constraints (or 316 parameters) that are optional to process. 318 6.2. Information and Data Models 320 An implementation SHOULD allow the operator to view the capability 321 defined in this document. To serve this purpose, the PCEP YANG 322 module [I-D.ietf-pce-pcep-yang] could be extended. 324 6.3. Liveness Detection and Monitoring 326 Mechanisms defined in this document do not imply any new liveness 327 detection and monitoring requirements in addition to those already 328 listed in [RFC5440]. 330 6.4. Verify Correct Operations 332 Mechanisms defined in this document do not imply any new operation 333 verification requirements in addition to those already listed in 334 [RFC5440]. 336 6.5. Requirements On Other Protocols 338 Mechanisms defined in this document do not imply any new requirements 339 on other protocols. 341 6.6. Impact On Network Operations 343 Mechanisms defined in this document do not have any impact on network 344 operations in addition to those already listed in [RFC5440]. 346 7. Acknowledgments 348 Thanks to Jonathan Hardwick for discussion and suggestions around 349 this draft. 351 8. References 353 8.1. Normative References 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, 357 DOI 10.17487/RFC2119, March 1997, 358 . 360 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 361 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 362 DOI 10.17487/RFC5440, March 2009, 363 . 365 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 366 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 367 May 2017, . 369 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 370 Computation Element Communication Protocol (PCEP) 371 Extensions for Stateful PCE", RFC 8231, 372 DOI 10.17487/RFC8231, September 2017, 373 . 375 8.2. Informative References 377 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 378 Element (PCE)-Based Architecture", RFC 4655, 379 DOI 10.17487/RFC4655, August 2006, 380 . 382 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 383 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 384 June 2010, . 386 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 387 BGP, LDP, PCEP, and MSDP Issues According to the Keying 388 and Authentication for Routing Protocols (KARP) Design 389 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 390 . 392 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 393 "Recommendations for Secure Use of Transport Layer 394 Security (TLS) and Datagram Transport Layer Security 395 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 396 2015, . 398 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 399 Stateful Path Computation Element (PCE)", RFC 8051, 400 DOI 10.17487/RFC8051, January 2017, 401 . 403 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 404 "Extensions to the Path Computation Element Communication 405 Protocol (PCEP) to Compute Service-Aware Label Switched 406 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 407 2017, . 409 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 410 "PCEPS: Usage of TLS to Provide a Secure Transport for the 411 Path Computation Element Communication Protocol (PCEP)", 412 RFC 8253, DOI 10.17487/RFC8253, October 2017, 413 . 415 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 416 Computation Element Communication Protocol (PCEP) 417 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 418 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 419 . 421 [I-D.ietf-pce-pcep-yang] 422 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 423 YANG Data Model for Path Computation Element 424 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 425 yang-07 (work in progress), March 2018. 427 [I-D.ietf-pce-association-group] 428 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 429 Dhody, D., and Y. Tanaka, "PCEP Extensions for 430 Establishing Relationships Between Sets of LSPs", draft- 431 ietf-pce-association-group-06 (work in progress), June 432 2018. 434 [I-D.ietf-pce-association-diversity] 435 Litkowski, S., Sivabalan, S., Barth, C., and D. Dhody, 436 "Path Computation Element communication Protocol extension 437 for signaling LSP diversity constraint", draft-ietf-pce- 438 association-diversity-04 (work in progress), June 2018. 440 Authors' Addresses 442 Dhruv Dhody (editor) 443 Huawei Technologies 444 Divyashree Techno Park, Whitefield 445 Bangalore, Karnataka 560066 446 India 448 EMail: dhruv.ietf@gmail.com 450 Stephane Litkowski 451 Orange 453 EMail: stephane.litkowski@orange.com