RFC 8741

Ability for a Stateful Path Computation Element (PCE) to Request and Obtain Control of a Label Switched Path (LSP)

📅 published March 2020, from ietf

Ability for a Stateful PCE to Request and Obtain Control of an LSP 🎀

Okay bestie, this one is an Internet Standards Track document from the IETF, so it's officially the real deal 👑. It was published in March 2020 as RFC 8741 (ISSN 2070-1721). The authors are A. Raghuram, A. Goddard (AT&T), J. Karthik, S. Sivabalan (Cisco Systems, Inc.), and M. Negi (Huawei Technologies). It's a bit of a long one, so this is part 1 of 2 ✨

Abstract ✨

Okay so, a stateful Path Computation Element (PCE) keeps track of where the MPLS Traffic Engineering Label Switched Paths (TE LSPs) are placed 🗺️ When a PCE has stateful control over LSPs, it can tell LSP head-ends to change the attributes of those LSPs, and especially their paths. A Path Computation Client (PCC) that set up LSPs through local configuration can hand control of those LSPs over to a stateful PCE 🫶

Sometimes a stateful PCE wants to take control of locally configured LSPs that it knows about but that were never delegated to it. This document adds an extension to the Path Computation Element Communication Protocol (PCEP) so that a PCE can ask for that control 💅

Status of This Memo 📜

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8741.

Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents 🌸

1.  Introduction
2.  Terminology
  2.1.  Requirements Language
3.  LSP Control Request Flag
4.  Operation
5.  Security Considerations
6.  IANA Considerations
7.  Manageability Considerations
  7.1.  Control of Function and Policy
  7.2.  Information and Data Models
  7.3.  Liveness Detection and Monitoring
  7.4.  Verify Correct Operations
  7.5.  Requirements on Other Protocols
  7.6.  Impact on Network Operations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🦋

Okay so the "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE" spec [RFC8231] adds a bunch of extensions to PCEP [RFC5440] so you can have stateful control of Traffic Engineering Label Switched Paths (TE LSPs), both between and across PCEP sessions, in compliance with [RFC4657] 💖 It includes ways to sync LSP state between Path Computation Clients (PCCs) and PCEs, delegate control of LSPs to PCEs, and let PCEs control the timing and sequence of path computations within and across PCEP sessions. The stateful PCEP has two main network operations:

Delegation: As per [RFC8051], this is an operation that gives a PCE temporary rights to modify a subset of LSP parameters on one or more LSPs of a PCC. LSPs are delegated from a PCC to a PCE and are called "delegated" LSPs.

Revocation: As per [RFC8231], this is an operation a PCC performs on a previously delegated LSP. It takes back the rights that were granted to the PCE in the delegation operation.

For redundant stateful PCEs (Section 5.7.4 of [RFC8231]), if a PCE fails, one of the redundant PCEs might want to request control over an LSP. The redundant PCEs may use a local policy or a proprietary election mechanism to decide which PCE takes control. So we need a way for a stateful PCE to ask a PCC for control of one or more LSPs, so that a newly elected primary PCE can request the takeover 🙌

For virtualized PCEs (vPCEs) running in virtual network function (VNF) mode, as the computation load in the network goes up, a new vPCE instance could be spun up to balance the load. The PCEs could use a proprietary algorithm to decide which LSPs go to the new vPCE. So a mechanism for a PCE to request control of some LSPs is needed here too ✨

In some deployments, the operator wants to use a stateful PCE for global optimization algorithms but still wants to keep control of the LSP at the PCC. In that case, a stateful PCE could ask to take control during the global optimization and then return the delegation once it's done 🧚

Note that [RFC8231] specifies a mechanism for a PCC to delegate an orphaned LSP to another PCE. The mechanism defined in this document can be used together with [RFC8231]. In the end, it's the PCC that decides which PCE to delegate the orphaned LSP to 👑

This specification is a simple extension that lets a PCE request control of one or more LSPs from any PCC over the stateful PCEP session. The procedures for granting and giving up control of the LSPs follow [RFC8231], unless this document explicitly sets them aside 💅

2. Terminology 💜

This document uses the following terms defined in [RFC5440]:

  • PCC: Path Computation Client
  • PCE: Path Computation Element
  • PCEP: Path Computation Element communication Protocol

This document uses the following terms defined in [RFC8231]:

  • PCRpt: Path Computation State Report message
  • PCUpd: Path Computation Update Request message
  • PLSP-ID: A PCEP-specific identifier for the LSP
  • SRP: Stateful PCE Request Parameters

Readers of this document are expected to have some familiarity with [RFC8231] 🤓

2.1. Requirements Language 🔥

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. ✨

3. LSP Control Request Flag 🍓

The Stateful PCE Request Parameters (SRP) object is defined in Section 7.2 of [RFC8231], and it includes a Flags field 💖

