idnits 2.17.1 draft-ietf-pce-lsp-control-request-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 (June 4, 2019) is 1788 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-11 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 6, 2019 AT&T 6 J. Karthik 7 S. Sivabalan 8 J. Parker 9 Cisco Systems, Inc. 10 M. Negi 11 Huawei Technologies 12 June 4, 2019 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-04 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 December 6, 2019. 55 Copyright Notice 57 Copyright (c) 2019 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. Implementation Status . . . . . . . . . . . . . . . . . . . . 5 77 5.1. Huawei's Proof of Concept based on ONOS . . . . . . . . . 6 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 80 7.1. SRP Object Flags . . . . . . . . . . . . . . . . . . . . 7 81 8. Manageability Considerations . . . . . . . . . . . . . . . . 7 82 8.1. Control of Function and Policy . . . . . . . . . . . . . 7 83 8.2. Information and Data Models . . . . . . . . . . . . . . . 7 84 8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 7 85 8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 7 86 8.5. Requirements On Other Protocols . . . . . . . . . . . . . 8 87 8.6. Impact On Network Operations . . . . . . . . . . . . . . 8 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 91 10.2. Informative References . . . . . . . . . . . . . . . . . 9 92 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 10 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 95 1. Introduction 97 Stateful PCEP extensions [RFC8231] specifies a set of extensions to 98 PCEP [RFC5440] to enable stateful control of TE LSPs between and 99 across PCEP sessions in compliance with [RFC4657]. It includes 100 mechanisms to effect LSP state synchronization between PCCs and PCEs, 101 delegation of control of LSPs to PCEs, and PCE control of timing and 102 sequence of path computations within and across PCEP sessions. The 103 stateful PCEP defines the following two useful network operations: 105 o Delegation: As per [RFC8051], an operation to grant a PCE 106 temporary rights to modify a subset of LSP parameters on one or 107 more LSPs of a PCC. LSPs are delegated from a PCC to a PCE and 108 are referred to as "delegated" LSPs. 110 o Revocation: As per [RFC8231], an operation performed by a PCC on a 111 previously delegated LSP. Revocation revokes the rights granted 112 to the PCE in the delegation operation. 114 For Redundant Stateful PCEs (section 5.7.4. of [RFC8231]), during a 115 PCE failure, one of the redundant PCE could request to take control 116 over an LSP. The redundant PCEs MAY use a local policy or a 117 proprietary election mechanism to decide which PCE would take 118 control. In this case, a mechanism is needed for a stateful PCE to 119 request control of one or more LSPs from a PCC, so that a newly 120 elected primary PCE can request to take over control. 122 In case of virtualized PCEs (vPCE) running as virtual network 123 function (VNF), as the computation load in the network increases, a 124 new instance of vPCE could be instantiated to balance the current 125 load. The PCEs could use proprietary algorithm to decide which LSPs 126 to be assigned to the new vPCE. Thus having a mechanism for the PCE 127 to request control of some LSPs is needed. 129 In some deployments, the operator would like to use stateful PCE for 130 global optimization algorithms but would still like to keep the 131 control of the LSP at the PCC. In such cases, a stateful PCE could 132 request to take control during the global optimization and return the 133 delegation once done. 135 Note that [RFC8231] specify a mechanism for a PCC to delegate an 136 orphaned LSP to another PCE. The mechanism defined in this document 137 can be used in conjunction to [RFC8231]. Ultimately, it is the PCC 138 that decides which PCE to delegate the orphaned LSP. 140 This specification provides a simple extension, by using this a PCE 141 can request control of one or more LSPs from any PCC over the 142 stateful PCEP session. The procedures for granting and relinquishing 143 control of the LSPs are specified in accordance with the 144 specification [RFC8231]. 146 2. Terminology 148 The following terminologies are used in this document: 150 PCC: Path Computation Client. 152 PCE: Path Computation Element 154 PCEP: Path Computation Element communication Protocol. 156 PCRpt: Path Computation State Report message. 158 PCUpd: Path Computation Update Request message. 160 PLSP-ID: A PCEP-specific identifier for the LSP. 162 3. LSP Control Request Flag 164 The Stateful PCE Request Parameters (SRP) object is defined in 165 [RFC8231], it includes a Flags field. [RFC8281] defines a R (LSP- 166 REMOVE) flag. 168 A new flag, the "LSP Control Request Flag" (C), is introduced in the 169 SRP object. On a PCUpd message, a PCE sets the C Flag to 1 to 170 indicate that, it wishes to gain control of LSP(s). The LSP is 171 identified by the LSP object. A PLSP-ID of value other than 0 and 172 0xFFFFF is used to identify the LSP for which the PCE requests 173 control. The PLSP-ID value of 0 indicates that the PCE is requesting 174 control of all LSPs originating from the PCC that it wishes to 175 delegate. The flag has no meaning in the PCRpt and PCInitiate 176 message and MUST be set to 0 on transmission and MUST be ignored on 177 receipt. 179 4. Operation 181 During normal operation, a PCC that wishes to delegate the control of 182 an LSP sets the D Flag (delegate) to 1 in all PCRpt messages 183 pertaining to the LSP. The PCE confirms the delegation by setting D 184 Flag to 1 in all PCUpd messages pertaining to the LSP. The PCC 185 revokes the control of the LSP from the PCE by setting D Flag to 0 in 186 PCRpt messages pertaining to the LSP. If the PCE wishes to 187 relinquish the control of the LSP, it sets D Flag to 0 in all PCUpd 188 messages pertaining to the LSP. 190 If a PCE wishes to gain control over an LSP, it sends a PCUpd message 191 with C Flag set to 1 in SRP object. The LSP for which the PCE 192 requests control is identified by the PLSP-ID. The PLSP-ID of 0 193 indicates that the PCE wants control over all LSPs originating from 194 the PCC. If the LSP(s) is/are already delegated to the PCE making 195 the request, the PCC ignores the C Flag. A PCC can decide to 196 delegate the control of the LSP at its own discretion. If the PCC 197 grants or denies the control, it sends PCRpt message with D Flag set 198 to 1 and 0 respectively in accordance with according with stateful 199 PCEP [RFC8231] . If the PCC does not grant the control, it MAY choose 200 to not respond, and the PCE may choose to retry requesting the 201 control preferably using exponentially increasing timer. A PCE 202 ignores the C Flag on the PCRpt message. Note that, the PCUpd 203 message with C flag set is received for a currently non-delegated LSP 204 (for which the PCE is requesting delegation), this MUST NOT trigger 205 the error handling as specified in [RFC8231] (a PCErr with Error- 206 type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update 207 Request for a non-delegated LSP)). 209 In case multiple PCEs request control over an LSP, and if the PCC is 210 willing to grant the control, the LSP MUST be delegated to only one 211 PCE chosen by the PCC based on its local policy. 213 It should be noted that a legacy implementation of PCC, that does not 214 understand the C flag in PCUpd message, would simply ignore the flag 215 (and the request to grant control over the LSP). At the same time it 216 would trigger the error condition as specified in [RFC8231] (a PCErr 217 with Error-type=19 (Invalid Operation) and error-value 1 (Attempted 218 LSP Update Request for a non-delegated LSP)). 220 [RFC8281] describes the setup, maintenance and teardown of PCE- 221 initiated LSPs under the stateful PCE model. It also specify how a 222 PCE MAY obtain control over an orphaned LSP that was PCE-initiated. 223 A PCE implementation can apply the mechanism described in this 224 document in conjunction with those in [RFC8281]. 226 5. Implementation Status 228 [Note to the RFC Editor - remove this section before publication, as 229 well as remove the reference to RFC 7942.] 231 This section records the status of known implementations of the 232 protocol defined by this specification at the time of posting of this 233 Internet-Draft, and is based on a proposal described in RFC 7942 234 [RFC7942]. The description of implementations in this section is 235 intended to assist the IETF in its decision processes in progressing 236 drafts to RFCs. Please note that the listing of any individual 237 implementation here does not imply endorsement by the IETF. 239 Furthermore, no effort has been spent to verify the information 240 presented here that was supplied by IETF contributors. This is not 241 intended as, and must not be construed to be, a catalog of available 242 implementations or their features. Readers are advised to note that 243 other implementations may exist. 245 According to RFC 7942, "this will allow reviewers and working groups 246 to assign due consideration to documents that have the benefit of 247 running code, which may serve as evidence of valuable experimentation 248 and feedback that have made the implemented protocols more mature. 249 It is up to the individual working groups to use this information as 250 they see fit". 252 5.1. Huawei's Proof of Concept based on ONOS 254 The PCE function was developed in the ONOS open source platform. 255 This extension was implemented on a private version as a proof of 256 concept to enable multi-instance support. 258 o Organization: Huawei 260 o Implementation: Huawei's PoC based on ONOS 262 o Description: PCEP as a southbound plugin was added to ONOS. To 263 support multi-instance ONOS deployment in a cluster, this 264 extension in PCEP is used. Refer 265 https://wiki.onosproject.org/display/ONOS/PCEP+Protocol 267 o Maturity Level: Prototype 269 o Coverage: Full 271 o Contact: satishk@huawei.com 273 6. Security Considerations 275 The security considerations listed in [RFC8231] and [RFC8281] apply 276 to this document as well. However, this document also introduces a 277 new attack vectors. An attacker may flood the PCC with request to 278 delegate all its LSPs at a rate which exceeds the PCC's ability to 279 process them, either by spoofing messages or by compromising the PCE 280 itself. The PCC can simply ignore these messages with no extra 281 actions. Securing the PCEP session using mechanism like Transport 282 Layer Security (TLS) [RFC8253] is RECOMMENDED. 284 7. IANA Considerations 286 This document requests IANA actions to allocate code points for the 287 protocol elements defined in this document. 289 7.1. SRP Object Flags 291 The SRP object is defined in [RFC8231] and the registry to manage the 292 Flag field of the SRP object is requested in [RFC8281]. IANA is 293 requested to make the following allocation in the aforementioned 294 registry. 296 Bit Description Reference 297 TBD LSP Control Request Flag (c-bit) This document 299 8. Manageability Considerations 301 All manageability requirements and considerations listed in [RFC5440] 302 and [RFC8231] apply to PCEP protocol extensions defined in this 303 document. In addition, requirements and considerations listed in 304 this section apply. 306 8.1. Control of Function and Policy 308 A PCE or PCC implementation SHOULD allow the operator to configure 309 the policy based on which it honor the request to control the LSPs. 310 Further, the operator MAY be to be allowed to trigger the LSP control 311 request at the PCE. 313 8.2. Information and Data Models 315 The PCEP YANG module [I-D.ietf-pce-pcep-yang] could be extended to 316 include mechanism to trigger the LSP control request. 318 8.3. Liveness Detection and Monitoring 320 Mechanisms defined in this document do not imply any new liveness 321 detection and monitoring requirements in addition to those already 322 listed in [RFC5440]. 324 8.4. Verify Correct Operations 326 Mechanisms defined in this document do not imply any new operation 327 verification requirements in addition to those already listed in 328 [RFC5440] and [RFC8231]. 330 8.5. Requirements On Other Protocols 332 Mechanisms defined in this document do not imply any new requirements 333 on other protocols. 335 8.6. Impact On Network Operations 337 Mechanisms defined in [RFC5440] and [RFC8231] also apply to PCEP 338 extensions defined in this document. Further, the mechanism 339 described in this document can help the operator to request control 340 of the LSPs at a particular PCE. 342 9. Acknowledgements 344 Thanks to Jonathan Hardwick to remind the authors to not use 345 suggested values in IANA section. 347 10. References 349 10.1. Normative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, 353 DOI 10.17487/RFC2119, March 1997, 354 . 356 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 357 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 358 DOI 10.17487/RFC5440, March 2009, 359 . 361 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 362 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 363 May 2017, . 365 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 366 Computation Element Communication Protocol (PCEP) 367 Extensions for Stateful PCE", RFC 8231, 368 DOI 10.17487/RFC8231, September 2017, 369 . 371 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 372 Computation Element Communication Protocol (PCEP) 373 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 374 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 375 . 377 10.2. Informative References 379 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 380 Element (PCE) Communication Protocol Generic 381 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 382 2006, . 384 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 385 Code: The Implementation Status Section", BCP 205, 386 RFC 7942, DOI 10.17487/RFC7942, July 2016, 387 . 389 [RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a 390 Stateful Path Computation Element (PCE)", RFC 8051, 391 DOI 10.17487/RFC8051, January 2017, 392 . 394 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 395 "PCEPS: Usage of TLS to Provide a Secure Transport for the 396 Path Computation Element Communication Protocol (PCEP)", 397 RFC 8253, DOI 10.17487/RFC8253, October 2017, 398 . 400 [I-D.ietf-pce-pcep-yang] 401 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 402 YANG Data Model for Path Computation Element 403 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 404 yang-11 (work in progress), March 2019. 406 Appendix A. Contributor Addresses 408 Dhruv Dhody 409 Huawei Technologies 410 Divyashree Techno Park, Whitefield 411 Bangalore, Karnataka 560066 412 India 414 EMail: dhruv.ietf@gmail.com 416 Authors' Addresses 418 Aswatnarayan Raghuram 419 AT&T 420 200 S Laurel Aevenue 421 Middletown, NJ 07748 422 USA 424 EMail: ar2521@att.com 426 Al Goddard 427 AT&T 428 200 S Laurel Aevenue 429 Middletown, NJ 07748 430 USA 432 EMail: ag6941@att.com 434 Chaitanya Yadlapalli 435 AT&T 436 200 S Laurel Aevenue 437 Middletown, NJ 07748 438 USA 440 EMail: cy098d@att.com 442 Jay Karthik 443 Cisco Systems, Inc. 444 125 High Street 445 Boston, Massachusetts 02110 446 USA 448 EMail: jakarthi@cisco.com 449 Siva Sivabalan 450 Cisco Systems, Inc. 451 2000 Innovation Drive 452 Kanata, Ontario K2K 3E8 453 Canada 455 EMail: msiva@cisco.com 457 Jon Parker 458 Cisco Systems, Inc. 459 2000 Innovation Drive 460 Kanata, Ontario K2K 3E8 461 Canada 463 EMail: jdparker@cisco.com 465 Mahendra Singh Negi 466 Huawei Technologies 467 Divyashree Techno Park, Whitefield 468 Bangalore, Karnataka 560066 469 India 471 EMail: mahendrasingh@huawei.com