RFC 8281
Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model
Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model 🦋
- Request for Comments: 8281 🎀
- Category: Standards Track 💅
- Date: December 2017 🌸
- ISSN: 2070-1721
- Authors: E. Crabbe (Individual Contributor), I. Minei (Google, Inc.), S. Sivabalan (Cisco Systems, Inc.), R. Varga (Pantheon Technologies SRO) 🫶
- Obsoletes / Updates: Nothing! This header doesn't list any RFC that it obsoletes or updates. 🧚
It's an IETF document, so it's been through the usual public review process, and it's a Standards Track spec. Let's get into it. 💖
Abstract
Okay so PCEP (the Path Computation Element Communication Protocol) is the protocol that lets Path Computation Elements (PCEs) do path computations whenever a Path Computation Client (PCC) asks them to. 🧠
The stateful PCE extensions are where things get spicy ✨. They give you active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) over PCEP, in a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This doc is all about how PCE-initiated LSPs get created and deleted under that stateful PCE model. Iconic. 👑
Status of This Memo
This is an Internet Standards Track document. 🌈
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841 📚.
Info about this doc's current status, any errata, and how to send feedback lives at https://www.rfc-editor.org/info/rfc8281 🔗.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. 🦋
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read these, bestie, because they explain your rights and restrictions for this document. 🙈
If you pull Code Components out of this document, they have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as described in the Simplified BSD License. 💜
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
3. Architectural Overview . . . . . . . . . . . . . . . . . . . 5
3.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Operation Overview . . . . . . . . . . . . . . . . . . . 6
4. Support of PCE-Initiated LSPs . . . . . . . . . . . . . . . . 7
4.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 8
5. PCE-Initiated LSP Instantiation and Deletion . . . . . . . . 8
5.1. The LSP Initiate Request . . . . . . . . . . . . . . . . 8
5.2. The R Flag in the SRP Object . . . . . . . . . . . . . . 10
5.3. LSP Instantiation . . . . . . . . . . . . . . . . . . . . 10
5.3.1. The Create Flag . . . . . . . . . . . . . . . . . . . 12
5.3.2. The SPEAKER-ENTITY-ID TLV . . . . . . . . . . . . . . 13
5.4. LSP Deletion . . . . . . . . . . . . . . . . . . . . . . 13
6. LSP Delegation and Cleanup . . . . . . . . . . . . . . . . . 14
7. LSP State Synchronization . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 15
8.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 15
8.3. SRP object . . . . . . . . . . . . . . . . . . . . . . . 16
8.4. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 16
8.5. PCEP-Error Object . . . . . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9.1. Malicious PCE . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Malicious PCC . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 201. Introduction 🌸
Okay, so [RFC5440] is the one that describes PCEP! PCEP is the chat between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between PCE and PCE. It's how you get computation of Multiprotocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP) characteristics. 🧚
[RFC8231] adds a bunch of extensions to PCEP so you can do stateful control of TE LSPs, both between and across PCEP sessions, following [RFC4657]. It includes:
- mechanisms to effect LSP State Synchronization between PCCs and PCEs ✨
- delegation of control of LSPs to PCEs 👑
- PCE control of timing and sequence of path computations within and across PCEP sessions 💅
Its whole focus is a model where LSPs are configured on the PCC, and control over them gets delegated to the PCE. Very organized, very structured. 🍓
This document is the glow-up 🌈. It covers the setup, maintenance, and teardown of PCE-initiated LSPs under the stateful PCE model. The best part is you don't need any local configuration on the PCC, so you get a dynamic network that's centrally controlled and deployed. Main character energy for real. 🦋
2. Terminology 💖
This doc uses the following terms from [RFC5440]: PCC, PCE, and PCEP Peer. 🫶
It also uses these terms from [RFC8051]: Stateful PCE and Delegation. 🎀
And these ones from [RFC8231]: Redelegation Timeout Interval, State Timeout Interval, LSP State Report, and LSP Update Request. 🧠
The following term is defined in this document:
- PCE-initiated LSP: LSP that is instantiated as a result of a request from the PCE. ✨
Message formats in this doc are specified using Routing Backus-Naur Form (RBNF) encoding, as described in [RFC5511]. 🔥
2.1. Requirements Language
Here's where the key-word rules live, bestie, so pay attention 🙈. 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. Lowercase versions don't count as key words. Not me being extra, it's just how the spec works 💅.
3. Architectural Overview 🧚
3.1. Motivation
Here's the tea ☕. [RFC8231] gives you active control over LSPs that are locally configured on the PCC. That model leans on the Label Edge Router (LER) taking an active role in delegating its locally configured LSPs to the PCE. It's a great fit when LSP placement is fairly static. 🍓
But when LSP placement has to change in response to application demands, it's useful to support dynamic creation and teardown of LSPs. That's where it gets iconic 👑. The ability for a PCE to trigger creation of LSPs on demand fits right into a controller-based network architecture, where the controller's intelligence decides when and where to set up paths. 🦋
A possible use case is a software-defined network, where applications request network resources and paths from the network infrastructure. For example, an application can request a path with certain constraints between two Label Switching Routers (LSRs) by contacting the PCE. The PCE computes a path that satisfies those constraints, then tells the head end LSR to instantiate and signal it. When the application no longer needs the path, the PCE can request its teardown. Clean, efficient, no drama 💅.
Another use case is dynamically adjusting aggregate bandwidth between two points in the network using multiple LSPs. This is very similar to auto-bandwidth, except it lets you provide the desired capacity through multiple LSPs. That's a big upgrade, because it fixes two of the limitations auto-bandwidth can run into: 1) growing the capacity between the endpoints beyond the capacity of individual links in the path, and 2) achieving good bin packing by using several small LSPs instead of a single large one 📦. The number of LSPs varies with demand, and LSPs get created and deleted dynamically to meet the bandwidth requirements 🌸.
Another use case is demand engineering. A PCE that can see both the network state and the demand matrix can anticipate and optimize how traffic gets distributed across the infrastructure 🧠. Those optimizations may require creating new paths across the infrastructure, so yeah, it's giving planning-ahead energy 🫶.
3.2. Operation Overview ✨
okay bestie, so this section is where the magic starts 🦋 this doc adds a brand new I flag to the STATEFUL-PCE-CAPABILITY TLV so a sender can say "yep, I support PCE-initiated LSPs" 💅 (more on that in Section 4.1). a PCC or PCE sets this flag in the Open message during the PCEP initialization phase to show it can do the procedures in this doc 🎀
there's also a brand new PCEP message called the LSP Initiate Request (PCInitiate) 🌸 a PCE can send it to a PCC to ask for an LSP to be created or deleted. when to actually spin one up or tear one down? not this doc's problem 🙈 that's out of scope, periodt
so here's the vibe for creating one 💖 the PCE sends a PCInitiate message to the PCC asking for a new LSP. the PCC builds it using the attributes the PCE gave, and fills in its own local values for anything unspecified ✨ then the PCC generates a Path Computation State Report (PCRpt) for the LSP. this PCRpt carries a newly assigned PLSP-ID 🧚 and delegates the LSP to the PCE via the Delegate flag in the LSP object 👑
the PCE can update the LSP later by sending Path Computation Update Request (PCUpd) messages 🦋 after that, the PCRpt and PCUpd messages for that LSP both carry the PCC-assigned PLSP-ID, which uniquely identifies the LSP 💜 deets in Section 5.3 bestie
and for deleting 😭 the PCE sends a PCInitiate message to request a deletion. to say "this is a delete," this doc defines a new R flag in the Stateful PCE Request Parameter (SRP) object inside that PCInitiate message 💀 (see Section 5.2). the PCC removes the LSP and sends a PCRpt for the removed state. more details in Section 5.4 🫶
Figure 1 shows the whole life cycle, it's literally so clean 🌈
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|<--PCInitiate-------------------| (Initiate LSP)
| |
|---PCRpt, PLSP_ID=1, D=1------->| (Confirm initiation)
| . |
| . |
| |
|<--PCUpd, PLSP_ID=1-------------| (Update LSP)
| |
|---PCRpt, PLSP_ID=1, D=1------->| (Confirm update)
| . |
| . |
| |
|<--PCInitiate, PLSP_ID=1, R=1---| (Delete LSP)
| |
|---PCRpt, PLSP_ID=1, R=1------->| (Confirm delete)
Figure 1: PCE-Initiated LSP Life Cycle4. Support of PCE-Initiated LSPs 🌈
okay so how does a PCEP speaker even say it can do PCE-initiated LSPs? 🤔 during the PCEP initialization phase, duh 💅 when the PCEP session gets created, it sends an Open message with an OPEN object that has the STATEFUL-PCE-CAPABILITY TLV (defined in [RFC8231]) 🎀 and this doc adds a new flag to that TLV, the I (LSP-INSTANTIATION-CAPABILITY) flag 💖 it says "I support instantiating PCE-initiated LSPs" ✨
a PCE can only initiate LSPs for PCCs that advertised this capability 🙈 and a PCC only follows the procedures in this doc on sessions where the PCE advertised the I flag 👑 no cap, it's a two-way handshake bestie 🫶
4.1. STATEFUL-PCE-CAPABILITY TLV 🍓
the format of the STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231], and it's copied here so you can see the new I flag 🦋
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length=4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |I|S|U|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+
Figure 2: STATEFUL-PCE-CAPABILITY TLV Formata new flag is defined to show the sender supports LSP instantiation by a PCE 💜
I (LSP-INSTANTIATION-CAPABILITY -- 1 bit): if it's set to 1 by a PCC, the I flag means that PCC allows a PCE to instantiate an LSP ✨ if it's set to 1 by a PCE, the I flag means that PCE supports instantiating LSPs 🌸 the LSP-INSTANTIATION-CAPABILITY flag MUST be set by both the PCC and PCE in order to enable PCE-initiated LSP instantiation 💅
5. PCE-Initiated LSP Instantiation and Deletion 👑
so to start an LSP, a PCE sends a PCInitiate message to a PCC 🦋 the message format, objects, and TLVs get covered separately below for the creation case and the deletion case 🌈
5.1. The LSP Initiate Request 🎀
an LSP Initiate Request (PCInitiate) message is a PCEP message a PCE sends to a PCC to trigger LSP instantiation or deletion 💖 the Message-Type field of the PCEP common header for PCInitiate is set to 12 🧚 the PCInitiate message MUST include the SRP and the LSP objects, and it MAY contain other objects too (more on that later in this section) 🫶
the format of a PCInitiate message looks like this 💀
<PCInitiate Message> ::= <Common Header>
<PCE-initiated-lsp-list>
Where:
<Common Header> is defined in RFC 5440
<PCE-initiated-lsp-list> ::= <PCE-initiated-lsp-request>
[<PCE-initiated-lsp-list>]
<PCE-initiated-lsp-request> ::= (<PCE-initiated-lsp-instantiation>|
<PCE-initiated-lsp-deletion>)
<PCE-initiated-lsp-instantiation> ::= <SRP>
<LSP>
[<END-POINTS>]
<ERO>
[<attribute-list>]
<PCE-initiated-lsp-deletion> ::= <SRP>
<LSP>
Where:
<attribute-list> is defined in RFC 5440 and extended by
PCEP extensions.the LSP object is defined in [RFC8231] 🍓 and the END-POINTS and Explicit Route Objects (EROs) are defined in [RFC5440] ✨
the SRP object is defined in [RFC8231] 🌸 it has an SRP-ID-number that's unique within a PCEP session 💜 the PCE increments the last-used SRP-ID-number before it sends each PCInitiate message 🦋 and the PCC MUST echo the SRP-ID-number in the PCEP Error (PCErr) and PCRpt messages it sends as a result of the PCInitiate 🫶 that's how the PCE correlates them with the matching PCInitiate, bestie 🧚
5.2. The R Flag in the SRP Object 💅
the format of the SRP object is defined in [RFC8231] and copied here so you can see the new R flag 🌈
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags |R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRP-ID-number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Optional TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: The SRP Object Formata new flag is defined to show a delete operation initiated by the PCE 💖
R (LSP-REMOVE -- 1 bit): if it's set to 0, it means a request to create an LSP ✨ if it's set to 1, it means a request to remove an LSP 😭
5.3. LSP Instantiation ✨
okay so instantiating an LSP is basically the PCE saying "hey PCC, build this for me pls" 💖 It happens by sending a PCInitiate message, and the LSP gets set up with RSVP-TE 🎀 Other setup methods? Outside the scope of this doc, bestie, so we're leaving them alone 🙈
A PCInitiate message that's being used to instantiate an LSP MUST contain an LSP object with the reserved PLSP-ID 0 🧚 That LSP object MUST also include the SYMBOLIC-PATH-NAME TLV, which is how the PCC-assigned PLSP-ID gets matched up with the LSP. It's giving matchmaker energy 💘
That same PCInitiate MUST contain an ERO for the LSP 🛣️
Now, for an RSVP-signaled instantiation request, the destination address might be needed 👀 The PCC MAY work it out from a provided object (like the ERO) or from a local decision. Or the END-POINTS object MAY be included to spell out the destination addresses for the RSVP-TE signaling, so nobody has to guess 🫶 The source address MUST either be specified, or left for the PCC to choose by setting it to "0.0.0.0" (if the destination is an IPv4 address) or "::" (if the destination is an IPv6 address). Choose your fighter 💅
The PCE MAY include various attributes as per [RFC5440]. The PCC MUST use these values in the LSP instantiation, and it uses local values for any unspecified parameters 🍓 After the LSP is set up, the PCC MUST send a PCRpt to the PCE that reflects these values. The SRP object in that PCRpt MUST echo the value of the PCInitiate message that triggered the setup. Any LSP that got instantiated because of a PCInitiate MUST have the Create flag (Section 5.3.1) set in its LSP object ✨
Now the error situations, because even the best protocols get a little messy 💀
- If the PCC gets a
PCInitiatewith a non-zero PLSP-ID and the R flag in the SRP object set to zero, it MUST send a PCErr withError-type=19 (Invalid Operation)andError-value=8 (Non-zero PLSP-ID in the LSP Initiate Request)🙅♀️ - If the PCC gets a
PCInitiatewithout an ERO and the R flag in the SRP object set to zero, it MUST send a PCErr withError-type=6 (Mandatory Object missing)andError-value=9 (ERO object missing)😭 - If the PCC gets a
PCInitiatewithout a SYMBOLIC-PATH-NAME TLV, it MUST send a PCErr withError-type=10 (Reception of an invalid object)andError-value=8 (SYMBOLIC-PATH-NAME TLV missing)🙈
The PCE MUST NOT give a symbolic path name that clashes with the symbolic path name of any existing LSP in the PCC. (Existing LSPs might be statically configured, or initiated by another PCE. Not me being dramatic, it's just a rule 🌸) If there's a clash, the PCC MUST send a PCErr with Error-type=23 (Bad Parameter value) and Error-value=1 (SYMBOLIC-PATH-NAME in use). The only exception is for LSPs whose State Timeout Interval timer is running (see Section 6) ⏳
If the PCC decides the LSP parameters in the PCInitiate are unacceptable, it MUST send a PCErr with Error-type=24 (PCE instantiation error) and Error-value=1 (Unacceptable instantiation parameters) 🥺 If the PCC runs into an internal error while processing the PCInitiate, it MUST send a PCErr with Error-type=24 (PCE instantiation error) and Error-value=2 (Internal error) 🔥
A PCC MUST relay any errors it hits while setting up a PCE-initiated LSP back to the PCE, by sending a PCErr with Error-type=24 (PCE instantiation error) and Error-value=3 (Signaling error) 📣 That PCErr MUST echo the SRP-ID-number of the PCInitiate. The PCEP-ERROR object SHOULD include the RSVP_ERROR_SPEC TLV (if an RSVP ERROR_SPEC object was returned to the PCC by a downstream node) 🧾
Once the LSP is up, RSVP signaling errors get reported in PCRpt messages instead, as described in [RFC8231] 📬
When the LSP instantiation finishes successfully, the PCC MUST send a PCRpt 🎉 The LSP object in that message MUST contain a non-zero PLSP-ID that uniquely identifies the LSP within this PCC, and it MUST have the Create flag (Section 5.3.1) and the Delegate flag set. The SRP object MUST contain an SRP-ID-number that echoes the value from the PCInitiate that triggered the setup. The PCRpt MUST include the attributes the PCC used to instantiate the LSP 💜
A PCC SHOULD be able to put a cap on either the number of LSPs or the percentage of resources allocated to honour PCE-initiated LSP requests 🧢 As soon as that limit is hit, the PCC MUST send a PCErr with Error-type=19 (Invalid Operation) and Error-value=6 (PCE-initiated LSP limit reached), and it's free to drop any incoming PCInitiate messages without any additional processing. Boundaries, babe 🚧
The PCE SHOULD be able to limit either the number of PCInitiate messages pending for a particular PCC, or how long it waits for a response (positive or negative) to a PCInitiate from a PCC. If that limit is reached, it MAY take further action, such as closing the session or removing all its LSPs 🌈
5.3.1. The Create Flag
The LSP object is defined in [RFC8231] and included here for easy reference, with the addition of the new Create (C) flag 🦋
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PLSP-ID |Flags |C| O |A|R|S|D|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// TLVs //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: The LSP Object Format 🖼️
Here's the new bit: the C flag. On a PCRpt message, the C flag set to 1 tells you that this LSP was created via a PCInitiate message 🙌 The C flag MUST be set to 1 on each PCRpt message for the LSP's entire existence, no exceptions. This is what lets PCEs know which LSPs they initiated themselves, which is a detail that would otherwise only be known by the PCC and the PCE that started them 🕵️♀️
5.3.2. The SPEAKER-ENTITY-ID TLV
The optional SPEAKER-ENTITY-ID TLV, defined in [RFC8232], MAY be included in the LSP object of a PCRpt as an optional TLV for LSPs where the C flag is 1 💁♀️ It identifies the PCE that started the creation of the LSP on all PCEP sessions, which is info that would otherwise only be known by the PCC and the PCE that initiated the LSP.
If this TLV shows up in a PCRpt for an LSP where the C flag is 0, that LSP MUST be ignored, and the PCE MUST send a PCErr with Error-type=23 (Bad parameter value) and Error-value=2 (Speaker identity included for an LSP that is not PCE initiated). Not it 🙅♀️
5.4. LSP Deletion
A PCE can start the removal of a PCE-initiated LSP by sending a PCInitiate with an LSP object carrying the PLSP-ID of the LSP to be removed, plus an SRP object with the R flag set (see Section 5.2) 🗑️ A PLSP-ID of zero removes all LSPs that have the C flag set to 1 (in their LSP object) and are delegated to the PCE. Whole-clean-slate energy 🧹
If the PLSP-ID is unknown, the PCC MUST send a PCErr with Error-type=19 (Invalid Operation) and Error-value=3 (Unknown PLSP-ID) [RFC8231] 🤷♀️
If the PLSP-ID in the PCInitiate is not delegated to the PCE, the PCC MUST send a PCErr with Error-type=19 (Invalid operation) and Error-value=1 (LSP is not delegated) [RFC8231] 🚫
If the PLSP-ID in the PCInitiate was not created by a PCE, the PCC MUST send a PCErr with Error-type=19 (Invalid operation) and Error-value=9 (LSP is not PCE initiated) 🙈
After the LSP is removed, the PCC MUST send a PCRpt as described in [RFC8231]. The SRP object in that PCRpt MUST include the SRP-ID-number from the PCInitiate that triggered the removal, and the R flag in the SRP object MUST be set 💖
6. LSP Delegation and Cleanup 🧼
The PCC MUST delegate PCE-initiated LSPs to the PCE as soon as they're instantiated 🎀 The PCC MUST also set the delegation bit to 1 in the PCRpt that includes the assigned PLSP-ID.
The PCC MUST NOT revoke delegation for a PCE-initiated LSP on an active PCEP session. That means every PCRpt going from the PCC to the PCE that owns the delegation MUST have the delegation bit set to 1 🔒 If the owning PCE gets a PCRpt with the delegation bit set to 0, it MUST send a PCErr with Error-type=19 (Invalid Operation) and Error-value=7 (Delegation for PCE-initiated LSP cannot be revoked). The PCE MAY react further by closing the session 💀
Control over a PCE-initiated LSP can go back to the PCC in two ways 🔄 A PCE MAY return a delegation to the PCC so the LSP can be transferred between PCEs. Or, the PCC takes control of an LSP if the PCEP session it was delegated on fails and the Redelegation Timeout Interval timer expires. In both cases the LSP becomes an orphan until the State Timeout Interval timer expires [RFC8231] 👻
The PCC MAY try to redelegate an orphaned LSP by following the procedures of [RFC8231] 🔁 Or, if the orphaned LSP was PCE-initiated, a PCE MAY take control of it like this:
A PCE (either the original one or one of its backups) sends a PCInitiate that includes just the SRP and LSP objects, and carries the PLSP-ID of the LSP it wants to take control of 🫴 If the PCC gets a PCInitiate with a PLSP-ID pointing to an orphaned PCE-initiated LSP, it MUST redelegate that LSP to the PCE. Any other non-zero PLSP-ID MUST result in a PCErr being generated using the rules in Section 5.4. The State Timeout Interval timer for the LSP is stopped once the redelegation happens. After getting control of the LSP, the PCE may remove it using the procedures in this document 🥳
The State Timeout Interval timer is the reason a PCE crash doesn't cause automatic, immediate disruption for services using PCE-initiated LSPs 🛟 These LSPs aren't removed right away when the PCE fails. Instead, they get cleaned up when this timer expires, which allows network cleanup without any manual intervention. The PCC MUST support removing PCE-initiated LSPs as one of the behaviours applied when the State Timeout Interval timer expires 🧹 That behaviour MUST be picked based on local policy, and it can end up as either LSP removal or reverting to operator-defined default parameters.
7. LSP State Synchronization 🔄
LSP State Synchronization procedures are described in Section 5.6 of [RFC8231] 📖 During State Synchronization, a PCC reports the state of its LSPs to the PCE using PCRpt messages, and it sets the SYNC flag in the LSP object. For PCE-initiated LSPs, the PCC MUST also set the Create flag in the LSP object, and it MAY include the SPEAKER-ENTITY-ID TLV identifying the PCE that requested the LSP creation 🫶
At the end of State Synchronization, the PCE SHOULD send a PCInitiate to initiate any missing LSPs and/or remove any LSPs that aren't wanted 🧐 Sometimes, depending on the deployment, it might be better for the PCE not to send this PCInitiate right away, or at all. For example, the PCC might be a slow device, or the operator might prefer not to disrupt active flows 🌸
8. IANA Considerations 🎀
As detailed below, IANA has allocated code points for the protocol elements defined in this document 💅
8.1. PCEP Messages ✨
okay so IANA registered this message type in the "PCEP Messages" subregistry of the PCEP Numbers registry 💅 fun fact: it was first called "Initiate" during early allocation, and then it got renamed, so the table below shows the final version 🦋
Value Meaning Reference
----- -------------------- -------------
12 LSP Initiate Request RFC 82818.2. LSP Object 🎀
so [RFC8231] already defines the LSP object, and per that RFC, IANA made a registry to manage its Flag field 🌸 IANA then grabbed a brand new bit in the "LSP Object Flag Field" subregistry, and it's giving main character energy:
Bit Description Reference
--- ----------- -------------
4 Create RFC 82818.3. SRP object 💜
IANA made a whole new subregistry called "SRP Object Flag Field", living inside the "Path Computation Element Protocol (PCEP) Numbers" registry, to keep track of the Flag field of the SRP object 🧚 new values get assigned by Standards Action [RFC8126]. Each bit is tracked with three qualities: bit number (counting from bit 0 as the most significant bit), description, and defining RFC.
this document defines the following values, and yes bit 31 is literally the star of the show 👑
Bit Description Reference
--- ----------- -------------
31 LSP-Remove RFC 82818.4. STATEFUL-PCE-CAPABILITY TLV 🍓
[RFC8231] defines the STATEFUL-PCE-CAPABILITY TLV, and per that RFC, IANA set up a registry for its Flag field 🫶 IANA then allocated a new bit in the STATEFUL-PCE-CAPABILITY TLV Flag Field registry, and it looks like this:
Bit Description Reference
--- -------------------------------- -------------
29 LSP-INSTANTIATION-CAPABILITY (I) RFC 82818.5. PCEP-Error Object 🙈
IANA registered these error types and error values in the "PCEP-ERROR Object Error Types and Values" subregistry of the PCEP Numbers registry. Here's the whole list, exactly as it's written, because these codes are a big deal ✨
Error-Type Meaning
---------- --------------
10 Reception of an invalid object
Error-value=8: SYMBOLIC-PATH-NAME TLV missing
19 Invalid Operation
Error-value=6: PCE-initiated LSP limit reached
Error-value=7: Delegation for PCE-initiated LSP cannot
be revoked
Error-value=8: Non-zero PLSP-ID in LSP Initiate Request
Error-value=9: LSP is not PCE initiated
Error-value=10: PCE-initiated operation-frequency limit
reached
23 Bad parameter value
Error-value=1: SYMBOLIC-PATH-NAME in use
Error-value=2: Speaker identity included for an LSP
that is not PCE initiated
24 LSP instantiation error
Error-value=1: Unacceptable instantiation parameters
Error-value=2: Internal error
Error-value=3: Signaling error9. Security Considerations 🚨
okay bestie, this part is SERIOUS 😭 the security considerations from [RFC8231] apply to everything in this document, no exceptions 🔥 on top of that, there's a whole new risk to think about: a malicious PCE 💀
9.1. Malicious PCE 👿
the LSP instantiation mechanism in this document lets a PCE create state on the PCC and all throughout the network 😱 that means it opens up a brand new attack vector: an attacker could flood the PCC with LSP instantiation requests and drain network and LSR resources, either by spoofing messages or by compromising the PCE itself. unhinged, right? 💀
a PCC can protect itself by putting a limit on either the number of LSPs or the percentage of resources allocated to honor PCE-initiated LSP requests 🛡️ the second that limit is reached, the PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=6 (PCE-initiated LSP limit reached), and it's free to drop any incoming PCInitiate messages for LSP initiation without doing any extra processing 🫠
rapid flaps triggered by the PCE can be an attack vector too, so watch out 👀
a PCC can protect itself from that by putting a limit on how many flaps per unit of time it lets a PCE generate 🧱 once that limit is hit, a PCC MUST send a PCErr message with Error-type=19 (Invalid Operation) and Error-value=10 (PCE-initiated operation-frequency limit reached), and it's free to treat the session as having reached the limit in terms of resources allocated to honor PCE-initiated LSP requests, either permanently or for a locally-defined cool-off period ❄️
9.2. Malicious PCC 🕵️
the LSP instantiation mechanism here requires the PCE to keep state for the LSPs it instantiates, and it relies on the PCC responding (with either a state report or an error message) to requests for LSP instantiation 🥺 a malicious PCC, or one that has hit the limit on PCE-initiated LSPs, can just ignore PCE requests and chew through PCE resources. rude 😤
so a PCE can protect itself by limiting the number of pending requests or by setting a timeout 🕰️ and it MAY take further action, like closing the session or removing all the LSPs it initiated 🔒
10. References 📚
10.1. Normative References 💖
these are the ones you absolutely need to read, no skipping 🫶
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol
Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
Computation Element Communication Protocol (PCEP)
Extensions for Stateful PCE", RFC 8231,
DOI 10.17487/RFC8231, September 2017,
<https://www.rfc-editor.org/info/rfc8231>.
[RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X.,
and D. Dhody, "Optimizations of Label Switched Path State
Synchronization Procedures for a Stateful PCE", RFC 8232,
DOI 10.17487/RFC8232, September 2017,
<https://www.rfc-editor.org/info/rfc8232>.10.2. Informative References 🌈
these ones are extra reading if you're curious 🧚
[RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol Generic
Requirements", RFC 4657, DOI 10.17487/RFC4657, September
2006, <https://www.rfc-editor.org/info/rfc4657>.
[RFC8051] Zhang, X., Ed. and I. Minei, Ed., "Applicability of a
Stateful Path Computation Element (PCE)", RFC 8051,
DOI 10.17487/RFC8051, January 2017,
<https://www.rfc-editor.org/info/rfc8051>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.Acknowledgments 🫶
huge shoutout to Jan Medved, Ambrose Kwong, Ramon Casellas, Cyril Margaria, Dhruv Dhody, Raveendra Trovi, and Jon Hardwick for their contributions to this document 💖 you're all iconic ✨
Authors' Addresses 🎀
Edward Crabbe
Individual Contributor
Email: edward.crabbe@gmail.com
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: inaminei@google.com
Siva Sivabalan
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Email: msiva@cisco.com
Robert Varga
Pantheon Technologies SRO
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.varga@pantheon.tech📦 where this page comes from
- ietf: rfc8281 2017-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms