idnits 2.17.1 draft-dhody-pce-stateful-pce-optional-02.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 (October 22, 2018) is 2013 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-09 == 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: April 25, 2019 October 22, 2018 8 Extension for Stateful PCE to allow Optional Processing of PCEP Objects. 9 draft-dhody-pce-stateful-pce-optional-02 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 April 25, 2019. 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) [RFC8231], the Path 110 Computation Update Request (PCUpd) [RFC8231], and the LSP Initiate 111 Request (PCInitiate) [RFC8281] message. 113 This document updates [RFC8231] with respect to usage of P and I flag 114 as well as the handling of unknown objects in the stateful PCEP 115 message exchange. 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/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 (see [RFC8231]). For example, the 143 could include the METRIC object to indicate 144 a limiting constraint (B flag set) for the Path Delay Variation 145 metric [RFC8233]. In some scenarios it would be useful to state that 146 this limiting constraint can be relaxed by the PCE in case it cannot 147 find a path. Similarly in case of an association groups 148 [I-D.ietf-pce-association-group] such as Disjoint Association 149 [I-D.ietf-pce-association-diversity], the PCE may need to completely 150 relax the disjointness constraint in order to provide a path to all 151 the LSPs that are part of the association. In these case it would be 152 useful to mark the objects as 'optional' and it could be ignored by 153 the PCEP peer. Also it would be used for the PCEP speaker to learn 154 if the PCEP peer has relaxed the constraint and ignored the 155 processing of the PCEP object. 157 Thus, this document simply clarifies, how the already existing P and 158 I flag in the PCEP common object header could be used during the 159 stateful PCEP message exchanges. 161 3. PCEP Extension 163 3.1. STATEFUL-PCE-CAPABILITY TLV 165 A PCEP speaker indicates its ability to support for handling P and I 166 flag during the stateful PCEP message exchanges during the PCEP 167 initialization phase, as follows. When the PCEP session is created, 168 it sends an Open message with an OPEN object that contains the 169 STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new flag, 170 the R (RELAX) flag, is introduced to this TLV to indicate support for 171 relaxing the processing of some objects via the use of P and I flag 172 in the PCEP common object header. 174 R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag 175 indicates that the PCEP Speaker is willing to send and receive PCEP 176 objects with handling of P and I flags in the PCEP common object 177 header. In case the bit is unset, it indicates that the PCEP Speaker 178 would not handle P and I flags in the PCEP common object header. 180 The R flag must be set by both a PCC and a PCE for handling of P and 181 I flag in the PCEP common object header to allow relaxing some 182 constraints by marking objects as optional to process. If the PCEP 183 speaker that did not set R flag but receives PCEP objects with P or I 184 bit set, would behave as per the processing rule in [RFC8231]. 186 3.2. Handling of P flag 188 3.2.1. The PCRpt message 190 The P flag in the PCRpt message [RFC8231] allows a PCC to specify to 191 a PCE whether the object must be taken into account by the PCE 192 (during path computation or re-optimization) or is just optional. 194 When the P flag is set in PCRpt message, the object MUST be taken 195 into account by the PCE. Conversely, when the P flag is cleared, the 196 object is optional and the PCE is free to ignore it. The P flag for 197 the mandatory objects LSP and ERO (intended path) MUST be set in the 198 PCRpt message. If the mandatory object is received with the P flag 199 set incorrectly according to the rules stated above, the receiving 200 peer MUST send a PCErr message with Error-Type=10 (Reception of an 201 invalid object) and Error-value=1 (reception of an object with P flag 202 not set). By default, the PCC SHOULD set the P flag, unless a local 203 configuration or local policy indicates that some constraints 204 (corresponding PCEP objects) can be marked as optional and could be 205 ignored by the PCE. 207 3.2.2. The PCUpd message and the PCInitiate message 209 The P flag in the PCUpd message [RFC8231] and the PCInitiate message 210 [RFC8281] allows a PCE to specify to a PCC whether the object must be 211 taken into account by the PCC (during path setup) or is just 212 optional. When the P flag is set in PCUpd/PCInitiate, the object 213 MUST be taken into account by the PCC. Conversely, when the P flag 214 is cleared, the object is optional and the PCC is free to ignore it. 215 The P flag for the mandatory objects SRP, LSP and ERO (intended path) 216 MUST be set in the PCUpd message. If the mandatory object is 217 received with the P flag set incorrectly according to the rules 218 stated above, the receiving peer MUST send a PCErr message with 219 Error-Type=10 (Reception of an invalid object) and Error-value=1 220 (reception of an object with P flag not set). By default, the PCE 221 SHOULD set the P flag, unless a local configuration or local policy 222 indicates that some constraints (corresponding PCEP objects) can be 223 marked as optional and could be ignored by the PCC. 225 3.3. Handling of I flag 227 3.3.1. The PCUpd message 229 The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to 230 a PCC whether or not an optional object was processed. The PCE MAY 231 include the ignored optional object in its update request and set the 232 I flag to indicate that the optional object was ignored. When the I 233 flag is cleared, the PCE indicates that the optional object was 234 processed. 236 3.3.2. The PCRpt message 238 The I flag in the PCRpt message [RFC8231] allows a PCC to indicate to 239 a PCE whether or not an optional object was processed in response to 240 an LSP Update Request (PCUpd) or LSP Initiate Request (PCInitiate). 241 The PCC MAY include the ignored optional object in its report and set 242 the I flag to indicate that the optional object was ignored at PCC. 243 When the I flag is cleared, the PCC indicates that the optional 244 object was processed. The I flag has no meaning if the PCRpt message 245 is not in response to a PCUpd or PCInitiate message (i.e. without the 246 SRP object in the PCRpt message). 248 3.3.3. The PCInitiate message 250 The I flag has no meaning in the PCinitiate message [RFC8281] and is 251 ignored. 253 3.4. Delegation 255 Delegation is an operation to grant a PCE temporary rights to modify 256 a subset of LSP parameters on one or more LSPs of a PCC as described 257 in [RFC8051]. Note that for the delegated LSPs, the PCE can update 258 and mark some object as ignored even when the PCC had set the P flag 259 during delegation. Similarly, the PCE can update and mark some 260 object as a must to process even when the PCC had not set the P flag 261 during delegation. 263 The PCC MUST confirm this by sending the PCRpt message with the P 264 flag set as per the PCE expectation for the corresponding object. In 265 case PCC cannot except this, it would reach as per the processing 266 rules in [RFC8231]. 268 3.5. Unknown Object Handling 270 This document updates the handling of unknown objects in stateful 271 PCEP messages as per the setting of P flag in the common object 272 header in a similar way as [RFC5440], i.e. if a PCEP speaker does not 273 understand an object with the P flag set or understands the object 274 but decides to ignore the object, the entire stateful PCEP message 275 MUST be rejected and the PCE MUST send a PCErr message with Error- 276 Type="Unknown Object" or "Not supported Object" [RFC5440]. In case 277 the P flag is not set, the PCEP speaker is free to ignore the object 278 and continue with the message processing as defined. 280 [RFC8231] defined LSP Error Code TLV to be carried in PCRpt message 281 in the LSP object to convey error information. This document does 282 not change that procedure. 284 4. Security Considerations 286 This documents clarifies how the already existing P and I flag in 287 PCEP common object header could be used during stateful PCEP 288 exchanges. It updates the unknown object error handling in stateful 289 PCEP message exchange. These changes on its own do not add any new 290 security concerns. The security considerations identified in 291 [RFC5440], [RFC8231], and [RFC8281]. 293 As stated in [RFC6952], PCEP implementations SHOULD support the TCP- 294 AO [RFC5925] and not use TCP MD5 because of TCP MD5's known 295 vulnerabilities and weakness. PCEP also support Transport Layer 296 Security (TLS) [RFC8253] as per the recommendations and best current 297 practices in [RFC7525]. 299 5. IANA Considerations 301 5.1. STATEFUL-PCE-CAPABILITY TLV 303 [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA 304 created a registry to manage the value of the STATEFUL-PCE-CAPABILITY 305 TLV's Flag field. IANA has allocated a new bit in the STATEFUL-PCE- 306 CAPABILITY TLV Flag Field registry, as follows: 308 Bit Description Reference 309 ------------------------------------------------- 310 TBD1 RELAX bit [This I.D.] 312 6. Manageability Considerations 314 6.1. Control of Function and Policy 316 An operator MUST be allowed to configure the capability to support 317 relaxation of constraints in the stateful PCEP message exchange. 318 They SHOULD also allow configuration of related LSP constraints (or 319 parameters) that are optional to process. 321 6.2. Information and Data Models 323 An implementation SHOULD allow the operator to view the capability 324 defined in this document. To serve this purpose, the PCEP YANG 325 module [I-D.ietf-pce-pcep-yang] could be extended. 327 6.3. Liveness Detection and Monitoring 329 Mechanisms defined in this document do not imply any new liveness 330 detection and monitoring requirements in addition to those already 331 listed in [RFC5440]. 333 6.4. Verify Correct Operations 335 Mechanisms defined in this document do not imply any new operation 336 verification requirements in addition to those already listed in 337 [RFC5440]. 339 6.5. Requirements On Other Protocols 341 Mechanisms defined in this document do not imply any new requirements 342 on other protocols. 344 6.6. Impact On Network Operations 346 Mechanisms defined in this document do not have any impact on network 347 operations in addition to those already listed in [RFC5440]. 349 7. Acknowledgments 351 Thanks to Jonathan Hardwick for discussion and suggestions around 352 this draft. 354 8. References 356 8.1. Normative References 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, 360 DOI 10.17487/RFC2119, March 1997, 361 . 363 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 364 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 365 DOI 10.17487/RFC5440, March 2009, 366 . 368 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 369 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 370 May 2017, . 372 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 373 Computation Element Communication Protocol (PCEP) 374 Extensions for Stateful PCE", RFC 8231, 375 DOI 10.17487/RFC8231, September 2017, 376 . 378 8.2. Informative References 380 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 381 Element (PCE)-Based Architecture", RFC 4655, 382 DOI 10.17487/RFC4655, August 2006, 383 . 385 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 386 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 387 June 2010, . 389 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 390 BGP, LDP, PCEP, and MSDP Issues According to the Keying 391 and Authentication for Routing Protocols (KARP) Design 392 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 393 . 395 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 396 "Recommendations for Secure Use of Transport Layer 397 Security (TLS) and Datagram Transport Layer Security 398 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 399 2015, . 401 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 402 Stateful Path Computation Element (PCE)", RFC 8051, 403 DOI 10.17487/RFC8051, January 2017, 404 . 406 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 407 "Extensions to the Path Computation Element Communication 408 Protocol (PCEP) to Compute Service-Aware Label Switched 409 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 410 2017, . 412 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 413 "PCEPS: Usage of TLS to Provide a Secure Transport for the 414 Path Computation Element Communication Protocol (PCEP)", 415 RFC 8253, DOI 10.17487/RFC8253, October 2017, 416 . 418 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 419 Computation Element Communication Protocol (PCEP) 420 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 421 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 422 . 424 [I-D.ietf-pce-pcep-yang] 425 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 426 YANG Data Model for Path Computation Element 427 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 428 yang-09 (work in progress), October 2018. 430 [I-D.ietf-pce-association-group] 431 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 432 Dhody, D., and Y. Tanaka, "PCEP Extensions for 433 Establishing Relationships Between Sets of LSPs", draft- 434 ietf-pce-association-group-06 (work in progress), June 435 2018. 437 [I-D.ietf-pce-association-diversity] 438 Litkowski, S., Sivabalan, S., Barth, C., and D. Dhody, 439 "Path Computation Element communication Protocol extension 440 for signaling LSP diversity constraint", draft-ietf-pce- 441 association-diversity-04 (work in progress), June 2018. 443 Authors' Addresses 445 Dhruv Dhody (editor) 446 Huawei Technologies 447 Divyashree Techno Park, Whitefield 448 Bangalore, Karnataka 560066 449 India 451 EMail: dhruv.ietf@gmail.com 453 Stephane Litkowski 454 Orange 456 EMail: stephane.litkowski@orange.com