idnits 2.17.00 (12 Aug 2021) /tmp/idnits25194/draft-ietf-pce-lsp-setup-type-03.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 (June 23, 2015) is 2524 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 == Outdated reference: draft-ietf-pce-stateful-pce has been published as RFC 8231 Summary: 0 errors (**), 0 flaws (~~), 3 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 J. Medved 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: December 25, 2015 I. Minei 6 Google, Inc. 7 E. Crabbe 8 Individual Contributor 9 R. Varga 10 Pantheon Technologies SRO 11 J. Tantsura 12 Ericsson 13 J. Hardwick 14 Metaswitch Networks 15 June 23, 2015 17 Conveying path setup type in PCEP messages 18 draft-ietf-pce-lsp-setup-type-03.txt 20 Abstract 22 A Path Computation Element can compute traffic engineering paths (TE 23 paths) through a network that are subject to various constraints. 24 Currently, TE paths are label switched paths (LSPs) which are set up 25 using the RSVP-TE signaling protocol. However, other TE path setup 26 methods are possible within the PCE architecture. This document 27 proposes an extension to PCEP to allow support for different path 28 setup methods over a given PCEP session. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 34 document are to be interpreted as described in [RFC2119]. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 25, 2015. 53 Copyright Notice 55 Copyright (c) 2015 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 3. Path Setup Type TLV . . . . . . . . . . . . . . . . . . . . . 3 73 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 76 6.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 5 77 6.2. New Path Setup Type Registry . . . . . . . . . . . . . . 6 78 6.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 6 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 80 8. Normative References . . . . . . . . . . . . . . . . . . . . 6 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 83 1. Introduction 85 [RFC5440] describes the Path Computation Element Protocol (PCEP) for 86 communication between a Path Computation Client (PCC) and a Path 87 Control Element (PCE) or between one a pair of PCEs. A PCC requests 88 a path subject to various constraints and optimization criteria from 89 a PCE. The PCE responds to the PCC with a hop-by-hop path in an 90 Explicit Route Object (ERO). The PCC uses the ERO to set up the path 91 in the network. 93 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP that allow a 94 PCC to delegate its LSPs to a PCE. The PCE can then update the state 95 of LSPs delegated to it. In particular, the PCE may modify the path 96 of an LSP by sending a new ERO. The PCC uses this ERO to re-route 97 the LSP in a make-before-break fashion. 98 [I-D.ietf-pce-pce-initiated-lsp] specifies a mechanism allowing a PCE 99 to dynamically instantiate an LSP on a PCC by sending the ERO and 100 characteristics of the LSP. The PCC signals the LSP using the ERO 101 and other attributes sent by the PCE. 103 So far, the PCEP protocol and its extensions implicitly assume that 104 the TE paths are label switched, and are established via the RSVP-TE 105 protocol. However, other methods of LSP setup are not precluded. 106 When a new path setup method (other than RSVP-TE) is introduced for 107 setting up a path, a new capability TLV pertaining to the new path 108 setup method MAY be advertised when the PCEP session is established. 109 Such capability TLV MUST be defined in the specification of the new 110 path setup type. When multiple path setup methods are deployed in a 111 network, a given PCEP session may have to simultaneously support more 112 than one path setup types. In this case, the intended path setup 113 method needs to be either explicitly indicated or implied in the 114 appropriate PCEP messages (when necessary) so that both the PCC and 115 the PCE can take the necessary steps to set up the path. This 116 document introduces a generic TLV called "PATH-SETUP-TYPE TLV" and 117 specifies the base procedures to facilitate such operational model. 119 2. Terminology 121 The following terminologies are used in this document: 123 ERO: Explicit Route Object. 124 LSR: Label Switching Router. 125 PCC: Path Computation Client. 126 PCE: Path Computation Element 127 PCEP: Path Computation Element Protocol. 128 TLV: Type, Length, and Value. 130 3. Path Setup Type TLV 132 When a PCEP session is used to set up TE paths using different 133 methods, the corresponding PCE and PCC must be aware of the path 134 setup method used. That means, a PCE must be able to specify paths 135 in the correct format and a PCC must be able take control and take 136 forwarding plane actions appropriate to the path setup type. 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Type | Length | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Reserved | PST | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 Figure 1: PATH-SETUP-TYPE TLV 148 PATH-SETUP-TYPE TLV is an optional TLV associated with the RP 149 ([RFC5440]) and the SRP ([I-D.ietf-pce-stateful-pce]) objects. Its 150 format is shown in the above figure. The type of the TLV is to be 151 defined by IANA. The one octet value contains the Path Setup Type 152 (PST). This document specifies the following PST value: 154 o PST = 0: Path is setup via RSVP-TE signaling protocol(default). 156 The absence of the PATH-SETUP-TYPE TLV is equivalent to an PATH- 157 SETUP-TYPE TLV with an PST value of 0. It is recommended to omit the 158 TLV in the default case. If the RP or SRP object contains more than 159 one PATH-SETUP-TYPE TLVs, only the first TLV MUST be processed and 160 the rest MUST be ignored. 162 If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST 163 ignore the TLV in accordance with ([RFC5440]). If a PCEP speaker 164 recognizes the TLV but does not support the TLV, it MUST send PCErr 165 with Error-Type = 2 (Capability not supported). 167 4. Operation 169 When requesting a path from a PCE using a PCReq message ([RFC5440]), 170 a PCC MAY include the PATH-SETUP-TYPE TLV in the RP object. If the 171 PCE is capable of expressing the path in a format appropriate to the 172 setup method used, it MUST use the appropriate ERO format in the 173 PCRep message. If the path setup type cannot be inferred from the 174 ERO or any other object or TLV in the PCRep message, PATH-SETUP-TYPE 175 TLV may be included in the RP object of the PCRep message. 176 Regardless of whether PATH-SETUP-TYPE TLV is used or not, if the PCE 177 does not support the intended path setup type it MUST send PCErr with 178 Error-Type = TBD (Traffic engineering path setup error) (recommended 179 value is 21) and Error-Value = 1 (Unsupported path setup type) and 180 close the PCEP session. If the path setup types corresponding to the 181 PCReq and PCRep messages do not match, the PCC MUST send a PCErr with 182 Error-Type = 21 (Traffic engineering path setup error) and Error- 183 Value = 2 (Mismatched path setup type) and close the PCEP session. 185 In the case of stateful PCE, if the path setup type cannot be 186 unambiguously inferred from ERO or any other object or TLV, PATH- 187 SETUP-TYPE TLV MAY be used in PCRpt and PCUpd messages. If PATH- 188 SETUP-TYPE TLV is used in PCRpt message, the SRP object MUST be 189 present even in cases when the SRP-ID-number is the reserved value of 190 0x00000000. Regardless of whether PATH-SETUP-TYPE TLV is used or 191 not, if a PCRpt message is triggered due to a PCUpd message (in this 192 case SRP-ID-number is not equal to 0x00000000), the path setup types 193 corresponding to the PCRpt and PCUpd messages should match. 194 Otherwise, the PCE MUST send PCErr with Error-Type = 21 (Traffic 195 engineering path setup error) and Error-Value = 2 (Mismatched path 196 setup type) and close the connection. 198 In the case of PCE initiated LSPs, a PCE MAY include PATH-SETUP-TYPE 199 TLV in PCInitiate message if the message does not have any other 200 means of indicating path setup type. If a PCC does not support the 201 path setup type associated with the PCInitiate message, the PCC MUST 202 send PCErr with Error-Type = 21 (Traffic engineering path setup 203 error) and Error-Value = 1 (Unsupported path setup type) and close 204 the PCEP session. Similarly, as mentioned above, if the path setup 205 type cannot be unambiguously inferred from ERO or any other object or 206 TLV, the PATH-SETUP-TYPE TLV MAY be included in PCRpt messages 207 triggered by PCInitiate message. Regardless of whether PATH-SETUP- 208 TYPE TLV is used or not, if a PCRpt message is triggered by a 209 PCInitiate message, the path setup types corresponding to the PCRpt 210 and the PCInitiate messages should match. Otherwise, the PCE MUST 211 send PCErr message with Error-Type = 21 (Traffic engineering path 212 setup error) and Error-Value = 2 (Mismatched path setup type). 214 5. Security Considerations 216 No additional security measure is required. 218 6. IANA Considerations 220 6.1. PCEP TLV Type Indicators 222 IANA is requested to allocate a new code point in the PCEP TLV Type 223 Indicators registry, as follows: 225 Value Description Reference 227 TBD (recommended 28) PATH-SETUP-TYPE This document 229 6.2. New Path Setup Type Registry 231 IANA is requested to create a new sub-registry within the "Path 232 Computation Element Protocol (PCEP) Numbers" registry called "PATH- 233 SETUP-TYPE TLV PST Field". The allocation policy for this new 234 registry should be by IETF Consensus. The new registry should 235 contain the following value: 237 Value Description Reference 239 0 Traffic engineering path is This document 240 setup using RSVP signaling 241 protocol 243 6.3. PCEP-Error Object 245 IANA is requested to allocate code-points in the PCEP-ERROR Object 246 Error Types and Values registry for a new error-type and the 247 following new error-values: 249 Error-Type Meaning 250 21 Invalid traffic engineering path setup type 252 Error-value=0: Unassigned 253 Error-value=1: Unsupported path setup type 254 Error-value=2: Mismatched path setup type 256 7. Acknowledgements 258 We like to thank Marek Zavodsky for valuable comments. 260 8. Normative References 262 [I-D.ietf-pce-pce-initiated-lsp] 263 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 264 Extensions for PCE-initiated LSP Setup in a Stateful PCE 265 Model", draft-ietf-pce-pce-initiated-lsp-04 (work in 266 progress), April 2015. 268 [I-D.ietf-pce-stateful-pce] 269 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 270 Extensions for Stateful PCE", draft-ietf-pce-stateful- 271 pce-11 (work in progress), April 2015. 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, March 1997. 276 [RFC5440] Vasseur, JP. and JL. Le Roux, "Path Computation Element 277 (PCE) Communication Protocol (PCEP)", RFC 5440, March 278 2009. 280 Authors' Addresses 282 Siva Sivabalan 283 Cisco Systems, Inc. 284 2000 Innovation Drive 285 Kanata, Ontario K2K 3E8 286 Canada 288 Email: msiva@cisco.com 290 Jan Medved 291 Cisco Systems, Inc. 292 170 West Tasman Dr. 293 San Jose, CA 95134 294 USA 296 Email: jmedved@cisco.com 298 Ina Minei 299 Google, Inc. 300 1600 Amphitheatre Parkway 301 Mountain View, CA 94043 302 USA 304 Email: inaminei@google.com 306 Edward Crabbe 307 Individual Contributor 309 Robert Varga 310 Pantheon Technologies SRO 311 Mlynske Nivy 56 312 Bratislava, 821 05 313 Slovakia 315 Email: robert.varga@pantheon.sk 316 Jeff Tantsura 317 Ericsson 318 300 Holger Way 319 San Jose, CA 95134 320 USA 322 Email: jeff.tantsura@ericsson.com 324 Jon Hardwick 325 Metaswitch Networks 326 100 Church Street 327 Enfield, Middlesex 328 UK 330 Email: jon.hardwick@metaswitch.com