idnits 2.17.1 draft-ietf-pce-lsp-control-request-02.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 (December 18, 2018) is 1956 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 (-23) exists of draft-ietf-pce-pcep-yang-09 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 A. Raghuram 3 Internet-Draft A. Goddard 4 Intended status: Standards Track C. Yadlapalli 5 Expires: June 21, 2019 AT&T 6 J. Karthik 7 S. Sivabalan 8 J. Parker 9 Cisco Systems, Inc. 10 D. Dhody 11 Huawei Technologies 12 December 18, 2018 14 Ability for a stateful Path Computation Element (PCE) to request and 15 obtain control of a LSP 16 draft-ietf-pce-lsp-control-request-02 18 Abstract 20 The stateful Path Computation Element (PCE) communication Protocol 21 (PCEP) extensions provide stateful control of Multiprotocol Label 22 Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSP) 23 via PCEP, for a model where a Path Computation Client (PCC) delegates 24 control over one or more locally configured LSPs to a stateful PCE. 25 There are use-cases in which a stateful PCE may wish to request and 26 obtain control of one or more LSPs from a PCC. This document 27 describes a simple extension to stateful PCEP to achieve such an 28 objective. 30 Requirements Language 32 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 33 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 34 "OPTIONAL" in this document are to be interpreted as described in BCP 35 14 [RFC2119] [RFC8174] when, and only when, they appear in all 36 capitals, as shown here. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on June 21, 2019. 55 Copyright Notice 57 Copyright (c) 2018 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (https://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 3. LSP Control Request Flag . . . . . . . . . . . . . . . . . . 4 75 4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 78 6.1. SRP Object Flags . . . . . . . . . . . . . . . . . . . . 6 79 7. Manageability Considerations . . . . . . . . . . . . . . . . 6 80 7.1. Control of Function and Policy . . . . . . . . . . . . . 6 81 7.2. Information and Data Models . . . . . . . . . . . . . . . 6 82 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 6 83 7.4. Verify Correct Operations . . . . . . . . . . . . . . . . 6 84 7.5. Requirements On Other Protocols . . . . . . . . . . . . . 7 85 7.6. Impact On Network Operations . . . . . . . . . . . . . . 7 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 89 9.2. Informative References . . . . . . . . . . . . . . . . . 8 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 92 1. Introduction 94 Stateful PCEP extensions [RFC8231] specifies a set of extensions to 95 PCEP [RFC5440] to enable stateful control of TE LSPs between and 96 across PCEP sessions in compliance with [RFC4657]. It includes 97 mechanisms to effect LSP state synchronization between PCCs and PCEs, 98 delegation of control of LSPs to PCEs, and PCE control of timing and 99 sequence of path computations within and across PCEP sessions. The 100 stateful PCEP defines the following two useful network operations: 102 o Delegation: As per [RFC8051], an operation to grant a PCE 103 temporary rights to modify a subset of LSP parameters on one or 104 more LSPs of a PCC. LSPs are delegated from a PCC to a PCE and 105 are referred to as "delegated" LSPs. 107 o Revocation: As per [RFC8231], an operation performed by a PCC on a 108 previously delegated LSP. Revocation revokes the rights granted 109 to the PCE in the delegation operation. 111 For Redundant Stateful PCEs (section 5.7.4. of [RFC8231]), during a 112 PCE failure, one of the redundant PCE could request to take control 113 over an LSP. The redundant PCEs MAY use a local policy or a 114 proprietary election mechanism to decide which PCE would take 115 control. In this case, a mechanism is needed for a stateful PCE to 116 request control of one or more LSPs from a PCC, so that a newly 117 elected primary PCE can request to take over control. 119 In case of virtualized PCEs (vPCE) running as virtual network 120 function (VNF), as the computation load in the network increases, a 121 new instance of vPCE could be instantiated to balance the current 122 load. The PCEs could use proprietary algorithm to decide which LSPs 123 to be assigned to the new vPCE. Thus having a mechanism for the PCE 124 to request control of some LSPs is needed. 126 In some deployments, the operator would like to use stateful PCE for 127 global optimization algorithms but would still like to keep the 128 control of the LSP at the PCC. In such cases, a stateful PCE could 129 request to take control during the global optimization and return the 130 delegation once done. 132 Note that [RFC8231] specify a mechanism for a PCC to delegate an 133 orphaned LSP to another PCE. The mechanism defined in this document 134 can be used in conjunction to [RFC8231]. Ultimately, it is the PCC 135 that decides which PCE to delegate the orphaned LSP. 137 This specification provides a simple extension, by using this a PCE 138 can request control of one or more LSPs from any PCC over the 139 stateful PCEP session. The procedures for granting and relinquishing 140 control of the LSPs are specified in accordance with the 141 specification [RFC8231]. 143 2. Terminology 145 The following terminologies are used in this document: 147 PCC: Path Computation Client. 149 PCE: Path Computation Element 151 PCEP: Path Computation Element communication Protocol. 153 PCRpt: Path Computation State Report message. 155 PCUpd: Path Computation Update Request message. 157 PLSP-ID: A PCEP-specific identifier for the LSP. 159 3. LSP Control Request Flag 161 The Stateful PCE Request Parameters (SRP) object is defined in 162 [RFC8231], it includes a Flags field. [RFC8281] defines a R (LSP- 163 REMOVE) flag. 165 A new flag, the "LSP Control Request Flag" (C), is introduced in the 166 SRP object. On a PCUpd message, a PCE sets the C Flag to 1 to 167 indicate that, it wishes to gain control of LSP(s). The LSP is 168 identified by the LSP object. A PLSP-ID of value other than 0 and 169 0xFFFFF is used to identify the LSP for which the PCE requests 170 control. The PLSP-ID value of 0 indicates that the PCE is requesting 171 control of all LSPs originating from the PCC that it wishes to 172 delegate. The flag has no meaning in the PCRpt and PCInitiate 173 message and MUST be set to 0 on transmission and MUST be ignored on 174 receipt. 176 4. Operation 178 During normal operation, a PCC that wishes to delegate the control of 179 an LSP sets the D Flag (delegate) to 1 in all PCRpt messages 180 pertaining to the LSP. The PCE confirms the delegation by setting D 181 Flag to 1 in all PCUpd messages pertaining to the LSP. The PCC 182 revokes the control of the LSP from the PCE by setting D Flag to 0 in 183 PCRpt messages pertaining to the LSP. If the PCE wishes to 184 relinquish the control of the LSP, it sets D Flag to 0 in all PCUpd 185 messages pertaining to the LSP. 187 If a PCE wishes to gain control over an LSP, it sends a PCUpd message 188 with C Flag set to 1 in SRP object. The LSP for which the PCE 189 requests control is identified by the PLSP-ID. The PLSP-ID of 0 190 indicates that the PCE wants control over all LSPs originating from 191 the PCC. If the LSP(s) is/are already delegated to the PCE making 192 the request, the PCC ignores the C Flag. A PCC can decide to 193 delegate the control of the LSP at its own discretion. If the PCC 194 grants or denies the control, it sends PCRpt message with D Flag set 195 to 1 and 0 respectively in accordance with according with stateful 196 PCEP [RFC8231] . If the PCC does not grant the control, it MAY choose 197 to not respond, and the PCE may choose to retry requesting the 198 control preferably using exponentially increasing timer. A PCE 199 ignores the C Flag on the PCRpt message. Note that, the PCUpd 200 message with C flag set is received for a currently non-delegated LSP 201 (for which the PCE is requesting delegation), this MUST NOT trigger 202 the error handling as specified in [RFC8231] (a PCErr with Error- 203 type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update 204 Request for a non-delegated LSP)). 206 In case multiple PCEs request control over an LSP, and if the PCC is 207 willing to grant the control, the LSP MUST be delegated to only one 208 PCE chosen by the PCC based on its local policy. 210 It should be noted that a legacy implementation of PCC, that does not 211 understand the C flag in PCUpd message, would simply ignore the flag 212 (and the request to grant control over the LSP). At the same time it 213 would trigger the error condition as specified in [RFC8231] (a PCErr 214 with Error-type=19 (Invalid Operation) and error-value 1 (Attempted 215 LSP Update Request for a non-delegated LSP)). 217 [RFC8281] describes the setup, maintenance and teardown of PCE- 218 initiated LSPs under the stateful PCE model. It also specify how a 219 PCE MAY obtain control over an orphaned LSP that was PCE-initiated. 220 A PCE implementation can apply the mechanism described in this 221 document in conjunction with those in [RFC8281]. 223 5. Security Considerations 225 The security considerations listed in [RFC8231] and [RFC8281] apply 226 to this document as well. However, this document also introduces a 227 new attack vectors. An attacker may flood the PCC with request to 228 delegate all its LSPs at a rate which exceeds the PCC's ability to 229 process them, either by spoofing messages or by compromising the PCE 230 itself. The PCC can simply ignore these messages with no extra 231 actions. Securing the PCEP session using mechanism like Transport 232 Layer Security (TLS) [RFC8253] is RECOMMENDED. 234 6. IANA Considerations 236 This document requests IANA actions to allocate code points for the 237 protocol elements defined in this document. 239 6.1. SRP Object Flags 241 The SRP object is defined in [RFC8231] and the registry to manage the 242 Flag field of the SRP object is requested in [RFC8281]. IANA is 243 requested to make the following allocation in the aforementioned 244 registry. 246 Bit Description Reference 247 TBD LSP Control Request Flag (c-bit) This document 249 7. Manageability Considerations 251 All manageability requirements and considerations listed in [RFC5440] 252 and [RFC8231] apply to PCEP protocol extensions defined in this 253 document. In addition, requirements and considerations listed in 254 this section apply. 256 7.1. Control of Function and Policy 258 A PCE or PCC implementation SHOULD allow the operator to configure 259 the policy based on which it honor the request to control the LSPs. 260 Further, the operator MAY be to be allowed to trigger the LSP control 261 request at the PCE. 263 7.2. Information and Data Models 265 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 266 include mechanism to trigger the LSP control request. 268 7.3. Liveness Detection and Monitoring 270 Mechanisms defined in this document do not imply any new liveness 271 detection and monitoring requirements in addition to those already 272 listed in [RFC5440]. 274 7.4. Verify Correct Operations 276 Mechanisms defined in this document do not imply any new operation 277 verification requirements in addition to those already listed in 278 [RFC5440] and [RFC8231]. 280 7.5. Requirements On Other Protocols 282 Mechanisms defined in this document do not imply any new requirements 283 on other protocols. 285 7.6. Impact On Network Operations 287 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 288 extensions defined in this document. Further, the mechanism 289 described in this document can help the operator to request control 290 of the LSPs at a particular PCE. 292 8. Acknowledgements 294 Thanks to Jonathan Hardwick to remind the authors to not use 295 suggested values in IANA section. 297 9. References 299 9.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, 303 DOI 10.17487/RFC2119, March 1997, 304 . 306 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 307 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 308 DOI 10.17487/RFC5440, March 2009, 309 . 311 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 312 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 313 May 2017, . 315 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 316 Computation Element Communication Protocol (PCEP) 317 Extensions for Stateful PCE", RFC 8231, 318 DOI 10.17487/RFC8231, September 2017, 319 . 321 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 322 Computation Element Communication Protocol (PCEP) 323 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 324 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 325 . 327 9.2. Informative References 329 [I-D.ietf-pce-pcep-yang] 330 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 331 YANG Data Model for Path Computation Element 332 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 333 yang-09 (work in progress), October 2018. 335 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 336 Element (PCE) Communication Protocol Generic 337 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 338 2006, . 340 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 341 Stateful Path Computation Element (PCE)", RFC 8051, 342 DOI 10.17487/RFC8051, January 2017, 343 . 345 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 346 "PCEPS: Usage of TLS to Provide a Secure Transport for the 347 Path Computation Element Communication Protocol (PCEP)", 348 RFC 8253, DOI 10.17487/RFC8253, October 2017, 349 . 351 Authors' Addresses 353 Aswatnarayan Raghuram 354 AT&T 355 200 S Laurel Aevenue 356 Middletown, NJ 07748 357 USA 359 Email: ar2521@att.com 361 Al Goddard 362 AT&T 363 200 S Laurel Aevenue 364 Middletown, NJ 07748 365 USA 367 Email: ag6941@att.com 368 Chaitanya Yadlapalli 369 AT&T 370 200 S Laurel Aevenue 371 Middletown, NJ 07748 372 USA 374 Email: cy098d@att.com 376 Jay Karthik 377 Cisco Systems, Inc. 378 125 High Street 379 Boston, Massachusetts 02110 380 USA 382 Email: jakarthi@cisco.com 384 Siva Sivabalan 385 Cisco Systems, Inc. 386 2000 Innovation Drive 387 Kanata, Ontario K2K 3E8 388 Canada 390 Email: msiva@cisco.com 392 Jon Parker 393 Cisco Systems, Inc. 394 2000 Innovation Drive 395 Kanata, Ontario K2K 3E8 396 Canada 398 Email: jdparker@cisco.com 400 Dhruv Dhody 401 Huawei Technologies 402 Divyashree Techno Park, Whitefield 403 Bangalore, Karnataka 560066 404 India 406 Email: dhruv.ietf@gmail.com