idnits 2.17.1 draft-dhody-pce-stateful-pce-vendor-07.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 (July 8, 2019) is 1753 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-12 -- 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: January 9, 2020 S. Sivabalan 6 Cisco Systems, Inc. 7 July 8, 2019 9 Conveying Vendor-Specific Information in the Path Computation Element 10 (PCE) Communication Protocol (PCEP) extensions for stateful PCE. 11 draft-dhody-pce-stateful-pce-vendor-07 13 Abstract 15 A Stateful Path Computation Element (PCE) maintains information on 16 the current network state, including: computed Label Switched Path 17 (LSPs), reserved resources within the network, and pending path 18 computation requests. This information may then be considered when 19 computing new traffic engineered LSPs, and for associated and 20 dependent LSPs, received from Path Computation Clients (PCCs). 22 RFC 7470 defines a facility to carry vendor-specific information in 23 PCEP. 25 This document extends this capability for the stateful PCE messages. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 9, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Procedures for the Vendor Information Object . . . . . . . . 3 64 3. Procedures for the Vendor Information TLV . . . . . . . . . . 5 65 4. Vendor Information Object and TLV . . . . . . . . . . . . . . 6 66 5. Manageability Considerations . . . . . . . . . . . . . . . . 6 67 5.1. Control of Function and Policy . . . . . . . . . . . . . 6 68 5.2. Information and Data Models . . . . . . . . . . . . . . . 6 69 5.3. Liveness Detection and Monitoring . . . . . . . . . . . . 6 70 5.4. Verify Correct Operations . . . . . . . . . . . . . . . . 6 71 5.5. Requirements On Other Protocols . . . . . . . . . . . . . 6 72 5.6. Impact On Network Operations . . . . . . . . . . . . . . 6 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 78 9.2. Informative References . . . . . . . . . . . . . . . . . 8 79 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 The Path Computation Element communication Protocol (PCEP) [RFC5440] 85 provides mechanisms for Path Computation Elements (PCEs) to perform 86 path computations in response to Path Computation Clients' (PCCs) 87 requests. 89 A stateful PCE is capable of considering, for the purposes of path 90 computation, not only the network state in terms of links and nodes 91 (referred to as the Traffic Engineering Database or TED) but also the 92 status of active services (previously computed paths, and currently 93 reserved resources, stored in the Label Switched Paths Database (LSP- 94 DB). [RFC8051] describes general considerations for a stateful PCE 95 deployment and examines its applicability and benefits, as well as 96 its challenges and limitations through a number of use cases. 98 [RFC8231] describes a set of extensions to PCEP to provide stateful 99 control. A stateful PCE has access to not only the information 100 carried by the network's Interior Gateway Protocol (IGP), but also 101 the set of active paths and their reserved resources for its 102 computations. The additional state allows the PCE to compute 103 constrained paths while considering individual LSPs and their 104 interactions. [RFC8281] describes the set-up, maintenance and 105 teardown of PCE-initiated LSPs under the stateful PCE model. These 106 extensions added new messages in PCEP for stateful PCE. 108 [RFC7470] defined Vendor Information object that can be used to carry 109 arbitrary, proprietary information such as vendor-specific 110 constraints. It also defined VENDOR-INFORMATION-TLV that can be used 111 to carry arbitrary information within any existing or future PCEP 112 object that supports TLVs. 114 This document extend the usage of Vendor Information Object and 115 VENDOR-INFORMATION-TLV to stateful PCE. The VENDOR-INFORMATION-TLV 116 can be carried inside any of the new objects added in PCEP for 117 stateful PCE as per [RFC7470], this document extend the PCEP messages 118 to also include the Vendor Information Object as well. 120 1.1. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here. 128 2. Procedures for the Vendor Information Object 130 A Path Computation LSP State Report message [RFC8231] (also referred 131 to as PCRpt message) is a PCEP message sent by a PCC to a PCE to 132 report the current state of an LSP. A PCC that wants to convey 133 proprietary or vendor-specific information or metrics to a PCE does 134 so by including a Vendor Information object in the PCRpt message. 135 The contents and format of the object are described in Section 4 of 136 [RFC7470]. The PCE determines how to interpret the information in 137 the Vendor Information object by examining the Enterprise Number it 138 contains. 140 The Vendor Information object is OPTIONAL in a PCRpt message. 141 Multiple instances of the object MAY be used on a single PCRpt 142 message. Different instances of the object can have different 143 Enterprise Numbers. 145 The format of the PCRpt message (with [RFC8231] as base) is updated 146 as follows: 148 ::= 149 150 Where: 152 ::= [] 154 ::= [] 155 156 157 [] 158 Where: 159 ::= 160 [] 162 is defined in [RFC8231]. 164 A Path Computation LSP Update Request message (also referred to as 165 PCUpd message) is a PCEP message sent by a PCE to a PCC to update 166 attributes of an LSP. The Vendor Information object can be included 167 in a PCUpd message to convey proprietary or vendor-specific 168 information. 170 The format of the PCUpd message (with [RFC8231] as base) is updated 171 as follows: 173 ::= 174 175 Where: 177 ::= 178 [] 180 ::= 181 182 183 [] 184 Where: 185 ::= 186 [] 188 is defined in [RFC8231]. 190 A Path Computation LSP Initiate Message (also referred to as 191 PCInitiate message) is a PCEP message sent by a PCE to a PCC to 192 trigger LSP instantiation or deletion. The Vendor Information object 193 can be included in a PCInitiate message to convey proprietary or 194 vendor-specific information. 196 The format of the PCInitiate message (with [RFC8281] as base) is 197 updated as follows: 199 ::= 200 201 Where: 203 ::= 204 [] 206 ::= 207 (| 208 ) 210 ::= 211 212 [] 213 214 [] 215 [] 217 Where: 219 ::= 220 [] 222 and is as per 223 [RFC8281]. 225 A legacy implementation that does not recognize the Vendor 226 Information object will act according to the procedures set out in 227 [RFC8231] and [RFC8281]. An implementation that supports the Vendor 228 Information object, but receives one carrying an Enterprise Number 229 that it does not support, SHOULD ignore the object in the same way as 230 described in [RFC7470]. 232 3. Procedures for the Vendor Information TLV 234 The Vendor Information TLV can be used to carry vendor-specific 235 information that applies to a specific PCEP object by including the 236 TLV in the object. This includes objects used in stateful PCE 237 extension such as SRP and LSP object. All the procedures as per 238 section 3 of [RFC7470]. 240 4. Vendor Information Object and TLV 242 [RFC7470] specify the format of VENDOR-INFORMATION Object and VENDOR- 243 INFORMATION-TLV. 245 5. Manageability Considerations 247 All manageability requirements and considerations listed in 248 [RFC5440], [RFC7470] and [RFC8231] apply to PCEP protocol extensions 249 defined in this document. In addition, requirements and 250 considerations listed in this section apply. 252 5.1. Control of Function and Policy 254 As stated in [RFC7470], this capability, the associated vendor 255 specific information and policy SHOULD made configurable. This 256 information can be used in stateful messages as well. 258 5.2. Information and Data Models 260 The PCEP YANG module is specified in [I-D.ietf-pce-pcep-yang]. It is 261 NOT RECOMMENDED that standard YANG module be augmented with details 262 of vendor information. It MAY be extended to include the use of this 263 information and the Enterprise Numbers that the object and TLVs 264 contain. 266 5.3. Liveness Detection and Monitoring 268 Mechanisms defined in this document do not imply any new liveness 269 detection and monitoring requirements in addition to those already 270 listed in [RFC5440]. 272 5.4. Verify Correct Operations 274 Mechanisms defined in this document do not imply any new operation 275 verification requirements in addition to those already listed in 276 [RFC5440] and [RFC8231]. 278 5.5. Requirements On Other Protocols 280 Mechanisms defined in this document do not imply any new requirements 281 on other protocols. 283 5.6. Impact On Network Operations 285 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 286 extensions defined in this document. Further, the mechanism 287 described in this document can help the operator to request control 288 of the LSPs at a particular PCE. 290 6. IANA Considerations 292 There are no IANA consideration in this document. 294 7. Security Considerations 296 The protocol extensions defined in this document do not change the 297 nature of PCEP. Therefore, the security considerations set out in 298 [RFC5440], [RFC7470], [RFC8231] and [RFC8281] apply unchanged. 300 As stated in [RFC6952], PCEP implementations SHOULD support the TCP- 301 AO [RFC5925] and not use TCP MD5 because of TCP MD5's known 302 vulnerabilities and weakness. PCEP also support Transport Layer 303 Security (TLS) [RFC8253] as per the recommendations and best current 304 practices in [RFC7525]. 306 8. Acknowledgments 308 Thanks to Avantika, Mahendra Singh Negi, Udayasree Palle and Swapna K 309 for their suggestions. 311 9. References 313 9.1. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 321 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 322 DOI 10.17487/RFC5440, March 2009, 323 . 325 [RFC7470] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 326 Constraints in the Path Computation Element Communication 327 Protocol", RFC 7470, DOI 10.17487/RFC7470, March 2015, 328 . 330 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 331 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 332 May 2017, . 334 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 335 Computation Element Communication Protocol (PCEP) 336 Extensions for Stateful PCE", RFC 8231, 337 DOI 10.17487/RFC8231, September 2017, 338 . 340 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 341 Computation Element Communication Protocol (PCEP) 342 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 343 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 344 . 346 9.2. Informative References 348 [I-D.ietf-pce-pcep-yang] 349 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 350 YANG Data Model for Path Computation Element 351 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 352 yang-12 (work in progress), July 2019. 354 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 355 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 356 June 2010, . 358 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 359 BGP, LDP, PCEP, and MSDP Issues According to the Keying 360 and Authentication for Routing Protocols (KARP) Design 361 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 362 . 364 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 365 "Recommendations for Secure Use of Transport Layer 366 Security (TLS) and Datagram Transport Layer Security 367 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 368 2015, . 370 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 371 Stateful Path Computation Element (PCE)", RFC 8051, 372 DOI 10.17487/RFC8051, January 2017, 373 . 375 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 376 "PCEPS: Usage of TLS to Provide a Secure Transport for the 377 Path Computation Element Communication Protocol (PCEP)", 378 RFC 8253, DOI 10.17487/RFC8253, October 2017, 379 . 381 Appendix A. Contributor Addresses 383 Dhruv Dhody 384 Huawei Technologies 385 Divyashree Techno Park, Whitefield 386 Bangalore, Karnataka 560066 387 India 389 Authors' Addresses 391 Cheng Li 392 Huawei Technologies 393 Huawei Campus, No. 156 Beiqing Rd. 394 Beijing 100095 395 China 397 Email: chengli13@huawei.com 399 Haomian Zheng 400 Huawei Technologies 401 F3 RnD Center, Huawei Industrial Base, Bantian, Longgang District 402 Shenzhen, Guangdong 518129 403 P.R.China 405 Email: zhenghaomian@huawei.com 407 Siva Sivabalan 408 Cisco Systems, Inc. 409 2000 Innovation Drive 410 Kanata, Ontario K2K 3E8 411 Canada 413 Email: msiva@cisco.com