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