idnits 2.17.1 draft-ietf-pce-lsp-setup-type-09.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 (March 27, 2018) is 2221 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group S. Sivabalan 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: Standards Track J. Tantsura 5 Expires: September 28, 2018 Individual 6 I. Minei 7 Google, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 J. Hardwick 11 Metaswitch Networks 12 March 27, 2018 14 Conveying path setup type in PCEP messages 15 draft-ietf-pce-lsp-setup-type-09 17 Abstract 19 A Path Computation Element (PCE) can compute Traffic Engineering (TE) 20 paths through a network that are subject to various constraints. 21 Currently, TE paths are Label Switched Paths (LSPs) which are set up 22 using the RSVP-TE signaling protocol. However, other TE path setup 23 methods are possible within the PCE architecture. This document 24 proposes an extension to the PCE communication protocol (PCEP) to 25 allow support for different path setup methods over a given PCEP 26 session. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 28, 2018. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4 66 4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 5 67 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 68 6. Manageability Considerations . . . . . . . . . . . . . . . . 7 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 8.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 8 72 8.2. New Path Setup Type Registry . . . . . . . . . . . . . . 9 73 8.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 9 74 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 78 11.2. Informative References . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 81 1. Introduction 83 [RFC5440] describes the Path Computation Element communication 84 Protocol (PCEP) for communication between a Path Computation Client 85 (PCC) and a Path Computation Element (PCE), or between a PCE and a 86 PCE. A PCC requests a path subject to various constraints and 87 optimization criteria from a PCE. The PCE responds to the PCC with a 88 hop-by-hop path in an Explicit Route Object (ERO). The PCC uses the 89 ERO to set up the path in the network. 91 [RFC8231] specifies extensions to PCEP that allow a PCC to delegate 92 its LSPs to a PCE. The PCE can then update the state of LSPs 93 delegated to it. In particular, the PCE may modify the path of an 94 LSP by sending a new ERO. The PCC uses this ERO to re-route the LSP 95 in a make-before-break fashion. [RFC8281] specifies a mechanism 96 allowing a PCE to dynamically instantiate an LSP on a PCC by sending 97 the ERO and the characteristics of the LSP. The PCC creates the LSP 98 using the ERO and other attributes sent by the PCE. 100 So far, PCEP and its extensions have assumed that the TE paths are 101 label switched and are established via the RSVP-TE protocol. 102 However, other methods of LSP setup are possible in the PCE 103 architecture (see [RFC4655] and [RFC4657]). This document 104 generalizes PCEP to allow other LSP setup methods to be used. It 105 defines two new TLVs and specifies the base procedures to facilitate 106 this, as follows. 108 o The PATH-SETUP-TYPE-CAPABILITY TLV, which allows a PCEP speaker to 109 announce which LSP setup methods it supports when the PCEP session 110 is established. 112 o The PATH-SETUP-TYPE TLV, which allows a PCEP speaker to specify 113 which setup method should be used for a given LSP. When multiple 114 path setup types are deployed in a network, a given PCEP session 115 may have to simultaneously support more than one path setup type. 116 A PCEP speaker uses the PATH-SETUP-TYPE TLV to explicitly indicate 117 the intended path setup type in the appropriate PCEP messages, 118 unless the path setup type is RSVP-TE (which is assumed to be the 119 path setup type if no other setup type is indicated). This is so 120 that both the PCC and the PCE can take the necessary steps to set 121 up the path. 123 This document defines a path setup type code for RSVP-TE. When a new 124 path setup type (other than RSVP-TE) is introduced for setting up a 125 path, a path setup type code and, optionally, a sub-TLV pertaining to 126 the new path setup type will be defined by the document that 127 specifies the new path setup type. 129 1.1. Requirements Language 131 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 132 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 133 document are to be interpreted as described in [RFC2119]. 135 2. Terminology 137 The following terminologies are used in this document: 139 ERO: Explicit Route Object. 141 LSR: Label Switching Router. 143 PCC: Path Computation Client. 145 PCE: Path Computation Element. 147 PCEP: Path Computation Element Protocol. 149 PST: Path Setup Type. 151 TLV: Type, Length, and Value. 153 3. Path Setup Type Capability TLV 155 A PCEP speaker indicates which PSTs it supports during the PCEP 156 initialization phase, as follows. When the PCEP session is created, 157 it sends an Open message with an OPEN object containing the PATH- 158 SETUP-TYPE-CAPABILITY TLV. The format of this TLV is as follows. 160 0 1 2 3 161 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 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Type (TBD1) | Length | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Reserved | Num of PSTs | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | PST#1 | ... | PST#N | Padding | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | | 170 // Optional sub-TLVs (variable) // 171 | | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV 176 The TLV type is TBD1 (to be assigned by IANA). Its reserved field 177 MUST be set to zero. The other fields in the TLV are as follows. 179 Length: The total length of the remainder of the TLV, that is, 180 excluding the Type and Length fields. 182 Number of PSTs: The number of PSTs in the following list, excluding 183 padding. 185 List of PSTs: A list of the PSTs that the PCEP speaker supports. 186 Each PST is a single byte in length. Duplicate entries in this 187 list MUST be ignored. The PCEP speaker MUST pad the list with 188 zeros so that it is a muliple of four bytes in length. This 189 document defines the following PST value: 191 * PST = 0: Path is setup using the RSVP-TE signaling protocol. 193 Optional sub-TLVs: A list of sub-TLVs associated with the supported 194 PSTs. Each sub-TLV MUST obey the rules for TLV formatting defined 195 in ([RFC5440]). That is, each sub-TLV MUST be padded to a four 196 byte alignment, and the length field of each sub-TLV MUST NOT 197 include the padding bytes. This document does not define any sub- 198 TLVs. 200 A PCEP speaker MUST check that this TLV is correctly formatted, as 201 follows. The TLV Length field MUST be equal to the size of the 202 appended sub-TLVs plus the size of the PST list (rounded up to the 203 nearest multiple of four) plus four bytes. The Number of PSTs field 204 MUST be greater than zero. If a PCEP speaker receives a PATH-SETUP- 205 TYPE-CAPABILITY TLV which violates these rules, then the PCEP speaker 206 MUST send a PCErr message with Error-Type = 10 (Reception of an 207 invalid object) and Error-Value = 11 (Malformed object) and MUST 208 close the PCEP session. The PCEP speaker MAY include the malformed 209 OPEN object in the PCErr message as well. 211 If a PCEP speaker receives an OPEN object with more than one PATH- 212 SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first 213 instance of this TLV. 215 The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN 216 object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a 217 single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. A PCEP 218 speaker MAY omit the PATH-SETUP-TYPE-CAPABILITY TLV if the only PST 219 it supports is RSVP-TE. If a PCEP speaker supports other PSTs 220 besides RSVP-TE, then it SHOULD include the PATH-SETUP-TYPE- 221 CAPABILITY TLV in its OPEN object. 223 If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY 224 TLV, it MUST ignore the TLV in accordance with ([RFC5440]). 226 4. Path Setup Type TLV 228 When a PCEP session is used to set up TE paths using different 229 methods, the corresponding PCE and PCC must be aware of the path 230 setup method used. That means, a PCE must be able to specify paths 231 in the correct format and a PCC must be able to take control plane 232 and forwarding plane actions appropriate to the PST. 234 0 1 2 3 235 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 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Type (28) | Length (4) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Reserved | PST | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 2: PATH-SETUP-TYPE TLV 244 PATH-SETUP-TYPE TLV is an optional TLV associated with the RP 245 ([RFC5440]) and the SRP ([RFC8231]) objects. Its format is shown in 246 the above figure. The TLV type is 28. Its reserved field MUST be 247 set to zero. The one byte value contains the PST as defined for the 248 PATH-SETUP-TYPE-CAPABILITY TLV. 250 The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP- 251 TYPE TLV with a PST value of 0 (RSVP-TE). A PCEP speaker MAY omit 252 the TLV if the PST is RSVP-TE. If the RP or SRP object contains more 253 than one PATH-SETUP-TYPE TLV, only the first TLV MUST be processed 254 and the rest MUST be ignored. 256 If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST 257 ignore the TLV in accordance with ([RFC5440]). 259 5. Operation 261 During the PCEP initialization phase, if a PCEP speaker receives a 262 PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST consider that 263 the peer suports only the PSTs listed in the TLV. If the PCEP 264 speaker and its peer have no PSTs in common, then the PCEP speaker 265 MUST send a PCErr message with Error-Type = 21 (Invalid traffic 266 engineering path setup type) and Error-Value = 2 (Mismatched path 267 setup type) and close the PCEP session. 269 If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP 270 speaker MUST infer that the peer supports path setup using at least 271 RSVP-TE. The PCEP speaker MAY also infer that the peer supports 272 other path setup types, but the means of inference are outside the 273 scope of this document. 275 When a PCC sends a PCReq message to a PCE ([RFC5440]), it MUST 276 include the PATH-SETUP-TYPE TLV in the RP object, unless the intended 277 PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. 278 If the PCE is capable of expressing the path in a format appropriate 279 to the intended PST, it MUST use the appropriate ERO format in the 280 PCRep message. 282 When a PCE sends a PCRep message to a PCC ([RFC5440]), it MUST 283 include the PATH-SETUP-TYPE TLV in the RP object, unless the PST is 284 RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the 285 PCE does not support the intended PST, it MUST send a PCErr message 286 with Error-Type = 21 (Invalid traffic engineering path setup type) 287 and Error-Value = 1 (Unsupported path setup type) and close the PCEP 288 session. If the PSTs corresponding to the PCReq and PCRep messages 289 do not match, the PCC MUST send a PCErr message with Error-Type = 21 290 (Invalid traffic engineering path setup type) and Error-Value = 2 291 (Mismatched path setup type) and close the PCEP session. 293 When a stateful PCE sends a PCUpd message ([RFC8231]) or a PCInitiate 294 message ([RFC8281]) to a PCC, it MUST include the PATH-SETUP-TYPE TLV 295 in the SRP object, unless the intended PST is RSVP-TE, in which case 296 it MAY omit the PATH-SETUP-TYPE TLV. If the PCC does not support the 297 PST associated with the PCUpd or PCInitiate message, it MUST send a 298 PCErr message with Error-Type = 21 (Invalid traffic engineering path 299 setup type) and Error-Value = 1 (Unsupported path setup type) and 300 close the PCEP session. 302 When a PCC sends a PCRpt message to a stateful PCE ([RFC8231]), it 303 MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the 304 PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. 305 The PCC MUST include the SRP object in the PCRpt message if the PST 306 is not RSVP-TE, even when the SRP-ID-number is the reserved value of 307 0x00000000. If the PCRpt message is triggered by a PCUpd or 308 PCInitiate message, then the PST that the PCC indicates in the PCRpt 309 MUST match the PST that the stateful PCE intended in the PCUpd or 310 PCInitiate. If it does not, then the PCE MUST send a PCErr message 311 with Error-Type = 21 (Invalid traffic engineering path setup type) 312 and Error-Value = 2 (Mismatched path setup type) and close the PCEP 313 session. 315 6. Manageability Considerations 317 This document generalises PCEP to allow path setup methods other than 318 RSVP-TE to be used by the network. It is possible that, in a given 319 network, multiple path setup methods will be used. It is also 320 possible that not all devices will support the same set of path setup 321 methods. Managing networks that combine multiple path setup methods 322 may therefore raise some challenges from a configuration and 323 observability point of view. 325 Each document that introduces a new path setup type to PCEP must 326 include a manageability section. The manageability section must 327 explain how operators can manage PCEP with the new path setup type. 328 It must address the following questions, which are generally 329 applicable when working with multiple path setup types in PCEP. 331 o What are the criteria for when devices will use the new path setup 332 type in PCEP, and how can the operator control this? 334 o How can the network be migrated to the new path setup type, and 335 are there any backwards compatibility issues that operators need 336 to be aware of? 338 o Are paths set up using the new path setup type intended to coexist 339 with other paths over the long term and, if so, how is this 340 situation managed with PCEP? 342 o How can operators verify the correct operation of PCEP in the 343 network with respect to the new path setup type? Which fault 344 conditions must be reported to the operators? 346 o Are there any existing management interfaces (such as YANG models) 347 that must be extended to model the operation of PCEP in the 348 network with respect to the new path setup type? 350 See [RFC6123] for further guidance on how to write manageability 351 sections in PCEP standards-track documents. 353 7. Security Considerations 355 The security considerations described in [RFC5440] and [RFC8281] are 356 applicable to this specification. No additional security measure is 357 required. 359 8. IANA Considerations 361 8.1. PCEP TLV Type Indicators 363 IANA is requested to confirm the early allocation of the following 364 code point in the PCEP TLV Type Indicators registry. 366 Value Description Reference 368 28 PATH-SETUP-TYPE This document 370 IANA is requested to allocate a new code point for the following TLV 371 in the PCEP TLV Type Indicators registry. 373 Value Description Reference 375 TBD1 PATH-SETUP-TYPE-CAPABILITY This document 377 Note to IANA: The above TLV type was not part of the early code point 378 allocation that was done for this draft. It was added to the draft 379 after the early code point allocation had taken place. Please assign 380 a code point from the indicated registry and replace each instance of 381 "TBD1" in this document with the allocated code point. 383 8.2. New Path Setup Type Registry 385 IANA is requested to create a new sub-registry within the "Path 386 Computation Element Protocol (PCEP) Numbers" registry called "PCEP 387 Path Setup Types". The allocation policy for this new registry 388 should be by IETF Review. The new registry should contain the 389 following value: 391 Value Description Reference 393 0 Path is setup using the RSVP- This document 394 TE signaling protocol. 396 8.3. PCEP-Error Object 398 IANA is requested to confirm the early allocation of the following 399 code-points in the PCEP-ERROR Object Error Types and Values registry. 401 Error-Type Meaning 402 10 Reception of an invalid object 404 Error-value=11: Malformed object 406 Error-Type Meaning 407 21 Invalid traffic engineering path setup type 409 Error-value=0: Unassigned 410 Error-value=1: Unsupported path setup type 411 Error-value=2: Mismatched path setup type 413 Note to IANA: the early allocation for Error-Type=10, Error-value=11 414 was originally done by draft-ietf-pce-segment-routing. However, we 415 have since moved its definition into this document. Therefore, 416 please update the reference for this Error-value in the indicated 417 registry to point to RFC.ietf-pce-lsp-setup-type. 419 9. Contributors 421 The following people contributed to this document: 423 - Jan Medved 424 - Edward Crabbe 426 10. Acknowledgements 428 We like to thank Marek Zavodsky for valuable comments. 430 11. References 432 11.1. Normative References 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, 436 DOI 10.17487/RFC2119, March 1997, 437 . 439 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 440 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 441 DOI 10.17487/RFC5440, March 2009, 442 . 444 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 445 Computation Element Communication Protocol (PCEP) 446 Extensions for Stateful PCE", RFC 8231, 447 DOI 10.17487/RFC8231, September 2017, 448 . 450 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 451 Computation Element Communication Protocol (PCEP) 452 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 453 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 454 . 456 11.2. Informative References 458 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 459 Element (PCE)-Based Architecture", RFC 4655, 460 DOI 10.17487/RFC4655, August 2006, 461 . 463 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 464 Element (PCE) Communication Protocol Generic 465 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 466 2006, . 468 [RFC6123] Farrel, A., "Inclusion of Manageability Sections in Path 469 Computation Element (PCE) Working Group Drafts", RFC 6123, 470 DOI 10.17487/RFC6123, February 2011, 471 . 473 Authors' Addresses 475 Siva Sivabalan 476 Cisco Systems, Inc. 477 2000 Innovation Drive 478 Kanata, Ontario K2K 3E8 479 Canada 481 Email: msiva@cisco.com 483 Jeff Tantsura 484 Individual 486 Email: jefftant.ietf@gmail.com 488 Ina Minei 489 Google, Inc. 490 1600 Amphitheatre Parkway 491 Mountain View, CA 94043 492 USA 494 Email: inaminei@google.com 496 Robert Varga 497 Pantheon Technologies SRO 498 Mlynske Nivy 56 499 Bratislava, 821 05 500 Slovakia 502 Email: nite@hq.sk 504 Jon Hardwick 505 Metaswitch Networks 506 100 Church Street 507 Enfield, Middlesex 508 UK 510 Email: jonathan.hardwick@metaswitch.com