idnits 2.17.1 draft-farrel-pce-rfc7150bis-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 : ---------------------------------------------------------------------------- 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 21, 2014) is 3559 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 normative reference: RFC 6006 (Obsoleted by RFC 8306) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7150 (Obsoleted by RFC 7470) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Fatai Zhang 3 Internet-Draft Huawei 4 Intended status: Standards Track A. Farrel 5 Obsoletes: 7150 (if approved) Juniper Networks 7 Expires: January 21, 2015 July 21, 2014 9 Conveying Vendor-Specific Constraints in the Path 10 Computation Element communication Protocol 12 draft-farrel-pce-rfc7150bis-01.txt 14 Abstract 16 The Path Computation Element communication Protocol (PCEP) is used to 17 convey path computation requests and responses both between Path 18 Computation Clients (PCCs) and Path Computation Elements (PCEs) and 19 between cooperating PCEs. In PCEP, the path computation requests 20 carry details of the constraints and objective functions that the PCC 21 wishes the PCE to apply in its computation. 23 This document defines a facility to carry vendor-specific information 24 in PCEP using a dedicated object and a new Type-Length-Variable that 25 can be carried in any existing PCEP object. 27 This document obsoletes RFC 7150. The only change from that document 28 is the allocation of a different code point for the 29 VENDOR-INFORMATION object. 31 Status of this Memo 33 This Internet-Draft is submitted to IETF in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF), its areas, and its working groups. Note that other 38 groups may also distribute working documents as Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html 51 Copyright Notice 53 Copyright (c) 2014 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 1. Introduction 68 A Path Computation Element (PCE) is an entity (component, 69 application, or network node) that is capable of computing a network 70 path or route based on a network graph and applying computational 71 constraints. An architecture for the use of PCEs is defined in 72 [RFC4655]. 74 The Path Computation Element communication Protocol (PCEP) is defined 75 in [RFC5440] to exchange path computation requests and responses 76 between Path Computation Clients (PCCs) and PCEs. It is also used 77 between cooperating PCEs. 79 Path computations performed by a PCE depend on a set of constraints 80 indicated by the PCC. These constraints include the endpoints of the 81 path to compute (source and destination) and may include other simple 82 constraints such as bandwidth requirements and metric maxima (for 83 example, a maximum threshold for the hop count or the Traffic 84 Engineering (TE) metric of the computed path). 86 The PCE also needs to use an objective function to qualify the path 87 it selects as meeting the requirements of the PCC. The PCE may have 88 a default objective function, but the PCC can also indicate which 89 objective function it wants applied by placing an Objective Function 90 object in the path computation request message [RFC5541]. A core set 91 of objective functions to be supported in PCEP messages is defined in 92 the base PCEP requirements [RFC4657], and [RFC5541] defines each of 93 these functions as an abstract formula. 95 The registry of codepoints used to indicate objective functions is 96 managed by IANA and new assignments can be made according to "IETF 97 Review" and "First Come First Served" policies [RFC5226]. PCE 98 implementations may also choose to offer proprietary, vendor-specific 99 objective functions, and there is scope for this within the codepoint 100 registry created by [RFC5541] using the codepoints that are flagged 101 as "Reserved for Private Use". 103 Proprietary objective functions may operate on non-standard 104 constraints or metrics. The PCEP METRIC Object defined in [RFC5440] 105 has scope for the definition of new, standardized metrics, but no 106 facility for the definition of vendor-specific metrics. At the same 107 time, there is no mechanism in PCEP for carrying other, more complex, 108 vendor-specific information. 110 This document defines a new PCEP object, the Vendor Information 111 object that can be used to carry arbitrary, proprietary information 112 such as vendor-specific constraints. 114 This document also defines a new PCEP TLV, the VENDOR-INFORMATION-TLV 115 that can be used to carry arbitrary information within any PCEP 116 object that supports TLVs. 118 It should be noted that by the very definition of "vendor-specific", 119 the inclusion of either a Vendor Information object or the VENDOR- 120 INFORMATION-TLV implies an inability to interoperate at a functional 121 level with implementations from other vendors unless there is some 122 cooperation agreement between vendors. Sections 2.1 and 3.1 discuss 123 backward compatibility, which indicates how these protocol constructs 124 are handled by implementations that do not support them at all, while 125 text in Sections 2 and 3 describe how implementations handle the 126 constructs if they understand them, but do not support the embedded 127 Enterprise Number that indicates to which vendor the constructs 128 apply. 130 When vendor-specific information is used by an implementation, the 131 vendor is encouraged to document the meaning of the information to 132 encourage wider use and implementation. In particular, when there is 133 more general interest in a vendor-specific extension, the vendor is 134 encouraged to bring it to the IETF for standardization as a regular 135 protocol construct moving it out of the vendor-specific space. 137 This document obsoletes RFC 7150. The only change from that document 138 is the allocation of a different code point for the 139 VENDOR-INFORMATION object. This change became necessary because of 140 an inadvertant clash with codepoints used in another Internet-Draft 141 that had been deployed without IANA allocation. The PCE working 142 group has conducted a survey of implementations and deployments of 143 RFC 7150 and considers that this change is safe and does not harm 144 early implementers of RFC 7150. 146 1.1. Conventions Used in This Document 148 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 149 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 150 "OPTIONAL" in this document are to be interpreted as described in 151 [RFC2119]. 153 2. Procedures for the Vendor Information Object 155 A PCC that wants to convey proprietary or vendor-specific constraints 156 or metrics to a PCE does so by including a Vendor Information object 157 in the PCReq message. The contents and format of the object are 158 described in Section 4, but it is important to note that the object 159 includes an Enterprise Number that is a unique identifier of an 160 organization responsible for the definition of the content and 161 meaning of the object. 163 A PCE that receives a PCReq message containing a Vendor Information 164 object MUST act according to the P flag in the object header. That 165 is, if the P flag is set, the object will be treated as mandatory and 166 the request will either be processed using the contents of the object 167 or be rejected as defined in [RFC5440] (see also Section 2.1). If 168 the P flag is clear, then, as defined in [RFC5440], the object may be 169 used by the PCE or may be ignored. The PCC sets the P flag according 170 to how it wishes the request to be processed. 172 The PCE determines how to interpret the information in the Vendor 173 Information object by examining the Enterprise Number it contains. 174 An implementation that supports the Vendor Information object, but 175 receives one carrying an Enterprise Number that it does not support 176 MUST act according to the P flag in the object. That is, if the P 177 flag is set, the PCE MUST reject the PCReq as defined in [RFC5440] by 178 sending an Error message with Error-Type="Not supported Object" along 179 with the corresponding Vendor Information object. 181 The Vendor Information object is OPTIONAL in a PCReq message. 182 Multiple instances of the object MAY be used on a single PCReq 183 message, and each MUST be treated according to its P-bit setting. 184 Different instances of the object can have different Enterprise 185 Numbers. 187 The object can be present in the PCReq message to enable it to apply 188 to a single path computation request or to a set of synchronized 189 requests. This usage mirrors the usage of the Objective Function 190 object [RFC5541]. Thus, the PCReq message based on [RFC6006] is 191 encoded as follows using the syntax described in [RFC5511]. 193 ::= 194 [] 195 197 where 199 ::= 200 [] 201 [] 202 [] 203 [] 204 [] 205 [] 207 ::= 208 [] 210 ::= 211 [] 213 ::= 214 [] 216 ::= 217 [] 218 219 [] 220 [] 221 [] 222 [] 223 [] 224 [] 225 [] 227 where 229 ::= 230 [] 231 [] 232 [] 233 [] 235 ::= [] [] 237 ::= [] 239 The Vendor Information object can be included in a PCRep message in 240 exactly the same way as any other object as defined in [RFC5440]. 242 Thus, the PCRep is encoded as follows: 244 ::= 245 247 ::= 248 [] 249 [] 250 [] 251 [] 253 where: 255 ::= 256 [] 257 258 [] 259 [] 261 ::= (|) [] 263 ::= [] 264 [] 265 [] 266 [] 267 [] 269 2.1. Backward Compatibility for the Vendor Information Object 271 A legacy implementation that does not recognize the Vendor 272 Information object will act according to the procedures set out in 273 [RFC5440]. If the P flag is set in the object, the message will be 274 rejected using a PCErr message with an Error Type of 3 ("Unknown 275 Object"). If the P flag is not set, the object can safely be ignored 276 by the recipient. 278 3. Procedures for the Vendor Information TLV 280 The Vendor Information TLV can be used to carry vendor-specific 281 information that applies to a specific PCEP object by including the 282 TLV in the object. 284 The PCE determines how to interpret the Vendor Information TLV by 285 examining the Enterprise Number it contains. If the Enterprise 286 Number is unknown to the PCE, it MUST treat the Vendor Information 287 TLV as an unknown TLV and handle it as described in [RFC5440] (see 288 also Section 3.1). 290 Further specifications are needed to define the position and meaning 291 of the Vendor Information TLV for specific PCEP objects. 293 3.1. Backward Compatibility 295 A legacy implementation that does not recognize the Vendor 296 Information TLV in an object will act according to the procedures set 297 out in [RFC5440]. As described in Section 7.1 of [RFC5440], 298 unrecognized TLVs MUST be ignored. 300 4. Protocol Elements 302 The Vendor Information object and TLV conform to the format for PCEP 303 objects and TLVs defined in [RFC5440]. 305 VENDOR-INFORMATION Object-Class xx (TBA by IANA) 307 VENDOR-INFORMATION Object-Type 1 309 VENDOR-INFORMATION-TLV Type 7 311 The format of the VENDOR-INFORMATION object and the format of the 312 VENDOR-INFORMATION-TLV are the same and are as shown in Figure 1. 314 0 1 2 3 315 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | Enterprise Number | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 ~ Enterprise-Specific Information ~ 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 Figure 1 : Format of the Vendor Information Object and TLV 324 Enterprise Number 326 A unique identifier of an organization encoded as a 32-bit 327 integer. Enterprise Numbers are assigned by IANA and managed 328 through an IANA registry [RFC2578]. 330 Enterprise-Specific Information 332 The detailed enterprise-specific constraint information carried by 333 the object. The format and interpretation of this information is 334 a matter for the enterprise identified by the Enterprise Number. 335 Such formats and interpretation may be published by the enterprise 336 (possibly through an Informational RFC or through commercial 337 documentation) so that PCCs or PCEs that are not part of the 338 organization can use the information. 340 5. IANA Considerations 342 IANA maintains a registry of PCEP parameters called the "Path 343 Computation Element Protocol (PCEP) Numbers". 345 5.1. New PCEP Object 347 IANA had previously allocated the value 32 from the "PCEP Objects" 348 subregistry for use as the VENDOR-INFORMATION object. 350 IANA is requested to release that value and mark it as unassigned. 352 IANA is requested to assign a new value as follows. IANA is 353 requested to assign the value 34. 355 Object-Class Value Name Reference 356 xx VENDOR-INFORMATION [This.I-D] 357 Object-Type 358 0: Unassigned 359 1: Vendor-Specific Constraints [This.I-D] 360 2-255: Unassigned 362 5.2. New PCEP TLV 364 IANA has made an allocation from the "PCEP TLV Type Indicators" 365 subregistry as follows. 367 Value Description Reference 368 7 VENDOR-INFORMATION-TLV [RFC7150] 370 IANA is requested to update the reference to point to this document. 372 6. Management Considerations 374 This section follows the guidance of [RFC5706] and [RFC6123]. 376 6.1. Control of Function and Policy 378 A PCEP implementation SHOULD allow configuring of various parameters 379 as described in [RFC5440]. A PCC implementation that uses vendor- 380 specific information MAY make the use of this information 381 configurable either across the whole PCC, per PCE that the PCC uses, 382 or per path computation request. A PCE that supports vendor-specific 383 information MAY make the support of this information configurable, 384 and MAY allow configuration of policies for the use of the 385 information. 387 6.2. Information and Data Models 389 A PCEP MIB module is defined in [PCE-MIB] that describes managed 390 objects for modeling of PCEP communications. 392 It is NOT RECOMMENDED that standard MIB modules be extended to 393 include detailed information about the content of the Vendor 394 Information object or TLV. However, the standard MIB module MAY be 395 extended to report the use of the Vendor Information object or TLV 396 and the Enterprise Numbers that the objects and TLVs contain. 398 6.3. Liveness Detection and Monitoring 400 This document makes no change to the basic operation of PCEP, so 401 there are no changes to the requirements for liveness detection and 402 monitoring set out in [RFC4657] and [RFC5440]. 404 6.4. Verifying Correct Operation 406 This document makes no change to the basic operation of PCEP, so 407 there are no changes to the requirements or techniques for monitoring 408 the correct operation of the protocol out in [RFC4657] and [RFC5440]. 410 Note that "correct operation" in this context refers to the operation 411 of the protocol itself and not to the operation of the computation 412 algorithms which are out of scope for all PCEP work. 414 Mechanisms for verifying the correct operation of computation 415 algorithms might involve comparing the results returned by more than 416 one PCE. Scope for this might be limited by the use of vendor 417 information unless multiple PCEs support the same set of vendor 418 information. 420 6.5. Requirements on Other Protocols and Functional Components 422 This document does not place any new requirements on other network 423 components or protocols. However, it may be beneficial to consider 424 whether a PCE should advertise the Enterprise Numbers and vendor 425 information it supports. This advertisement could be within PCE 426 Discovery [RFC5088] [RFC5089] or through extensions to PCEP 427 [RFC5440]. 429 Extensions for discovery and advertisement are outside the scope of 430 this document. 432 6.6. Impact on Network Operation 434 The availability of vendor information in PCEP messages may 435 facilitate more complex and detailed path computations that may 436 enhance the way in which the network is operated. 438 On the other hand, the presence of additional vendor-specific 439 information in PCEP messages may congest the operation of the 440 protocol especially if the PCE does not support the information 441 supplied by the PCC. Thus, a PCC SHOULD monitor the capabilities of 442 a PCE either by discovery mechanisms as described in Section 6.5 or 443 through the receipt of negative responses. A PCC SHOULD NOT include 444 vendor information in a PCReq message to a PCE that it believes does 445 not support the information and that will not forward the request to 446 some other PCE that does support the information. 448 7. Security Considerations 450 The protocol extensions defined in this document do not substantially 451 change the nature of PCEP. Therefore, the security considerations 452 set out in [RFC5440] apply unchanged. Note that further security 453 considerations for the use of PCEP over TCP are presented in 454 [RFC6952]. 456 Operators should note that an attack on PCEP may involve making PCEP 457 messages as large as possible in order to consume bandwidth and 458 processing power. The Vendor Information object and TLV may provide 459 a vector for this type of attack. It may be protected against by 460 using the authentication and integrity procedures described in 461 [RFC5440]. 463 8. References 465 8.1. Normative References 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation 471 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 472 March 2009. 474 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 475 Used to Form Encoding Rules in Various Routing Protocol 476 Specifications", RFC 5511, April 2009. 478 [RFC6006] Zhao, Q., Ed., King, D., Ed., Verhaeghe, F., Takeda, T., 479 Ali, Z., and J. Meuric, "Extensions to the Path 480 Computation Element Communication Protocol (PCEP) for 481 Point-to-Multipoint Traffic Engineering Label Switched 482 Paths", RFC 6006, September 2010. 484 8.2. Informative References 486 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 487 Schoenwaelder, Ed., "Structure of Management Information 488 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 490 [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path 491 Computation Element (PCE)-Based Architecture", RFC 4655, 492 August 2006. 494 [RFC4657] Ash, J., Ed., and J. Le Roux, Ed., "Path Computation 495 Element (PCE) Communication Protocol Generic 496 Requirements", RFC 4657, September 2006. 498 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 499 Zhang, "OSPF Protocol Extensions for Path Computation 500 Element (PCE) Discovery", RFC 5088, January 2008. 502 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 503 Zhang, "IS-IS Protocol Extensions for Path Computation 504 Element (PCE) Discovery", RFC 5089, January 2008. 506 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 507 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 508 May 2008. 510 [RFC5541] Le Roux, JL., Vasseur, JP., and Y. Lee, "Encoding of 511 Objective Functions in the Path Computation Element 512 Communication Protocol (PCEP)", RFC 5541, June 2009. 514 [RFC5706] Harrington, D., "Guidelines for Considering Operations and 515 Management of New Protocols and Protocol Extensions", RFC 516 5706, November 2009. 518 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 519 Computation Element (PCE) Working Group Drafts", RFC 6123, 520 February 2011. 522 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 523 BGP, LDP, PCEP, and MSDP Issues According to the Keying 524 and Authentication for Routing Protocols (KARP) Design 525 Guide", RFC 6952, May 2013. 527 [RFC7150] Zhang, F. and A. Farrel, "Conveying Vendor-Specific 528 Constraints in the Path Computation Element Communication 529 Protocol", RFC 7150, March 2014. 531 [PCE-MIB] Koushik, A., Stephan, E., Zhao, Q., King, D., and J. 532 Hardwick, "Path Computation Element Protocol (PCEP) 533 Management Information Base", Work in Progress, February 534 2014. 536 9. Acknowledgements 538 Thanks to Meral Shirazipour, Ramon Casellas, Cyril Margaria, Dhruv 539 Dhody, Julien Meuric, and Robert Sparks for review and comments of 540 the work that became RFC 7150. 542 10. Contributors 544 Greg Bernstein 545 Grotto Networking 546 EMail: gregb@grotto-networking.com 548 Ina Minei 549 Juniper Networks 550 EMail: ina@juniper.net 552 Authors' Addresses 554 Adrian Farrel 555 Juniper Networks 556 EMail: adrian@olddog.co.uk 558 Fatai Zhang 559 Huawei Technologies 560 EMail: zhangfatai@huawei.com