idnits 2.17.1 draft-ietf-pce-lsp-setup-type-04.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 (April 25, 2017) is 2557 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: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-09 == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-18 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 Cisco Systems, Inc. 4 Intended status: Standards Track J. Tantsura 5 Expires: October 27, 2017 Individual 6 I. Minei 7 Google, Inc. 8 R. Varga 9 Pantheon Technologies SRO 10 J. Hardwick 11 Metaswitch Networks 12 April 25, 2017 14 Conveying path setup type in PCEP messages 15 draft-ietf-pce-lsp-setup-type-04 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 October 27, 2017. 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 TLV . . . . . . . . . . . . . . . . . . . . . 3 70 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 72 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 73 6.1. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 5 74 6.2. New Path Setup Type Registry . . . . . . . . . . . . . . 6 75 6.3. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 6 76 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 78 9. Normative References . . . . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 [RFC5440] describes the Path Computation Element Protocol (PCEP) for 84 communication between a Path Computation Client (PCC) and a Path 85 Control Element (PCE) or between one a pair of PCEs. A PCC requests 86 a path subject to various constraints and optimization criteria from 87 a PCE. The PCE responds to the PCC with a hop-by-hop path in an 88 Explicit Route Object (ERO). The PCC uses the ERO to set up the path 89 in the network. 91 [I-D.ietf-pce-stateful-pce] specifies extensions to PCEP that allow a 92 PCC to delegate its LSPs to a PCE. The PCE can then update the state 93 of LSPs delegated to it. In particular, the PCE may modify the path 94 of an LSP by sending a new ERO. The PCC uses this ERO to re-route 95 the LSP in a make-before-break fashion. 96 [I-D.ietf-pce-pce-initiated-lsp] specifies a mechanism allowing a PCE 97 to dynamically instantiate an LSP on a PCC by sending the ERO and 98 characteristics of the LSP. The PCC signals the LSP using the ERO 99 and other attributes sent by the PCE. 101 So far, the PCEP protocol and its extensions implicitly assume that 102 the TE paths are label switched, and are established via the RSVP-TE 103 protocol. However, other methods of LSP setup are not precluded. 104 When a new path setup method (other than RSVP-TE) is introduced for 105 setting up a path, a new capability TLV pertaining to the new path 106 setup method MAY be advertised when the PCEP session is established. 107 Such capability TLV MUST be defined in the specification of the new 108 path setup type. When multiple path setup methods are deployed in a 109 network, a given PCEP session may have to simultaneously support more 110 than one path setup types. In this case, the intended path setup 111 method needs to be either explicitly indicated or implied in the 112 appropriate PCEP messages (when necessary) so that both the PCC and 113 the PCE can take the necessary steps to set up the path. This 114 document introduces a generic TLV called "PATH-SETUP-TYPE TLV" and 115 specifies the base procedures to facilitate such operational model. 117 2. Terminology 119 The following terminologies are used in this document: 121 ERO: Explicit Route Object. 123 LSR: Label Switching Router. 125 PCC: Path Computation Client. 127 PCE: Path Computation Element 129 PCEP: Path Computation Element Protocol. 131 TLV: Type, Length, and Value. 133 3. Path Setup Type TLV 135 When a PCEP session is used to set up TE paths using different 136 methods, the corresponding PCE and PCC must be aware of the path 137 setup method used. That means, a PCE must be able to specify paths 138 in the correct format and a PCC must be able take control and take 139 forwarding plane actions appropriate to the path setup type. 141 0 1 2 3 142 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 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Type | Length | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Reserved | PST | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 Figure 1: PATH-SETUP-TYPE TLV 151 PATH-SETUP-TYPE TLV is an optional TLV associated with the RP 152 ([RFC5440]) and the SRP ([I-D.ietf-pce-stateful-pce]) objects. Its 153 format is shown in the above figure. The type of the TLV is to be 154 defined by IANA. The one octet value contains the Path Setup Type 155 (PST). This document specifies the following PST value: 157 o PST = 0: Path is setup via RSVP-TE signaling protocol(default). 159 The absence of the PATH-SETUP-TYPE TLV is equivalent to an PATH- 160 SETUP-TYPE TLV with an PST value of 0. It is recommended to omit the 161 TLV in the default case. If the RP or SRP object contains more than 162 one PATH-SETUP-TYPE TLVs, only the first TLV MUST be processed and 163 the rest MUST be ignored. 165 If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST 166 ignore the TLV in accordance with ([RFC5440]). If a PCEP speaker 167 recognizes the TLV but does not support the TLV, it MUST send PCErr 168 with Error-Type = 2 (Capability not supported). 170 4. Operation 172 When requesting a path from a PCE using a PCReq message ([RFC5440]), 173 a PCC MAY include the PATH-SETUP-TYPE TLV in the RP object. If the 174 PCE is capable of expressing the path in a format appropriate to the 175 setup method used, it MUST use the appropriate ERO format in the 176 PCRep message. If the path setup type cannot be inferred from the 177 ERO or any other object or TLV in the PCRep message, PATH-SETUP-TYPE 178 TLV may be included in the RP object of the PCRep message. 179 Regardless of whether PATH-SETUP-TYPE TLV is used or not, if the PCE 180 does not support the intended path setup type it MUST send PCErr with 181 Error-Type = TBD (Traffic engineering path setup error) (recommended 182 value is 21) and Error-Value = 1 (Unsupported path setup type) and 183 close the PCEP session. If the path setup types corresponding to the 184 PCReq and PCRep messages do not match, the PCC MUST send a PCErr with 185 Error-Type = 21 (Traffic engineering path setup error) and Error- 186 Value = 2 (Mismatched path setup type) and close the PCEP session. 188 In the case of stateful PCE, if the path setup type cannot be 189 unambiguously inferred from ERO or any other object or TLV, PATH- 190 SETUP-TYPE TLV MAY be used in PCRpt and PCUpd messages. If PATH- 191 SETUP-TYPE TLV is used in PCRpt message, the SRP object MUST be 192 present even in cases when the SRP-ID-number is the reserved value of 193 0x00000000. Regardless of whether PATH-SETUP-TYPE TLV is used or 194 not, if a PCRpt message is triggered due to a PCUpd message (in this 195 case SRP-ID-number is not equal to 0x00000000), the path setup types 196 corresponding to the PCRpt and PCUpd messages should match. 197 Otherwise, the PCE MUST send PCErr with Error-Type = 21 (Traffic 198 engineering path setup error) and Error-Value = 2 (Mismatched path 199 setup type) and close the connection. 201 In the case of PCE initiated LSPs, a PCE MAY include PATH-SETUP-TYPE 202 TLV in PCInitiate message if the message does not have any other 203 means of indicating path setup type. If a PCC does not support the 204 path setup type associated with the PCInitiate message, the PCC MUST 205 send PCErr with Error-Type = 21 (Traffic engineering path setup 206 error) and Error-Value = 1 (Unsupported path setup type) and close 207 the PCEP session. Similarly, as mentioned above, if the path setup 208 type cannot be unambiguously inferred from ERO or any other object or 209 TLV, the PATH-SETUP-TYPE TLV MAY be included in PCRpt messages 210 triggered by PCInitiate message. Regardless of whether PATH-SETUP- 211 TYPE TLV is used or not, if a PCRpt message is triggered by a 212 PCInitiate message, the path setup types corresponding to the PCRpt 213 and the PCInitiate messages should match. Otherwise, the PCE MUST 214 send PCErr message with Error-Type = 21 (Traffic engineering path 215 setup error) and Error-Value = 2 (Mismatched path setup type). 217 5. Security Considerations 219 No additional security measure is required. 221 6. IANA Considerations 223 6.1. PCEP TLV Type Indicators 225 IANA is requested to allocate a new code point in the PCEP TLV Type 226 Indicators registry, as follows: 228 Value Description Reference 230 TBD (recommended 28) PATH-SETUP-TYPE This document 232 6.2. New Path Setup Type Registry 234 IANA is requested to create a new sub-registry within the "Path 235 Computation Element Protocol (PCEP) Numbers" registry called "PATH- 236 SETUP-TYPE TLV PST Field". The allocation policy for this new 237 registry should be by IETF Consensus. The new registry should 238 contain the following value: 240 Value Description Reference 242 0 Traffic engineering path is This document 243 setup using RSVP signaling 244 protocol 246 6.3. PCEP-Error Object 248 IANA is requested to allocate code-points in the PCEP-ERROR Object 249 Error Types and Values registry for a new error-type and the 250 following new error-values: 252 Error-Type Meaning 253 21 Invalid traffic engineering path setup type 255 Error-value=0: Unassigned 256 Error-value=1: Unsupported path setup type 257 Error-value=2: Mismatched path setup type 259 7. Contributors 261 The following people contributed to this document: 263 - Jan Medved 264 - Edward Crabbe 266 8. Acknowledgements 268 We like to thank Marek Zavodsky for valuable comments. 270 9. Normative References 272 [I-D.ietf-pce-pce-initiated-lsp] 273 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 274 Extensions for PCE-initiated LSP Setup in a Stateful PCE 275 Model", draft-ietf-pce-pce-initiated-lsp-09 (work in 276 progress), March 2017. 278 [I-D.ietf-pce-stateful-pce] 279 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 280 Extensions for Stateful PCE", draft-ietf-pce-stateful- 281 pce-18 (work in progress), December 2016. 283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 284 Requirement Levels", BCP 14, RFC 2119, 285 DOI 10.17487/RFC2119, March 1997, 286 . 288 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 289 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 290 DOI 10.17487/RFC5440, March 2009, 291 . 293 Authors' Addresses 295 Siva Sivabalan 296 Cisco Systems, Inc. 297 2000 Innovation Drive 298 Kanata, Ontario K2K 3E8 299 Canada 301 Email: msiva@cisco.com 303 Jeff Tantsura 304 Individual 306 Email: jefftant.ietf@gmail.com 308 Ina Minei 309 Google, Inc. 310 1600 Amphitheatre Parkway 311 Mountain View, CA 94043 312 USA 314 Email: inaminei@google.com 316 Robert Varga 317 Pantheon Technologies SRO 318 Mlynske Nivy 56 319 Bratislava, 821 05 320 Slovakia 322 Email: robert.varga@pantheon.sk 323 Jon Hardwick 324 Metaswitch Networks 325 100 Church Street 326 Enfield, Middlesex 327 UK 329 Email: jon.hardwick@metaswitch.com