idnits 2.17.1 draft-dhody-pce-stateful-pce-optional-00.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 (March 1, 2018) is 2248 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-06 == Outdated reference: A later version (-15) exists of draft-ietf-pce-association-diversity-03 == Outdated reference: A later version (-10) exists of draft-ietf-pce-association-group-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: September 2, 2018 March 1, 2018 8 Extension for Stateful PCE to allow Optional Processing of PCEP Objects. 9 draft-dhody-pce-stateful-pce-optional-00 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 September 2, 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. Unknown Object Handling . . . . . . . . . . . . . . . . . 6 66 4. Security Considerations . . . . . . . . . . . . . . . . . . . 6 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 5.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 6 69 6. Manageability Considerations . . . . . . . . . . . . . . . . 7 70 6.1. Control of Function and Policy . . . . . . . . . . . . . 7 71 6.2. Information and Data Models . . . . . . . . . . . . . . . 7 72 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 7 73 6.4. Verify Correct Operations . . . . . . . . . . . . . . . . 7 74 6.5. Requirements On Other Protocols . . . . . . . . . . . . . 7 75 6.6. Impact On Network Operations . . . . . . . . . . . . . . 7 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 7.1. Normative References . . . . . . . . . . . . . . . . . . 7 78 7.2. Informative References . . . . . . . . . . . . . . . . . 8 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 81 1. Introduction 83 [RFC5440] describes the Path Computation Element communication 84 Protocol (PCEP) which enables the communication between a Path 85 Computation Client (PCC) and a Path Control Element (PCE), or between 86 two PCEs based on the PCE architecture [RFC4655]. 88 PCEP Extensions for Stateful PCE Model [RFC8231] describes a set of 89 extensions to PCEP to enable active control of Multiprotocol Label 90 Switching Traffic Engineering (MPLS-TE) and Generalzied MPLS (GMPLS) 91 tunnels. [RFC8281] describes the setup and teardown of PCE-initiated 92 LSPs under the active stateful PCE model, without the need for local 93 configuration on the PCC, thus allowing for a dynamic network. 95 [RFC5440] defined P flag (Processing-Rule) as part of Common Object 96 Header to allow a PCC to specify in a PCReq message sent to a PCE 97 whether the object must be taken into account by the PCE during path 98 computation or is just optional. The I flag (Ignore) is used by a 99 PCE in a PCRep message to indicate to a PCC whether or not an 100 optional object was processed. Stateful PCE [RFC8231] specified that 101 P and I flags of the PCEP objects defined in [RFC8231] is to be set 102 to 0 on transmission and ignored on receipt since they are 103 exclusively related to path computation requests. The behavior for P 104 and I flag in other objects defined in [RFC5440] and other extension 105 was not specified. This document clarifies how the P and I flag 106 could be used in the stateful PCE model to identify optional objects 107 in the Path Computation State Report (PCRpt), the Path Computation 108 Update Request (PCUpd) and the LSP Initiate Request (PCInitiate) 109 message. 111 This document updates [RFC8231] with respect to usage of P and I flag 112 as well as handling of unknown objects in stateful PCEP message 113 exchanges. 115 1.1. Requirements Language 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 2. Overview 125 [RFC5440] describes the handling on unknown objects as per the 126 setting of the P flag for the PCReq message. Further [RFC8231] 127 defined the usage of LSP Error Code TLV in PCRpt message in response 128 to failed LSP Update Request via PCUpd message (for example, due to 129 an unsupported object or a TLV). 131 This document clarifies the procedure for marking some objects as 132 optional to be processed by the PCEP peer in the stateful PCEP 133 messages. Further this document updates the procedure for handling 134 unknown objects in the stateful PCEP messages based on the P flag. 136 2.1. Usage Example 138 The PCRpt message is used to report the current state of an LSP. As 139 part of the message both the and is encoded. The could 141 include the METRIC object to indicate a limiting constraint (B flag 142 set) for the Path Delay Variation metric [RFC8233]. In some 143 scenarios it would be useful to state that this limiting constraint 144 can be relaxed by the PCE, in case it cannot find a path. Similarly 145 in case of an association groups [I-D.ietf-pce-association-group] 146 such as Disjoint Association [I-D.ietf-pce-association-diversity], 147 the PCE may need to completely relax the disjointness constraint in 148 order to provide a path to all the LSPs that are part of the 149 association. In these case it would be useful mark the objects as 150 optional and could be ignored by the PCEP peer. Also it would be 151 used for the PCEP speaker to learn if the PCEP peer has relaxed the 152 constraint and ignored the processing of the PCEP object. 154 Thus, this document simply clarifies how the already existing P and I 155 flag in PCEP common object header could be used during stateful PCEP 156 exchanges. 158 3. PCEP Extension 160 3.1. STATEFUL-PCE-CAPABILITY TLV 162 A PCEP speaker indicates its ability to support for handling P and I 163 flag during the stateful PCEP message exchanges during the PCEP 164 initialization phase, as follows. When the PCEP session is created, 165 it sends an Open message with an OPEN object that contains the 166 STATEFUL-PCE-CAPABILITY TLV, as defined in [RFC8231]. A new flag, 167 the R (RELAX) flag, is introduced to this TLV to indicate support for 168 relaxing the processing of some objects via the use of P and I flag 169 in PCEP common object header. 171 R (RELAX bit - TBD1): If set to 1 by a PCEP Speaker, the R flag 172 indicates that the PCEP Speaker is willing to send and receive PCEP 173 objects with handling of P and I flags in the PCEP common object 174 header. In case the bit is unset, it indicates that the PCEP Speaker 175 would not handle P and I flags in the PCEP common object header. 177 The R flag must be set by both a PCC and a PCE for handling of P and 178 I flag in the PCEP common object header to allow relaxing some 179 constraints by marking objects as optional to process. If the PCEP 180 speaker that did not set R flag but receives PCEP objects with P or I 181 bit set, would behave as per the processing rule in [RFC8231]. 183 3.2. Handling of P flag 185 3.2.1. The PCRpt message 187 The P flag in the PCRpt message [RFC8231] allows a PCC to specify to 188 a PCE whether the object must be taken into account by the PCE 189 (during path computation or re-optimization) or is just optional. 190 When the P flag is set, the object MUST be taken into account by the 191 PCE. Conversely, when the P flag is cleared, the object is optional 192 and the PCE is free to ignore it. The P flag for the mandatory 193 objects LSP and ERO (intended path) MUST be set in the PCRpt message. 195 If the mandatory object is received with the P flag set incorrectly 196 according to the rules stated above, the receiving peer MUST send a 197 PCErr message with Error-Type=10 (Reception of an invalid object) and 198 Error-value=1 (reception of an object with P flag not set). By 199 default, the PCC SHOULD set the P flag, unless a local configuration 200 or local policy indicates that some constraints (corresponding PCEP 201 objects) can be marked as optional and could be ignored by the PCE. 203 3.2.2. The PCUpd message and the PCInitiate message 205 The P flag in the PCUpd message [RFC8231] and the PCInitiate message 206 [RFC8281] allows a PCE to specify to a PCC whether the object must be 207 taken into account by the PCC (during path setup) or is just 208 optional. When the P flag is set, the object MUST be taken into 209 account by the PCC. Conversely, when the P flag is cleared, the 210 object is optional and the PCC is free to ignore it. The P flag for 211 the mandatory objects SRP, LSP and ERO (intended path) MUST be set in 212 the PCUpd message. If the mandatory object is received with the P 213 flag set incorrectly according to the rules stated above, the 214 receiving peer MUST send a PCErr message with Error-Type=10 215 (Reception of an invalid object) and Error-value=1 (reception of an 216 object with P flag not set). By default, the PCE SHOULD set the P 217 flag, unless a local configuration or local policy indicates that 218 some constraints (corresponding PCEP objects) can be marked as 219 optional and could be ignored by the PCC. 221 3.3. Handling of I flag 223 3.3.1. The PCUpd message 225 The I flag in the PCUpd message [RFC8231] allows a PCE to indicate to 226 a PCC whether or not an optional object was processed. The PCE MAY 227 include the ignored optional object in its update request and set the 228 I flag to indicate that the optional object was ignored. When the I 229 flag is cleared, the PCE indicates that the optional object was 230 processed. Note that for the delegated LSPs, the PCE can update and 231 mark some object as ignored even when the PCC had set the P flag 232 during delegation. 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. The PCC MAY include the ignored optional 239 object in its report and set the I flag to indicate that the optional 240 object was ignored at PCC. When the I flag is cleared, the PCC 241 indicates that the optional object was processed. The I flag has no 242 meaning if the PCRpt message is not in response to a PCUpd or 243 PCInitiate message. 245 3.3.3. The PCInitiate message 247 The I flag has no meaning in the PCinitiate message [RFC8281]. 249 3.4. Unknown Object Handling 251 This document updates the handling of unknown objects in stateful 252 PCEP messages as per the setting of P flag in the common object 253 header in a similar way as [RFC5440], i.e. if a PCEP speaker does not 254 understand an object with the P flag set or understands the object 255 but decides to ignore the object, the entire stateful PCEP message 256 MUST be rejected and the PCE MUST send a PCErr message with Error- 257 Type="Unknown Object" or "Not supported Object" [RFC5440]. In case 258 the P flag is not set, the PCEP speaker is free to ignore the object 259 and continue with the message processing as defined. 261 [RFC8231] defined LSP Error Code TLV to be carried in PCRpt message 262 in the LSP object to convey error information. This document does 263 not change that impact that procedure. 265 4. Security Considerations 267 This documents clarifies how the already existing P and I flag in 268 PCEP common object header could be used during stateful PCEP 269 exchanges. It updates the unknown object error handling in stateful 270 PCEP message exchange. These changes on its own do not add any new 271 security concerns. The security considerations identified in 272 [RFC5440], [RFC8231], and [RFC8281]. 274 As stated in [RFC6952], PCEP implementations SHOULD support the TCP- 275 AO [RFC5925] and not use TCP MD5 because of TCP MD5's known 276 vulnerabilities and weakness. PCEP also support Transport Layer 277 Security (TLS) [RFC8253] as per the recommendations and best current 278 practices in [RFC7525]. 280 5. IANA Considerations 282 5.1. STATEFUL-PCE-CAPABILITY TLV 284 [RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV; per that RFC, IANA 285 created a registry to manage the value of the STATEFUL-PCE-CAPABILITY 286 TLV's Flag field. IANA has allocated a new bit in the STATEFUL-PCE- 287 CAPABILITY TLV Flag Field registry, as follows: 289 Bit Description Reference 290 ------------------------------------------------- 291 TBD1 RELAX bit [This I.D.] 293 6. Manageability Considerations 295 6.1. Control of Function and Policy 297 An operator MUST be allowed to configure the capability to support 298 relaxation of constraints in the stateful PCEP message exchange. 299 They SHOULD also allow configuration of related LSP constraints (or 300 parameters) that are optional to process. 302 6.2. Information and Data Models 304 An implementation SHOULD allow the operator to view the capability 305 defined in this document. To serve this purpose, the PCEP YANG 306 module [I-D.ietf-pce-pcep-yang] could be extended. 308 6.3. Liveness Detection and Monitoring 310 Mechanisms defined in this document do not imply any new liveness 311 detection and monitoring requirements in addition to those already 312 listed in [RFC5440]. 314 6.4. Verify Correct Operations 316 Mechanisms defined in this document do not imply any new operation 317 verification requirements in addition to those already listed in 318 [RFC5440]. 320 6.5. Requirements On Other Protocols 322 Mechanisms defined in this document do not imply any new requirements 323 on other protocols. 325 6.6. Impact On Network Operations 327 Mechanisms defined in this document do not have any impact on network 328 operations in addition to those already listed in [RFC5440]. 330 7. References 332 7.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 340 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 341 DOI 10.17487/RFC5440, March 2009, 342 . 344 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 345 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 346 May 2017, . 348 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 349 Computation Element Communication Protocol (PCEP) 350 Extensions for Stateful PCE", RFC 8231, 351 DOI 10.17487/RFC8231, September 2017, 352 . 354 7.2. Informative References 356 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 357 Element (PCE)-Based Architecture", RFC 4655, 358 DOI 10.17487/RFC4655, August 2006, 359 . 361 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 362 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 363 June 2010, . 365 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 366 BGP, LDP, PCEP, and MSDP Issues According to the Keying 367 and Authentication for Routing Protocols (KARP) Design 368 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 369 . 371 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 372 "Recommendations for Secure Use of Transport Layer 373 Security (TLS) and Datagram Transport Layer Security 374 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 375 2015, . 377 [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, 378 "Extensions to the Path Computation Element Communication 379 Protocol (PCEP) to Compute Service-Aware Label Switched 380 Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 381 2017, . 383 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 384 "PCEPS: Usage of TLS to Provide a Secure Transport for the 385 Path Computation Element Communication Protocol (PCEP)", 386 RFC 8253, DOI 10.17487/RFC8253, October 2017, 387 . 389 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 390 Computation Element Communication Protocol (PCEP) 391 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 392 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 393 . 395 [I-D.ietf-pce-pcep-yang] 396 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 397 YANG Data Model for Path Computation Element 398 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 399 yang-06 (work in progress), January 2018. 401 [I-D.ietf-pce-association-diversity] 402 Litkowski, S., Sivabalan, S., Barth, C., and D. Dhody, 403 "Path Computation Element communication Protocol extension 404 for signaling LSP diversity constraint", draft-ietf-pce- 405 association-diversity-03 (work in progress), February 406 2018. 408 [I-D.ietf-pce-association-group] 409 Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H., 410 Dhody, D., and Y. Tanaka, "PCEP Extensions for 411 Establishing Relationships Between Sets of LSPs", draft- 412 ietf-pce-association-group-04 (work in progress), August 413 2017. 415 Authors' Addresses 417 Dhruv Dhody (editor) 418 Huawei Technologies 419 Divyashree Techno Park, Whitefield 420 Bangalore, Karnataka 560066 421 India 423 EMail: dhruv.ietf@gmail.com 425 Stephane Litkowski 426 Orange 428 EMail: stephane.litkowski@orange.com