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