idnits 2.17.1 draft-dhody-pce-stateful-pce-vendor-14.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 (19 April 2022) is 737 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-18 -- 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 Intended status: Standards Track Huawei Technologies 5 Expires: 21 October 2022 S. Sivabalan 6 Ciena 7 S. Sidor 8 Z. Ali 9 Cisco Systems, Inc. 10 19 April 2022 12 Conveying Vendor-Specific Information in the Path Computation Element 13 (PCE) Communication Protocol (PCEP) extensions for Stateful PCE. 14 draft-dhody-pce-stateful-pce-vendor-14 16 Abstract 18 A Stateful Path Computation Element (PCE) maintains information on 19 the current network state, including: computed Label Switched Path 20 (LSPs), reserved resources within the network, and the pending path 21 computation requests. This information may then be considered when 22 computing new traffic engineered LSPs, and for the associated and the 23 dependent LSPs, received from a Path Computation Client (PCC). 25 RFC 7470 defines a facility to carry vendor-specific information in 26 Path Computation Element Communication Protocol (PCEP). 28 This document extends this capability for the Stateful PCEP messages. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on 21 October 2022. 47 Copyright Notice 49 Copyright (c) 2022 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Revised BSD License text as 58 described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Revised BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2. Procedures for the Vendor Information Object . . . . . . . . 3 66 3. Procedures for the Vendor Information TLV . . . . . . . . . . 6 67 4. Vendor Information Object and TLV . . . . . . . . . . . . . . 6 68 5. Manageability Considerations . . . . . . . . . . . . . . . . 7 69 5.1. Control of Function and Policy . . . . . . . . . . . . . 7 70 5.2. Information and Data Models . . . . . . . . . . . . . . . 7 71 5.3. Liveness Detection and Monitoring . . . . . . . . . . . . 7 72 5.4. Verify Correct Operations . . . . . . . . . . . . . . . . 7 73 5.5. Requirements On Other Protocols . . . . . . . . . . . . . 7 74 5.6. Impact On Network Operations . . . . . . . . . . . . . . 7 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 76 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 77 7.1. Cisco Systems . . . . . . . . . . . . . . . . . . . . . . 8 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 79 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 82 10.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 86 1. Introduction 88 The Path Computation Element Communication Protocol (PCEP) [RFC5440] 89 provides mechanisms for a Path Computation Element (PCE) to perform 90 path computation in response to a Path Computation Client (PCC) 91 request. 93 A Stateful PCE is capable of considering, for the purposes of the 94 path computation, not only the network state in terms of links and 95 nodes (referred to as the Traffic Engineering Database or TED) but 96 also the status of active services (previously computed paths, and 97 currently reserved resources, stored in the Label Switched Paths 98 Database (LSP-DB). [RFC8051] describes general considerations for a 99 Stateful PCE deployment and examines its applicability and benefits, 100 as well as its challenges and limitations through a number of use 101 cases. 103 [RFC8231] describes a set of extensions to PCEP to provide stateful 104 control. A Stateful PCE has access to not only the information 105 carried by the network's Interior Gateway Protocol (IGP), but also 106 the set of active paths and their reserved resources for its 107 computations. The additional state allows the PCE to compute 108 constrained paths while considering individual LSPs and their 109 interactions. [RFC8281] describes the set up, maintenance and 110 teardown of PCE-initiated LSPs under the Stateful PCE model. These 111 extensions added new messages in PCEP for Stateful PCE. 113 [RFC7470] defined Vendor Information object that can be used to carry 114 arbitrary, proprietary information such as vendor-specific 115 constraints. It also defined VENDOR-INFORMATION-TLV that can be used 116 to carry arbitrary information within any existing or future PCEP 117 object that supports TLVs. 119 This document extend the usage of Vendor Information Object and 120 VENDOR-INFORMATION-TLV to Stateful PCE. The VENDOR-INFORMATION-TLV 121 can be carried inside any of the new objects added in PCEP for 122 Stateful PCE as per [RFC7470], this document extend the stateful PCEP 123 messages to also include the Vendor Information Object as well. 125 1.1. Requirements Language 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in BCP 130 14 [RFC2119] [RFC8174] when, and only when, they appear in all 131 capitals, as shown here. 133 2. Procedures for the Vendor Information Object 135 A Path Computation LSP State Report message (also referred to as 136 PCRpt message) [RFC8231] is a PCEP message sent by a PCC to a PCE to 137 report the current state of an LSP. A PCC that wants to convey 138 proprietary or vendor-specific information or metrics to a PCE does 139 so by including a Vendor Information object in the PCRpt message. 140 The contents and format of the object are described in Section 4 of 142 [RFC7470]. The PCE determines how to interpret the information in 143 the Vendor Information object by examining the Enterprise Number it 144 contains. 146 The Vendor Information object is OPTIONAL in a PCRpt message. 147 Multiple instances of the object MAY be used on a single PCRpt 148 message. Different instances of the object can have different 149 Enterprise Numbers. 151 The format of the PCRpt message (with [RFC8231] as base) is updated 152 as follows: 154 ::= 155 156 Where: 158 ::= [] 160 ::= [] 161 162 163 [] 164 Where: 165 ::= 166 [] 168 is defined in [RFC8231]. 170 A Path Computation LSP Update Request message (also referred to as 171 PCUpd message) [RFC8231] is a PCEP message sent by a PCE to a PCC to 172 update attributes of an LSP. The Vendor Information object can be 173 included in a PCUpd message to convey proprietary or vendor-specific 174 information. 176 The format of the PCUpd message (with [RFC8231] as base) is updated 177 as follows: 179 ::= 180 181 Where: 183 ::= 184 [] 186 ::= 187 188 189 [] 190 Where: 191 ::= 192 [] 194 is defined in [RFC8231]. 196 A Path Computation LSP Initiate Message (also referred to as 197 PCInitiate message) [RFC8281] is a PCEP message sent by a PCE to a 198 PCC to trigger an LSP instantiation or deletion. The Vendor 199 Information object can be included in a PCInitiate message to convey 200 proprietary or vendor-specific information. 202 The format of the PCInitiate message (with [RFC8281] as base) is 203 updated as follows: 205 ::= 206 207 Where: 209 ::= 210 [] 212 ::= 213 (| 214 ) 216 ::= 217 218 [] 219 220 [] 221 [] 223 Where: 225 ::= 226 [] 228 and is as per 229 [RFC8281]. 231 A legacy implementation that does not recognize the Vendor 232 Information object will act according to the procedures set out in 233 [RFC8231] and [RFC8281]. An implementation that supports the Vendor 234 Information object, but receives one carrying an Enterprise Number 235 that it does not support, MUST ignore the object in the same way as 236 described in [RFC7470]. 238 3. Procedures for the Vendor Information TLV 240 The Vendor Information TLV can be used to carry vendor-specific 241 information that applies to a specific PCEP object by including the 242 TLV in the object. This includes objects used in Stateful PCE 243 extension such as SRP and LSP object. All the procedures as per 244 section 3 of [RFC7470]. 246 4. Vendor Information Object and TLV 248 [RFC7470] specify the format of VENDOR-INFORMATION Object and VENDOR- 249 INFORMATION-TLV. 251 5. Manageability Considerations 253 All manageability requirements and considerations listed in 254 [RFC5440], [RFC7470], [RFC8231], and [RFC8281] apply to PCEP protocol 255 extensions defined in this document. In addition, requirements and 256 considerations listed in this section apply. 258 5.1. Control of Function and Policy 260 As stated in [RFC7470], this capability, the associated vendor 261 specific information and policy SHOULD made configurable. This 262 information can be used in Stateful PCEP messages as well. 264 5.2. Information and Data Models 266 The PCEP YANG module is specified in [I-D.ietf-pce-pcep-yang]. It is 267 RECOMMENDED that standard YANG module not be augmented with details 268 of vendor information. It MAY be extended to include the use of this 269 information and the Enterprise Numbers that the object and TLVs 270 contain. 272 5.3. Liveness Detection and Monitoring 274 Mechanisms defined in this document do not imply any new liveness 275 detection and monitoring requirements in addition to those already 276 listed in [RFC5440]. 278 5.4. Verify Correct Operations 280 Mechanisms defined in this document do not imply any new operation 281 verification requirements in addition to those already listed in 282 [RFC5440] and [RFC8231]. 284 5.5. Requirements On Other Protocols 286 Mechanisms defined in this document do not imply any new requirements 287 on other protocols. 289 5.6. Impact On Network Operations 291 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 292 extensions defined in this document. Further, the mechanism 293 described in this document can help the operator to request control 294 of the LSPs at a particular PCE. 296 6. IANA Considerations 298 There are no IANA consideration in this document. 300 7. Implementation Status 302 [NOTE TO RFC EDITOR : This whole section and the reference to RFC 303 7942 is to be removed before publication as an RFC] 305 This section records the status of known implementations of the 306 protocol defined by this specification at the time of posting of this 307 Internet-Draft, and is based on a proposal described in [RFC7942]. 308 The description of implementations in this section is intended to 309 assist the IETF in its decision processes in progressing drafts to 310 RFCs. Please note that the listing of any individual implementation 311 here does not imply endorsement by the IETF. Furthermore, no effort 312 has been spent to verify the information presented here that was 313 supplied by IETF contributors. This is not intended as, and must not 314 be construed to be, a catalog of available implementations or their 315 features. Readers are advised to note that other implementations may 316 exist. 318 According to [RFC7942], "this will allow reviewers and working groups 319 to assign due consideration to documents that have the benefit of 320 running code, which may serve as evidence of valuable experimentation 321 and feedback that have made the implemented protocols more mature. 322 It is up to the individual working groups to use this information as 323 they see fit". 325 7.1. Cisco Systems 327 * Organization: Cisco Systems, Inc. 329 * Implementation: Cisco IOS-XR PCE and PCC 331 * Description: Vendor Information Object used in PCRpt, PCUpd and 332 PCInitiate messages. 334 * Maturity Level: Production 336 * Coverage: Full 338 * Contact: ssidor@cisco.com 340 8. Security Considerations 342 The protocol extensions defined in this document do not change the 343 nature of PCEP. Therefore, the security considerations set out in 344 [RFC5440], [RFC7470], [RFC8231] and [RFC8281] apply unchanged. 346 As stated in [RFC6952], PCEP implementations SHOULD support the TCP- 347 AO [RFC5925] and not use TCP MD5 because of TCP MD5's known 348 vulnerabilities and weakness. PCEP also support Transport Layer 349 Security (TLS) [RFC8253] as per the recommendations and best current 350 practices in [RFC7525]. 352 9. Acknowledgments 354 Thanks to Avantika, Mahendra Singh Negi, Udayasree Palle and Swapna K 355 for their suggestions. 357 10. References 359 10.1. Normative References 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, 363 DOI 10.17487/RFC2119, March 1997, 364 . 366 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 367 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 368 DOI 10.17487/RFC5440, March 2009, 369 . 371 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 372 Constraints in the Path Computation Element Communication 373 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 374 . 376 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 377 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 378 May 2017, . 380 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 381 Computation Element Communication Protocol (PCEP) 382 Extensions for Stateful PCE", RFC 8231, 383 DOI 10.17487/RFC8231, September 2017, 384 . 386 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 387 Computation Element Communication Protocol (PCEP) 388 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 389 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 390 . 392 10.2. Informative References 394 [I-D.ietf-pce-pcep-yang] 395 Dhody, D., Hardwick, J., Beeram, V. P., and J. Tantsura, 396 "A YANG Data Model for Path Computation Element 397 Communications Protocol (PCEP)", Work in Progress, 398 Internet-Draft, draft-ietf-pce-pcep-yang-18, 25 January 399 2022, . 402 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 403 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 404 June 2010, . 406 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 407 BGP, LDP, PCEP, and MSDP Issues According to the Keying 408 and Authentication for Routing Protocols (KARP) Design 409 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 410 . 412 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 413 "Recommendations for Secure Use of Transport Layer 414 Security (TLS) and Datagram Transport Layer Security 415 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 416 2015, . 418 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 419 Code: The Implementation Status Section", BCP 205, 420 RFC 7942, DOI 10.17487/RFC7942, July 2016, 421 . 423 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 424 Stateful Path Computation Element (PCE)", RFC 8051, 425 DOI 10.17487/RFC8051, January 2017, 426 . 428 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 429 "PCEPS: Usage of TLS to Provide a Secure Transport for the 430 Path Computation Element Communication Protocol (PCEP)", 431 RFC 8253, DOI 10.17487/RFC8253, October 2017, 432 . 434 Appendix A. Contributor Addresses 436 Dhruv Dhody 437 Huawei Technologies 438 Divyashree Techno Park, Whitefield 439 Bangalore, Karnataka 560066 440 India 442 EMail: dhruv.ietf@gmail.com 444 Mike Koldychev 445 Cisco Systems 446 Kanata, Ontario 447 Canada 449 EMail: mkoldych@cisco.com 451 Authors' Addresses 453 Cheng Li 454 Huawei Technologies 455 Huawei Campus, No. 156 Beiqing Rd. 456 Beijing 457 100095 458 China 459 Email: c.l@huawei.com 461 Haomian Zheng 462 Huawei Technologies 463 H1, Huawei Xiliu Beipo Village, Songshan Lake 464 Dongguan 465 Guangdong, 523808 466 China 467 Email: zhenghaomian@huawei.com 469 Siva Sivabalan 470 Ciena 471 385 Terry Fox Drive 472 Kanata Ontario K2K 0L1 473 Canada 474 Email: msiva282@gmail.com 476 Samuel Sidor 477 Cisco Systems, Inc. 478 Email: ssidor@cisco.com 479 Zafar Ali 480 Cisco Systems, Inc. 481 Email: zali@cisco.com