idnits 2.17.00 (12 Aug 2021) /tmp/idnits24701/draft-ietf-pce-lsp-setup-type-06.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 (November 20, 2017) is 1643 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: draft-ietf-pce-pce-initiated-lsp has been published as RFC 8281 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: May 24, 2018 Individual 6 I. Minei 7 Google, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 J. Hardwick 11 Metaswitch Networks 12 November 20, 2017 14 Conveying path setup type in PCEP messages 15 draft-ietf-pce-lsp-setup-type-06 17 Abstract 19 A Path Computation Element can compute traffic engineering paths (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 PCEP to allow support for different path 25 setup methods over a given PCEP session. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on May 24, 2018. 50 Copyright Notice 52 Copyright (c) 2017 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Path Setup Type Capability TLV . . . . . . . . . . . . . . . 4 70 4. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 5 71 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 7.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 7 75 7.2. New Path Setup Type Registry . . . . . . . . . . . . . . 8 76 7.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 8 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 78 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 81 10.2. Informative References . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction 86 [RFC5440] describes the Path Computation Element Protocol (PCEP) for 87 communication between a Path Computation Client (PCC) and a Path 88 Computation Element (PCE), or between a PCE and a PCE. A PCC 89 requests a path subject to various constraints and optimization 90 criteria from a PCE. The PCE responds to the PCC with a hop-by-hop 91 path in an Explicit Route Object (ERO). The PCC uses the ERO to set 92 up the path in the network. 94 [RFC8231] specifies extensions to PCEP that allow a PCC to delegate 95 its LSPs to a PCE. The PCE can then update the state of LSPs 96 delegated to it. In particular, the PCE may modify the path of an 97 LSP by sending a new ERO. The PCC uses this ERO to re-route the LSP 98 in a make-before-break fashion. [I-D.ietf-pce-pce-initiated-lsp] 99 specifies a mechanism allowing a PCE to dynamically instantiate an 100 LSP on a PCC by sending the ERO and characteristics of the LSP. The 101 PCC creates the LSP using the ERO and other attributes sent by the 102 PCE. 104 So far, PCEP and its extensions have assumed that the TE paths are 105 label switched and are established via the RSVP-TE protocol. 106 However, other methods of LSP setup are possible in the PCE 107 architecture (see [RFC4655] and [RFC4657]). This document introduces 108 a TLV called "PATH-SETUP-TYPE-CAPABILITY" which allows a PCEP speaker 109 to announce the path setup types it supports when the PCEP session is 110 established. When a new path setup type (other than RSVP-TE) is 111 introduced for setting up a path, a path setup type code and, 112 optionally, a sub-TLV pertaining to the new path setup type will be 113 defined by the document that specifies the new path setup type. 115 When multiple path setup types are deployed in a network, a given 116 PCEP session may have to simultaneously support more than one path 117 setup type. In this case, the intended path setup type needs to be 118 either explicitly indicated or implied in the appropriate PCEP 119 messages (when necessary) so that both the PCC and the PCE can take 120 the necessary steps to set up the path. This document introduces a 121 generic TLV called "PATH-SETUP-TYPE TLV" and specifies the base 122 procedures to facilitate this operational model. 124 2. Terminology 126 The following terminologies are used in this document: 128 ERO: Explicit Route Object. 130 LSR: Label Switching Router. 132 PCC: Path Computation Client. 134 PCE: Path Computation Element. 136 PCEP: Path Computation Element Protocol. 138 PST: Path Setup Type. 140 TLV: Type, Length, and Value. 142 3. Path Setup Type Capability TLV 144 A PCEP speaker indicates which PSTs it supports during the PCEP 145 Initialization phase, as follows. When the PCEP session is created, 146 it sends an Open message with an OPEN object containing the PATH- 147 SETUP-TYPE-CAPABILITY TLV. The format of this TLV is as follows. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type (TBD1) | Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Reserved | PST length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | | 157 // List of PSTs (variable) // 158 | | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | | 161 // Optional sub-TLVs (variable) // 162 | | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 Figure 1: PATH-SETUP-TYPE-CAPABILITY TLV 167 The TLV type is TBD1 (to be assigned by IANA). Its reserved field 168 MUST be set to zero. The other fields in the TLV are as follows. 170 PST length: The length of the list of supported PSTs, in octets, 171 excluding padding. 173 List of PSTs: A list of the PSTs that the PCEP speaker supports. 174 Each PST is a single octet in length. Duplicate entries in this 175 list MUST be ignored. The PCEP speaker MUST pad the list with 176 zeros so that it is a muliple of four octets in length. 178 Optional sub-TLVs: A list of sub-TLVs associated with the supported 179 PSTs. Each sub-TLV MUST obey the rules for TLV formatting defined 180 in ([RFC5440]). That is, each sub-TLV MUST be padded to a four 181 byte alignment, and the length field of each sub-TLV MUST NOT 182 include the padding bytes. This document does not define any sub- 183 TLVs. 185 This document defines the following PST value: 187 o PST = 0: Path is setup using the RSVP-TE signaling protocol. 189 The overall TLV length MUST be equal to the size of the appended sub- 190 TLVs plus the PST length (rounded up to the nearest multiple of four) 191 plus four bytes for the reserved field and PST length field. The PST 192 length field MUST be greater than zero. If a PCEP speaker receives a 193 PATH-SETUP-TYPE-CAPABILITY TLV which violates these rules, then the 194 PCEP speaker MUST send a PCErr message with Error-Type = 10 195 (Reception of an invalid object) and Error-Value = 11 (Malformed 196 object) and MUST close the PCEP session. The PCEP speaker MAY 197 include the malformed OPEN object in the PCErr message as well. 199 If a PCEP speaker receives an OPEN object with more than one PATH- 200 SETUP-TYPE-CAPABILITY TLV then it MUST ignore all but the first 201 instance of this TLV. 203 The absence of the PATH-SETUP-TYPE-CAPABILITY TLV from the OPEN 204 object is equivalent to a PATH-SETUP-TYPE-CAPABILITY TLV containing a 205 single PST of 0 (RSVP-TE signaling protocol) and no sub-TLVs. It is 206 RECOMMENDED that a PCEP speaker omits the PATH-SETUP-TYPE-CAPABILITY 207 TLV if the only PST it supports is RSVP-TE. If a PCEP speaker 208 supports other PSTs besides RSVP-TE, then it SHOULD include the PATH- 209 SETUP-TYPE-CAPABILITY TLV in its OPEN object. 211 If a PCEP speaker does not recognize the PATH-SETUP-TYPE-CAPABILITY 212 TLV, it MUST ignore the TLV in accordance with ([RFC5440]). If a 213 PCEP speaker recognizes the TLV but does not support the TLV, it MUST 214 send a PCErr message with Error-Type = 2 (Capability not supported) 215 and MUST close the PCEP session. 217 4. Path Setup Type TLV 219 When a PCEP session is used to set up TE paths using different 220 methods, the corresponding PCE and PCC must be aware of the path 221 setup method used. That means, a PCE must be able to specify paths 222 in the correct format and a PCC must be able take control plane and 223 forwarding plane actions appropriate to the PST. 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type (28) | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Reserved | PST | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 Figure 2: PATH-SETUP-TYPE TLV 235 PATH-SETUP-TYPE TLV is an optional TLV associated with the RP 236 ([RFC5440]) and the SRP ([RFC8231]) objects. Its format is shown in 237 the above figure. The TLV type is 28. Its reserved field MUST be 238 set to zero. The one octet value contains the PST as defined for the 239 PATH-SETUP-TYPE-CAPABILITY TLV. 241 The absence of the PATH-SETUP-TYPE TLV is equivalent to a PATH-SETUP- 242 TYPE TLV with a PST value of 0 (RSVP-TE). It is RECOMMENDED that a 243 PCEP speaker omits the TLV if the PST is RSVP-TE. If the RP or SRP 244 object contains more than one PATH-SETUP-TYPE TLV, only the first TLV 245 MUST be processed and the rest MUST be ignored. 247 If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST 248 ignore the TLV in accordance with ([RFC5440]). If a PCEP speaker 249 recognizes the TLV but does not support the TLV, it MUST send PCErr 250 with Error-Type = 2 (Capability not supported). 252 5. Operation 254 During the PCEP Initialization phase, if a PCEP speaker receives a 255 PATH-SETUP-TYPE-CAPABILITY TLV from its peer, it MUST infer that the 256 peer suports only the PSTs listed in the TLV. If the PCEP speaker 257 and its peer have no PSTs in common, then the PCEP speaker MUST send 258 a PCErr message with Error-Type = 21 (Invalid traffic engineering 259 path setup type) and Error-Value = 2 (Mismatched path setup type) and 260 close the PCEP session. 262 If the peer has sent no PATH-SETUP-TYPE-CAPABILITY TLV, then the PCEP 263 speaker MUST infer that the peer supports path setup using at least 264 RSVP-TE. The PCEP speaker MAY also infer that the peer supports 265 other path setup types, but the means of inference are outside the 266 scope of this document. 268 When a PCC sends a PCReq message to a PCE ([RFC5440]), it MUST 269 include the PATH-SETUP-TYPE TLV in the RP object, unless the intended 270 PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. 271 If the PCE is capable of expressing the path in a format appropriate 272 to the intended PST, it MUST use the appropriate ERO format in the 273 PCRep message. 275 When a PCE sends a PCRep message to a PCC ([RFC5440]), it MUST 276 include the PATH-SETUP-TYPE TLV in the RP object, unless the PST is 277 RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the 278 PCE does not support the intended PST, it MUST send a PCErr message 279 with Error-Type = 21 (Invalid traffic engineering path setup type) 280 and Error-Value = 1 (Unsupported path setup type) and close the PCEP 281 session. If the PSTs corresponding to the PCReq and PCRep messages 282 do not match, the PCC MUST send a PCErr message with Error-Type = 21 283 (Invalid traffic engineering path setup type) and Error-Value = 2 284 (Mismatched path setup type) and close the PCEP session. 286 When a stateful PCE sends a PCUpd message ([RFC8231]) or a PCInitiate 287 message ([I-D.ietf-pce-pce-initiated-lsp]) to a PCC, it MUST include 288 the PATH-SETUP-TYPE TLV in the SRP object, unless the intended PST is 289 RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. If the 290 PCC does not support the PST associated with the PCUpd or PCInitiate 291 message, it MUST send a PCErr message with Error-Type = 21 (Invalid 292 traffic engineering path setup type) and Error-Value = 1 (Unsupported 293 path setup type) and close the PCEP session. 295 When a PCC sends a PCRpt message to a stateful PCE ([RFC8231]), it 296 MUST include the PATH-SETUP-TYPE TLV in the SRP object, unless the 297 PST is RSVP-TE, in which case it MAY omit the PATH-SETUP-TYPE TLV. 298 The PCC MUST include the SRP object in the PCRpt message if the PST 299 is not RSVP-TE, even when the SRP-ID-number is the reserved value of 300 0x00000000. If the PCRpt message is triggered by a PCUpd or 301 PCInitiate message, then the PST that the PCC indicates in the PCRpt 302 MUST match the PST that the stateful PCE intended in the PCUpd or 303 PCInitiate. If it does not, then the PCE MUST send a PCErr message 304 with Error-Type = 21 (Invalid traffic engineering path setup type) 305 and Error-Value = 2 (Mismatched path setup type) and close the PCEP 306 session. 308 6. Security Considerations 310 The security considerations described in [RFC5440] and 311 [I-D.ietf-pce-pce-initiated-lsp] are applicable to this 312 specification. No additional security measure is required. 314 7. IANA Considerations 316 7.1. PCEP TLV Type Indicators 318 IANA is requested to confirm the early allocation of the following 319 code point in the PCEP TLV Type Indicators registry. 321 Value Description Reference 323 28 PATH-SETUP-TYPE This document 325 IANA is requested to allocate a new code point for the following TLV 326 in the PCEP TLV Type Indicators registry. 328 Value Description Reference 330 TBD1 PATH-SETUP-TYPE-CAPABILITY This document 332 Note to IANA: The above TLV type was not part of the early code point 333 allocation that was done for this draft. It was added to the draft 334 after the early code point allocation had taken place. Please assign 335 a code point from the indicated registry and replace each instance of 336 "TBD1" in this document with the allocated code point. 338 7.2. New Path Setup Type Registry 340 IANA is requested to create a new sub-registry within the "Path 341 Computation Element Protocol (PCEP) Numbers" registry called "PCEP 342 Path Setup Types". The allocation policy for this new registry 343 should be by IETF Consensus. The new registry should contain the 344 following value: 346 Value Description Reference 348 0 Path is setup using the RSVP- This document 349 TE signaling protocol. 351 7.3. PCEP-Error Object 353 IANA is requested to confirm the early allocation of the following 354 code-points in the PCEP-ERROR Object Error Types and Values registry. 356 Error-Type Meaning 357 10 Reception of an invalid object 359 Error-value=11: Malformed object 361 Error-Type Meaning 362 21 Invalid traffic engineering path setup type 364 Error-value=0: Unassigned 365 Error-value=1: Unsupported path setup type 366 Error-value=2: Mismatched path setup type 368 Note to IANA: the early allocation for Error-Type=10, Error-value=11 369 was originally done by draft-ietf-pce-segment-routing. However, we 370 have since moved its definition into this document. Therefore, 371 please update the reference for this Error-value in the indicated 372 registry to point to RFC.ietf-pce-lsp-setup-type. 374 8. Contributors 376 The following people contributed to this document: 378 - Jan Medved 379 - Edward Crabbe 381 9. Acknowledgements 383 We like to thank Marek Zavodsky for valuable comments. 385 10. References 387 10.1. Normative References 389 [I-D.ietf-pce-pce-initiated-lsp] 390 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 391 Extensions for PCE-initiated LSP Setup in a Stateful PCE 392 Model", draft-ietf-pce-pce-initiated-lsp-11 (work in 393 progress), October 2017. 395 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 396 Requirement Levels", BCP 14, RFC 2119, 397 DOI 10.17487/RFC2119, March 1997, . 400 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 401 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 402 DOI 10.17487/RFC5440, March 2009, . 405 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 406 Computation Element Communication Protocol (PCEP) 407 Extensions for Stateful PCE", RFC 8231, 408 DOI 10.17487/RFC8231, September 2017, . 411 10.2. Informative References 413 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 414 Element (PCE)-Based Architecture", RFC 4655, 415 DOI 10.17487/RFC4655, August 2006, . 418 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 419 Element (PCE) Communication Protocol Generic 420 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 421 2006, . 423 Authors' Addresses 424 Siva Sivabalan 425 Cisco Systems, Inc. 426 2000 Innovation Drive 427 Kanata, Ontario K2K 3E8 428 Canada 430 Email: msiva@cisco.com 432 Jeff Tantsura 433 Individual 435 Email: jefftant.ietf@gmail.com 437 Ina Minei 438 Google, Inc. 439 1600 Amphitheatre Parkway 440 Mountain View, CA 94043 441 USA 443 Email: inaminei@google.com 445 Robert Varga 446 Pantheon Technologies SRO 447 Mlynske Nivy 56 448 Bratislava, 821 05 449 Slovakia 451 Email: nite@hq.sk 453 Jon Hardwick 454 Metaswitch Networks 455 100 Church Street 456 Enfield, Middlesex 457 UK 459 Email: jonathan.hardwick@metaswitch.com