There's a new "LSP Control Request" flag (30), also called the C flag, that gets introduced in the SRP object. In a PCUpd message, a PCE sets the C flag to 1 when it wants to gain control of LSPs. The LSPs are identified by the PLSP-ID in the LSP object that follows the SRP object. A PLSP-ID value other than 0 and 0xFFFFF identifies the LSP that the PCE is asking control of. A PLSP-ID value of 0 means the PCE is requesting control of all LSPs originating from the PCC that it wants to delegate. The C flag does nothing in other PCEP messages that carry SRP objects. In those messages the C flag MUST be set to 0 when it's sent and MUST be ignored when it's received 🙈

The C flag is ignored if the R flag [RFC8281] in the SRP object is set 🫠

4. Operation 🎀

During normal operation, a PCC that wants to delegate control of an LSP sets the Delegate (D) flag (Section 7.3 of [RFC8231]) to 1 in all PCRpt messages about that LSP. The PCE confirms the delegation by setting the D flag to 1 in all PCUpd messages about that LSP. The PCC takes control of the LSP back from the PCE by setting the D flag to 0 in PCRpt messages about that LSP. If the PCE wants to give up control of the LSP, it sets the D flag to 0 in all PCUpd messages about that LSP 🦋

If a PCE wants to gain control over an LSP, it sends a PCUpd message with the C flag set to 1 in the SRP object. The LSP the PCE is asking for is identified by the PLSP-ID in the associated LSP object. A PLSP-ID value of 0 means the PCE wants control over all LSPs originating from the PCC. An implementation of this feature needs to check for the LSP control feature (C flag set to 1) before it checks the PLSP-ID (as per [RFC8231]). The D flag and the C flag are mutually exclusive in a PCUpd message. The PCE MUST NOT send a control request for an LSP that is already delegated to it, which means if the D flag is set in the PCUpd message, then the C flag MUST NOT be set 🙅‍♀️ If a PCC gets a PCUpd message with the D flag set in the LSP object (meaning the LSP is already delegated) and the C flag is also set (meaning the PCE is making a control request), the PCC MUST ignore the C flag. A PCC can decide to delegate control of the LSP at its own discretion. If the PCC grants or denies control, it sends a PCRpt message with the D flag set to 1 or 0, respectively, following stateful PCEP [RFC8231]. If the PCC doesn't grant control, it MAY choose not to respond, and the PCE MAY choose to retry the request, preferably using an exponentially increasing timer ⏳ Also, if a PCUpd message with the C flag set arrives for a currently non-delegated LSP (the one the PCE is asking to delegate), this MUST NOT trigger the error handling specified in [RFC8231] (a PCErr with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update Request for a non-delegated LSP)) 🚫

As per [RFC8231], a PCC cannot delegate an LSP to more than one PCE at any time. If a PCE requests control of an LSP that the PCC has already delegated to another PCE, the PCC MAY ignore the request, or it MAY revoke the delegation to the first PCE before delegating it to the second. Which one it does is a matter of local policy 🤷‍♀️

It should be noted that a legacy PCC implementation that doesn't support this extension may get an LSP control request: a PCUpd message with the C flag set and the D flag unset. The legacy implementation would ignore the C flag and trigger the error condition for the D flag, as specified in [RFC8231] (that is, a PCErr with Error-type=19 (Invalid Operation) and error-value 1 (Attempted LSP Update Request for a non-delegated LSP)). Further, if the PLSP-ID value is 0, the error condition specified in [RFC8231] (that is, a PCErr with Error-type=19 (Invalid Operation) and error-value 3 (Attempted LSP Update Request for an LSP identified by an unknown PLSP-ID)) would be triggered 😭

[RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model. It also specifies how a PCE may obtain control over an orphaned LSP that was PCE-initiated. A PCE implementation can apply the mechanism described in this document alongside the ones in [RFC8281] 🌈

5. Security Considerations ✨

okay so the security stuff from [RFC8231] and [RFC8281] totally applies here too 💅 but this doc is bringing a brand new attack vector, so pay attention bestie 😭 An attacker could flood the PCC with requests to delegate ALL of its LSPs faster than the PCC can keep up, either by spoofing messages or by compromising the PCE itself. 💀 The PCC SHOULD be configured with a threshold rate for the delegation requests it gets from the PCE. If that threshold gets hit, it is RECOMMENDED to log the issue 🚨

A PCC is the ultimate arbiter of delegation, no cap 👑 As per [RFC8231], a local policy at the PCC is what influences the delegation. A PCC can also revoke the delegation at any time, so it's always got the final say 💖 A PCC need not blindly trust the control requests, and it SHOULD take local policy and other factors into consideration before honoring the request. Not blindly trusting anyone is giving main character energy 🦋

Also, a PCE may not be sure whether a PCC supports this feature at all 🙈 It would try sending a control request to a 'legacy' PCC, and that PCC would respond with an error, as described in Section 4. So the PCE only finds this out when it actually wants to take control over an LSP. A PCE might also be vulnerable to downgrade attacks if someone falsifies that error condition. Yikes 😬

As per [RFC8231], it is RECOMMENDED that these PCEP extensions only be activated on authenticated and encrypted sessions across PCEs and PCCs that belong to the same administrative authority. The way to do that is Transport Layer Security (TLS) [RFC8253], following the recommendations and best current practices in BCP 195 [RFC7525], unless [RFC8253] explicitly excludes them 🔐✨

6. IANA Considerations 🍓

IANA has allocated a code point for us in the "SRP Object Flag Field" subregistry, which lives in the "Path Computation Element Protocol (PCEP) Numbers" registry. Look at her go 🎀

              +-----+---------------------+-----------+
              | Bit | Description         | Reference |
              +=====+=====================+===========+
              | 30  | LSP Control Request | RFC 8741  |
              +-----+---------------------+-----------+

                               Table 1

7. Manageability Considerations 🌸

All of the manageability requirements and considerations from [RFC5440] and [RFC8231] apply to the PCEP extensions defined in this document 💜 On top of that, the requirements and considerations in this section apply too.

7.1. Control of Function and Policy

A PCC implementation SHOULD let the operator configure the policy rules that decide the conditions under which it honors a request to control the LSPs. That includes handling the case where an LSP control request comes in for an LSP that is currently delegated to some other PCE, which is a very real drama situation 🍿 A PCC implementation SHOULD also let the operator configure the threshold rate for the delegation requests it receives from the PCE. Further, the operator MAY be allowed to trigger the LSP control request for a particular LSP at the PCE. Lastly, a PCE implementation SHOULD let the operator configure an exponentially increasing timer to retry control requests that never got a response ⏰🫶

7.2. Information and Data Models

The PCEP YANG module [PCEP-YANG] could be extended to include a mechanism for triggering the LSP control request. Future-proofing era 🔮

7.3. Liveness Detection and Monitoring

The mechanisms in this document don't imply any new liveness detection and monitoring requirements beyond the ones already listed in [RFC5440]. Nothing new to worry about here, bestie 🌈

7.4. Verify Correct Operations

The mechanisms in this document don't imply any new operation verification requirements beyond the ones already listed in [RFC5440] and [RFC8231]. Easy 🧚

7.5. Requirements on Other Protocols

The mechanisms in this document don't imply any new requirements on other protocols. Other protocols are off the hook, lol 😂

7.6. Impact on Network Operations

The mechanisms described in [RFC5440] and [RFC8231] also apply to the PCEP extensions defined in this document. On top of that, the mechanism described here can help the operator request control of the LSPs at a particular PCE. That's iconic for operators 👑✨

8. References 📚

8.1. Normative References

8.2. Informative References

Acknowledgements 🫶

Huge thanks to Jonathan Hardwick for reminding the authors not to use suggested values in the IANA section 🙌

Thanks also to Adrian Farrel, Haomian Zheng, and Tomonori Takeda for their valuable comments 💖

Thanks to Shawn M. Emery for his Security Directorate review 🔐

Thanks to Francesca Palombini for the GENART review 🌷

And thanks to Benjamin Kaduk, Martin Vigoureux, Alvaro Retana, and Barry Leiba for the IESG reviews 👏

Contributors 💜

The following people contributed substantially to the content of this document and should be considered coauthors:

Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore 560066
Karnataka
India

Email: dhruv.ietf@gmail.com


Jon Parker
Cisco Systems, Inc.
2000 Innovation Drive
Kanata Ontario K2K 3E8
Canada

Email: jdparker@cisco.com


Chaitanya Yadlapalli
AT&T
200 S Laurel Avenue
Middletown, NJ 07748
United States of America

Email: cy098@att.com

Authors' Addresses 🦋

Aswatnarayan Raghuram
AT&T
200 S Laurel Avenue
Middletown, NJ 07748
United States of America

Email: ar2521@att.com


Al Goddard
AT&T
200 S Laurel Avenue
Middletown, NJ 07748
United States of America

Email: ag6941@att.com


Jay Karthik
Cisco Systems, Inc.
125 High Street
Boston, Massachusetts 02110
United States of America

Email: jakarthi@cisco.com


Siva Sivabalan
Cisco Systems, Inc.
2000 Innovation Drive
Kanata Ontario K2K 3E8
Canada

Email: msiva@cisco.com


Mahendra Singh Negi
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore 560066
Karnataka
India

Email: mahend.ietf@gmail.com
📦 where this page comes from