RFC 8232
Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE
RFC 8232: Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE 💖
Okay bestie, let's start with the basics 🎀 This one is from the IETF (Internet Engineering Task Force), it's numbered RFC 8232, and it's a Standards Track document, so it's an actual official spec and not just a vibe. It came out in September 2017 and has ISSN 2070-1721. The authors are E. Crabbe (Oracle), I. Minei (Google, Inc.), J. Medved (Cisco Systems, Inc.), R. Varga (Pantheon Technologies SRO), X. Zhang, and D. Dhody (Huawei Technologies). Also, the title block doesn't say it obsoletes or updates any other documents 🧚
Abstract ✨
So a stateful Path Computation Element (PCE) is giving main character energy 👑 It doesn't just know what the network's Interior Gateway Protocol (IGP) tells it. It also knows every active path and the resources they've reserved, which lets it compute constrained paths by looking at each Label Switched Path (LSP) and how they all interact 💅 That means the PCE needs a State Synchronization mechanism with the network, with the Path Computation Clients (PCCs), and with other cooperating PCEs. The basic version of that mechanism lives in the stateful PCE spec. This doc is all about the motivation for making that base procedure better, and it lays out the required Path Computation Element Communication Protocol (PCEP) extensions 🦋
Status of This Memo 📜
This is an Internet Standards Track document 🌸
It's a product of the IETF, and it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🫶
For the current status, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8232 💌
Copyright Notice ⚖️
Copyright (c) 2017 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) as they stand on the date this document was published. Please actually read these, because they spell out your rights and restrictions for this doc 🙈 Any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🍓
Table of Contents 🗺️
1. Introduction ....................................................4
1.1. Requirements Language ......................................4
2. Terminology .....................................................5
3. State Synchronization Avoidance .................................5
3.1. Motivation .................................................5
3.2. State Synchronization Avoidance Procedure ..................5
3.2.1. IP Address Change during Session Re-establishment ..10
3.3. PCEP Extensions ...........................................11
3.3.1. LSP-DB Version Number TLV ..........................11
3.3.2. Speaker Entity Identifier TLV ......................12
4. Incremental State Synchronization ..............................13
4.1. Motivation ................................................13
4.2. Incremental Synchronization Procedure .....................14
5. PCE-Triggered Initial Synchronization ..........................17
5.1. Motivation ................................................17
5.2. PCE-Triggered Initial State Synchronization Procedure .....18
6. PCE-Triggered Resynchronization ................................19
6.1. Motivation ................................................19
6.2. PCE-Triggered State Resynchronization Procedure ...........19
7. Advertising Support of Synchronization Optimizations ...........20
8. IANA Considerations ............................................21
8.1. PCEP-Error Object .........................................21
8.2. PCEP TLV Type Indicators ..................................22
8.3. STATEFUL-PCE-CAPABILITY TLV ...............................22
9. Manageability Considerations ...................................22
9.1. Control of Function and Policy ............................22
9.2. Information and Data Models ...............................22
9.3. Liveness Detection and Monitoring .........................23
9.4. Verify Correct Operations .................................23
9.5. Requirements on Other Protocols ...........................23
9.6. Impact on Network Operations ..............................23
10. Security Considerations .......................................23
11. References ....................................................24
11.1. Normative References .....................................24
11.2. Informative References ...................................24
Acknowledgments ...................................................25
Contributors ......................................................25
Authors' Addresses ................................................261. Introduction ✨
The Path Computation Element Communication Protocol (PCEP) is the thing that gives Path Computation Elements (PCEs) a way to do path computations whenever Path Computation Client (PCC) requests come in 💖
[RFC8231] describes a set of PCEP extensions for stateful control 🦋 A stateful PCE can see not only what the network's Interior Gateway Protocol (IGP) carries, but also the active paths and their reserved resources, which it uses for its computations. That extra state is what lets the PCE compute constrained paths by considering individual LSPs and how they interact. This needs a State Synchronization mechanism between the PCE and the network, between the PCE and the PCC, and between cooperating PCEs. [RFC8231] covers the basic State Synchronization mechanism. This document specifies the following optimizations for State Synchronization, along with the matching PCEP procedures and extensions 🧚
- State Synchronization Avoidance: skip State Synchronization if the state survived and didn't change during a session restart. (See Section 3.)
- Incremental State Synchronization: do incremental (delta) State Synchronization when that's possible. (See Section 4.)
- PCE-Triggered Initial Synchronization: let the PCE control the timing of the initial State Synchronization. (See Section 5.)
- PCE-Triggered Resynchronization: let the PCE resynchronize the state as a sanity check. (See Section 6.)
Each synchronization optimization capability gets advertised during the PCEP initialization phase 📣 Check out Section 7 for the new flags this document defines. Each flag's handling is explained in its relevant section 🌈
1.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 🔥 So if you see them in ALL CAPS, that's the official spec talking. Lowercase is just regular English 💅
2. Terminology 📚
This document uses the following terms defined in [RFC5440]: PCC, PCE, and PCEP Peer 🎀
This document uses the following terms defined in [RFC8051]: Stateful PCE, Delegation, and LSP State Database (LSP-DB) 🍓
This document uses the following terms defined in [RFC8231]: Redelegation Timeout Interval, LSP State Report, and LSP Update Request 🫶
Within this document, when a PCE is describing PCE-PCE communications, the requesting PCE fills the role of a PCC as usual 🧚
3. State Synchronization Avoidance 🦋
3.1. Motivation 🌸
Okay so the whole point of State Synchronization is to give a stateful PCE a checkpoint-in-time copy of a PCC's LSP state 📸 It happens right after the initialization phase [RFC5440], and [RFC8231] is where the basic mechanism is described 💜
Here's the thing though: State Synchronization isn't always needed after a PCEP session restart 🙈 If the state of both PCEP peers didn't change, the synchronization phase may be skipped. That's giant savings, both in control-plane data exchanges and in how fast the stateful PCE gets fully operational again ⭐ It's giving efficiency, bestie 👑
3.2. State Synchronization Avoidance Procedure ✨
Okay bestie, so State Synchronization MAY be skipped after a PCEP session restart, but only if the state of both PCEP peers didn't change in the window right before the session re-initializes 🦋. To know that, the PCE and the PCC both have to exchange and keep track of state during normal operation. The trick is a version counter called the LSP-DB Version Number, which tracks changes to the LSP-DB 🔢.
The INCLUDE-DB-VERSION (S) bit in the STATEFUL-PCE-CAPABILITY TLV (Section 7) gets advertised on a PCEP session during startup. It tells the other side that the LSP-DB Version Number should be included whenever LSPs are reported to the PCE 💌. The LSP-DB Version Number lives in the LSP-DB-VERSION TLV (see Section 3.3.1), and the PCC owns it 👑. It MUST be bumped by 1 for each successive change in the PCC's LSP-DB. The LSP-DB Version Number MUST start at 1 and may wrap around 🔄.
Values 0 and 0xFFFFFFFFFFFFFFFF are reserved 🚫. If either of those two values gets used during LSP State (re)Synchronization, the PCE speaker that receives it MUST send back a PCErr with Error-type=20 and Error-value=6 'Received an invalid LSP-DB Version Number', and then close the PCEP session 💀. Stuff that counts as a change to the local LSP-DB includes an LSP operational state change, delegating an LSP, removing or setting up an LSP, or changing any LSP attribute that would trigger a report to the PCE 📝.
If the include LSP-DB version capability is enabled, a PCC MUST increment its LSP-DB Version Number when the 'Redelegation Timeout Interval' timer expires. For how the Redelegation Timeout Interval gets used, see [RFC8231] ⏱️.
If both PCEP speakers set the S flag in the OPEN object's STATEFUL-PCE-CAPABILITY TLV to 1, the PCC MUST include the LSP-DB-VERSION TLV in each LSP object of the Path Computation LSP State Report (PCRpt) message 🎀. If the LSP-DB-VERSION TLV goes missing from a PCRpt message, the PCE will generate an error with Error-type=6 (Mandatory Object missing) and Error-value=12 'LSP-DB-VERSION TLV missing', and close the session 🙈. And if the include LSP-DB version capability was never enabled on a PCEP session, the PCC SHOULD NOT put the LSP-DB-VERSION TLV in the LSP Object. If one shows up anyway, the PCE MUST ignore it 🫶.
If a PCE's LSP-DB survived a PCEP session restart, the PCE puts the LSP-DB-VERSION TLV in its OPEN object, and that TLV holds the last LSP-DB Version Number it got on an LSP State Report from the PCC in the previous session 🧠. If a PCC's LSP-DB survived the restart, the PCC puts the LSP-DB-VERSION TLV in its OPEN object with its latest LSP-DB Version Number 📦. But if a PCEP speaker's LSP-DB did not survive the restart, or the database is empty at startup, that speaker MUST NOT include the LSP-DB-VERSION TLV in the OPEN object 🫥.
If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN object and the values match, the PCC MAY skip State Synchronization, and the PCE doesn't wait for the end-of-synchronization marker [RFC8231] 🥳. Otherwise, the PCC MUST perform either full State Synchronization (see [RFC8231]) or incremental State Synchronization (see Section 4, if that capability is advertised) with the stateful PCE. Put another way, if the incremental State Synchronization capability isn't advertised by the peers, a version match means State Synchronization is either skipped or a full one happens 🔀.
If the PCC tries to skip State Synchronization, by setting the SYNC flag to 0 and PLSP-ID to a non-zero value on the first LSP State Report from the PCC as per [RFC8231], the PCE MUST send back a PCErr with Error-type=20 and Error-value=2 'LSP-DB version mismatch', and close the PCEP session 🚨.
If State Synchronization is required, the PCE has to act before the initialization phase wraps up. The PCE MUST mark any LSPs in the LSP-DB that the PCC reported earlier as stale 🏷️. When the PCC reports an LSP during State Synchronization and that LSP is already in the LSP-DB, the PCE MUST update the LSP-DB and clear the stale marker from that LSP ✅. Once State Synchronization is finished, the PCC MUST immediately send an end-of-synchronization marker. That marker is a PCRpt message with an LSP object containing a PLSP-ID of 0 and the SYNC flag set to 0 [RFC8231]. The LSP-DB-VERSION TLV MUST be included in this PCRpt message too 🏁. When the PCE gets this state report, it MUST purge any LSPs still marked as stale from the LSP-DB 🧹.
Note that a PCE/PCC MAY force State Synchronization by not including the LSP-DB-VERSION TLV in its OPEN object 💅.
Since a PCE never changes the LSP-DB Version Number, a PCC should never come across this TLV in a message from the PCE (other than the OPEN message) 🙃. If it does get one from a PCE anyway, the PCC SHOULD ignore the LSP-DB-VERSION TLV 🫠.
Figure 1 shows an example sequence where State Synchronization gets skipped 🦋.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=42 \ ,---Open--|
| S=1 \ / DBv=42 |
| \/ S=1 |
| /\ |
| / `-------->| (OK to skip sync)
(Skip sync) |<--------` |
| . |
| . |
| . |
| |
|--PCRpt,DBv=43,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=44,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=45,SYNC=0-->|
| |
Figure 1: State Synchronization SkippedFigure 2 shows an example sequence where State Synchronization happens because of an LSP-DB version mismatch during PCEP session setup 🔁. Heads up: the exact same State Synchronization sequence would play out if either the PCC or the PCE left out the LSP-DB-VERSION TLV from their respective Open messages 💫.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=46 \ ,---Open--|
| S=1 \ / DBv=42 |
| \/ S=1 |
| /\ |
| / `-------->| (Expect sync)
(Do sync) |<--------` |
| |
|--PCRpt,DBv=46,SYNC=1-->| (Sync start)
| . |
| . |
| . |
|--PCRpt,DBv=46,SYNC=0-->| (Sync done)
| . | (Purge LSP state
| . | if applicable)
| . |
|--PCRpt,DBv=47,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=48,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=49,SYNC=0-->|
| |
Figure 2: State Synchronization PerformedFigure 3 shows an example sequence where State Synchronization gets skipped, but because one or both PCEP speakers set the S flag to 0, the PCC stops sending LSP-DB-VERSION TLVs in later PCRpt messages to the PCE 🙀. If the current PCEP session restarts, the speakers will have to run State Synchronization, because the PCE doesn't know the PCC's latest LSP-DB Version Number 😭.
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=42 \ ,---Open--|
| S=0 \ / DBv=42 |
| \/ S=0 |
| /\ |
| / `-------->| (OK to skip sync)
(Skip sync) |<--------` |
| . |
| . |
| . |
|------PCRpt,SYNC=0----->| (Regular
| | LSP State Report)
|------PCRpt,SYNC=0----->| (Regular
| | LSP State Report)
|------PCRpt,SYNC=0----->|
| |
Figure 3: State Synchronization Skipped;
No LSP-DB-VERSION TLVs Sent from the PCC3.2.1. IP Address Change during Session Re-establishment 🌸
Sometimes, while a PCEP session is being re-established, the PCC's or PCE's IP address can change 🌬️. That includes, but isn't limited to, these cases:
- A PCC could connect to the PCE using a physical interface IP address. In that case, if the line card the PCC connects from changes, the PCEP session goes down and comes back up with a different IP address tied to the new line card 🔌.
- The PCC or PCE can move around the network, physically or logically, and that can change its IP address 🚚. For example, the PCE might be deployed as a virtual network function (VNF). Another virtualized instance of the PCE could be loaded with the original PCE instance's state, but get a different IP address 🧚.
So a PCEP peer can recognize a peer it's already talked to, each PCEP peer includes the SPEAKER-ENTITY-ID TLV described in Section 3.3.2 in the OPEN message 🪪.
This TLV gets used during the State Synchronization procedure to spot a PCEP session as a re-establishment of an earlier session that went down 🔍. That means State Synchronization optimizations, like state sync avoidance, can then apply to this session ✨. Heads up that this only works within the State Timeout Interval [RFC8231]. Once the State Timeout Interval expires, all state tied to the PCEP session is removed, and that includes the SPEAKER-ENTITY-ID that was received ⌛. The PCEP session initialization procedure from [RFC5440] stays exactly the same 🎀.
3.3. PCEP Extensions 💜
A new INCLUDE-DB-VERSION (S) bit gets added to the stateful capabilities TLV (see Section 7 for details) 🌈.
3.3.1. LSP-DB Version Number TLV ✨
Okay bestie, the LSP-DB Version Number (LSP-DB-VERSION) TLV is totally optional 🎀, and it MAY be included in the OPEN object and the LSP object.
This TLV rides along in the LSP object inside a PCRpt message, and its whole job is to say which LSP-DB version the PCC is on 👑. It SHOULD NOT show up in the other PCEP messages, which are PCUpd (Path Computation Update Request), PCReq (Path Computation Request), and PCRep (Path Computation Reply) 🙈. If one somehow shows up there anyway, you MUST ignore it 💀.
Here's what the LSP-DB-VERSION TLV looks like 🦋:
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=23 | Length=8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP-DB Version Number |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: LSP-DB-VERSION TLV FormatThe type is 23, and the length is locked at 8 octets 🔢. The value is a 64-bit unsigned integer sent in network byte order, and that integer is the LSP-DB Version Number. Periodt 💅.
3.3.2. Speaker Entity Identifier TLV
Next up is the Speaker Entity Identifier TLV (SPEAKER-ENTITY-ID), which is another optional one 🌸. It MAY be included in the OPEN object when a PCEP speaker wants to figure out whether State Synchronization can be skipped after a PCEP session restarts ✨. It holds a unique ID for the node that stays the same for the whole life of the PCEP speaker, so peers can still recognise it even if its IP address changes 🫶.
Here's the tea 🍵. If a remote peer changes its IP address, a PCEP speaker learns the Speaker Entity Identifier when it receives the open message. But it MAY have already sent its own open message without realising that it's talking to a peer it already knows 😭. In that situation, either a full synchronization happens or the PCEP session gets terminated. Which one is up to local policy, and that may be a local policy decision 🙈. Either way, the new IP address gets associated with the Speaker Entity Identifier going forward. In the latter case, when the PCEP session is re-established, it's correctly matched to the Speaker Entity Identifier and doesn't get treated as an unknown peer 🦋.
Here's the layout of the SPEAKER-ENTITY-ID TLV 🧚:
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=24 | Length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Speaker Entity Identifier //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: SPEAKER-ENTITY-ID TLV FormatThe type is 24, and the length is variable. The length MUST be greater than 0 📏. The value gets padded to a 4-octet alignment, but that padding doesn't count toward the Length field. The value holds the Speaker Entity Identifier, which is the ID of the PCEP speaker sending this TLV. This identifier is required to be unique within its scope of visibility, and that scope is usually a single domain 🌍. The operator MAY configure it. Or it can be derived automatically from a suitably stable unique identifier, like a Media Access Control (MAC) address, a serial number, a Traffic Engineering Router ID, or something similar 🔐. For inter-domain connections, the speaker SHOULD prefix its usual identifier with the domain identifier of where it lives, such as an Autonomous System number, an IGP area identifier, or something similar, so it stays unique 🌈.
The relationship between this identifier and entities in the Traffic Engineering database is intentionally left undefined 🤷♀️.
From a manageability point of view, a PCE or PCC implementation SHOULD allow the operator to configure this Speaker Entity Identifier 🛠️.
Now the big rule 🚨. If a PCEP speaker gets a SPEAKER-ENTITY-ID on a new PCEP session, and it matches an existing alive PCEP session, the PCEP speaker MUST send a PCErr with Error-type=20 and Error-value=7 'Received an invalid Speaker Entity Identifier', and then close the PCEP session 💥. Not vibing with duplicates, no cap.
4. Incremental State Synchronization ✨
[RFC8231] describes the LSP State Synchronization mechanism between PCCs and stateful PCEs. During State Synchronization, a PCC sends the info for all its LSPs (i.e., the full LSP-DB) to the stateful PCE 📦. To cut down on that State Synchronization overhead when only a few LSP state changes happen in the network between PCEP session restarts, this section defines a mechanism for incremental (Delta) LSP-DB synchronization 🦋.
4.1. Motivation
According to [RFC8231], if a PCE restarts and its LSP-DB survived, PCCs with a mismatched LSP-DB Version Number will send all their LSP info (the full LSP-DB) to the stateful PCE, even if only a small number of LSPs actually changed state 😩. That can take a long time and eat up a lot of channel bandwidth.
Figure 6 shows an example of LSP State Synchronization 🗺️:
+-----+
| PCE |
+-----+
/
/
/
/
+------+ +------+
| PCC1 |------------| PCC2 |
+------+ +------+
| |
| |
+------+ +------+
| PCC3 |------------| PCC4 |
+------+ +------+
Figure 6: Topology ExampleLet's say there are 320 LSPs in the network, with each PCC having 80 LSPs 🍓. While the PCEP session is down, 20 LSPs from each PCC (so 80 LSPs in total) change. When the PCEP session restarts, the stateful PCE has to synchronize 320 LSPs with all the PCCs. But honestly, 240 of those LSPs stayed the same, which is giving wasted effort 💀. Doing a full LSP State Synchronization can take forever, and it's especially rough when you only have a low bandwidth channel (like an in-band control channel for optical transport networks) and there are tons of LSPs in the network 🐢. Another downside of full LSP synchronization is that it wastes bandwidth when the number of LSP changes during the downtime could be small 😤.
So an incremental (Delta) LSP-DB State Synchronization is described in this section, where only the LSPs that changed state get synchronized between the session restart 💜. That can include new, modified, or deleted LSPs ✨.
4.2. Incremental Synchronization Procedure ✨
okay so [RFC8231] explains State Synchronization, and Section 3 of this document explains how to skip it with the LSP-DB-VERSION TLV in the OPEN object 🧚. This section takes that idea further: if the versions don't match, you only sync the delta (the changes) instead of everything 💅
If both PCEP speakers include the LSP-DB-VERSION TLV in the OPEN object and the LSP-DB-VERSION TLV values match, the PCC MAY skip State Synchronization. Otherwise, the PCC MUST perform State Synchronization. Incremental State Synchronization capability gets advertised during session startup using the DELTA-LSP-SYNC-CAPABILITY (D) bit in the capabilities TLV (see Section 7) 🎀 Instead of dumping the full LSP-DB on the stateful PCE again, the PCC syncs only the delta (changes) as shown in Figure 7, but only when the D and S flags are set to 1 by both the PCC and the PCE 🦋 Any other combination of D and S flags from the PCC and PCE means you get the full LSP-DB sync from [RFC8231] instead. And if a PCEP speaker sets the D flag to zero in the OPEN message, it can skip the incremental optimization, which gives you a full LSP-DB sync 🙈
+-+-+ +-+-+
|PCC| |PCE|
+-+-+ +-+-+
| |
|--Open--, |
| DBv=46 \ ,---Open--|
| S=1 \ / DBv=42 |
| D=1 \/ S=1 |
| /\ D=1 |
| / \ |
| / `-------->| (Expect delta sync)
(Do sync)|<--------` | (DO NOT purge LSP
(Delta) | | state)
| |
(Delta sync starts) |--PCRpt,DBv=46,SYNC=1-->|
| . |
| . |
| . |
| . |
|--PCRpt,DBv=46,SYNC=0-->| (Sync done,
| | PLSP-ID=0)
| |
|--PCRpt,DBv=47,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=48,SYNC=0-->| (Regular
| | LSP State Report)
|--PCRpt,DBv=49,SYNC=0-->|
| |
Figure 7: Incremental Synchronization ProcedureAs per Section 3, the LSP-DB Version Number goes up by one every time the PCC's local LSP-DB changes 📈 Each LSP is tagged with the DB version from when its state changed. That's how the PCE figures out which LSPs and which info need syncing during incremental State Synchronization 🔍 The incremental sync runs from the last LSP-DB version the PCE received up to the PCC's latest DB version. Also, the LSP-DB Version Number can wrap around, and when it does, the incremental sync wraps too, until it reaches the PCC's latest LSP-DB Version Number 🔁
For incremental State Synchronization, the PCC doesn't need to keep a full history of LSP-DB changes forever 🙌 It only has to remember the LSP state changes (including LSP modification, setup, and deletion) that the PCE didn't get to process when the session went down. Here's the tricky bit: the PCC can't tell whether the PCE already processed a particular LSP report before the session dropped 🥺 So a PCC implementation MAY choose to store the LSP-DB Version Number with each LSP at the time its status changed. That way, when the session comes back, an incremental sync can be tried from the PCE's last LSP-DB Version Number ✨ For an LSP that gets deleted at the PCC, the implementation has to remember the deleted LSP somehow, so it can still be reported in a later incremental sync 💀 The PCC throws this info away based on local policy, or when it's confident enough that the info isn't needed anymore. In the Figure 7 example, the PCC has to store the LSP state changes between DB Versions 43 and 46 and sync those when it does the incremental LSP state update 🌸
If a PCC finds out it doesn't have enough information to finish incremental synchronization after advertising the incremental LSP State Synchronization capability, it MUST send a PCErr with Error-type=20 and Error-value=5 'A PCC indicates to a PCE that it can not complete the State Synchronization' (defined in [RFC8231]), and terminate the session. The PCC SHOULD re-establish the session with the D bit set to 0 in the OPEN message 🚨
The other procedures and error checks stay exactly the same as the full State Synchronization in [RFC8231] 💖
5. PCE-Triggered Initial Synchronization 🌈
5.1. Motivation
In networks like optical transport networks, the control channel between network nodes can run over in-band overhead, which means it has limited bandwidth 🥹 When a stateful PCE connects to the network through one network node, you want to control the timing of PCC State Synchronization. Otherwise you could overload that thin communication channel during the initial synchronization (full or incremental) when the session restarts, especially when there's a lot of control information that needs syncing between the stateful PCE and the network 😭 Letting the PCE trigger State Synchronization is the method being proposed here. It's similar to the function in Section 6, but it's used in different scenarios and for different purposes 💜
5.2. PCE-Triggered Initial State Synchronization Procedure
Support for PCE-triggered initial State Synchronization gets advertised during session startup using the TRIGGERED-INITIAL-SYNC (F) bit in the STATEFUL-PCE-CAPABILITY TLV (see Section 7) 🍓
So a stateful PCE can control the LSP-DB synchronization after a PCEP session is set up, both PCEP speakers MUST set the F bit to 1 in the OPEN message 👑 If both PCEP speakers include the LSP-DB-VERSION TLV and the TLV values match, State Synchronization can be skipped as described in Section 3.2. If the TLV isn't included, or the LSP-DB Version is mismatched, the PCE can trigger State Synchronization by sending a PCUpd message with PLSP-ID = 0 and SYNC = 1. The PCUpd message SHOULD include an empty Explicit Route Object (ERO) (with no ERO sub-object and object length of 4) as its intended path, and SHOULD NOT include the optional objects for its attributes for any parameter update. The PCC MUST ignore such an update when the SYNC flag is set 🙅♀️ If the TRIGGERED-INITIAL-SYNC capability isn't advertised by a PCE, and the PCC receives a PCUpd with the SYNC flag set to 1, the PCC MUST send a PCErr with the SRP-ID-number of the PCUpd, Error-type=20, and Error-value=4 'Attempt to trigger a synchronization when the PCE triggered synchronization capability has not been advertised' (see Section 8.1) 😤 If the TRIGGERED-INITIAL-SYNC capability is advertised by both a PCE and the PCC, the PCC MUST NOT trigger State Synchronization on its own 🙅 And if the PCE receives a PCRpt message before it has triggered State Synchronization, the PCE MUST send a PCErr with Error-type=20 and Error-value=3 'Attempt to trigger synchronization before PCE trigger' (see Section 8.1) 💅
This way, the PCE controls the order of LSP synchronization across all the PCCs re-establishing PCEP sessions with it 🦋 When PCE control is enabled, a PCC only starts sending information to the PCE after it gets that message ✨ This PCE-triggering capability works for both full and incremental State Synchronization. With the incremental kind, PCCs only send the info the PCE doesn't already have, which is inferred from the LSP-DB version info exchanged in the OPEN message (see Section 4.2 for the detailed procedure) 🧠
Once the PCE triggers the initial State Synchronization, the procedures and error checks stay unchanged from [RFC8231] 🫶
If a PCC implementation that doesn't support this extension shouldn't receive a PCUpd message that triggers State Synchronization, given the capability advertisement. But if it does receive one, it behaves according to [RFC8231] 🤷♀️
6. PCE-Triggered Resynchronization 🔁
6.1. Motivation
How accurate the PCE's computations are depends on how accurate its view of the LSP state is 🎯 So it can really help to be able to resynchronize that state even after the session is already up. The PCE can use this to keep sanity-checking its state against the network, or to recover from error conditions without tearing down sessions 🙌
6.2. PCE-Triggered State Resynchronization Procedure
okay so bestie, this is where the PCE gets to say "hey, I want a fresh look" 💅✨ Both PCEP speakers tell each other during session startup that they support this, using the TRIGGERED-RESYNC (T) bit in the STATEFUL-PCE-CAPABILITY TLV (see Section 7) 🎀. And the PCE gets to choose: resync its whole LSP-DB, or just one LSP. Main character choice 👑
To resync a single LSP, the PCE sends a Path Computation State Update (PCUpd) for that LSP with the SYNC flag in the LSP object set to 1 🦋. The PCE SHOULD NOT include any parameter updates for the LSP, and the PCC MUST ignore that kind of update when the SYNC flag is set 🙈. Then the PCC MUST respond with a PCRpt message carrying the LSP state, SYNC flag set to 0, and it MUST include the SRP-ID-number of the PCUpd that started all this 🌸. If the PCC can't find the LSP in its database, the PCC MUST also set the R (remove) flag [RFC8231] in the LSP object in that PCRpt message 💀.
The PCE can also resync the entire LSP-DB 🌈. First, the PCE MUST mark every LSP in the LSP-DB that the PCC previously reported as stale 🫶. Then it sends a PCUpd with an LSP object containing a PLSP-ID of 0 and the SYNC flag set to 1 🍓. This PCUpd MUST include an empty ERO (no ERO sub-object, object length of 4) as its intended path, and it SHOULD NOT include the optional objects for its attributes for any parameter update 💜. The PCC MUST ignore that update if the SYNC flag is set. This PCUpd is the trigger for the PCC to enter the synchronization phase described in [RFC8231] and start sending PCRpt messages 🧚. Once the end-of-synchronization marker arrives, the PCE purges any LSPs that weren't refreshed 🧹. The SRP-ID-number of the PCUpd that triggered the resync SHOULD be included in each PCRpt message ⭐.
If the PCC can't resync the entire LSP-DB, the PCC MUST respond with a PCErr message with Error-type=20 and Error-value=5 'cannot complete the State Synchronization' [RFC8231] 😭, and it MAY terminate the session. The PCE MUST remove the stale mark for the LSPs that were previously reported by the PCC 🧽. Depending on local policy, the PCE MAY try the synchronization again later ⏰.
If the TRIGGERED-RESYNC capability is not advertised by a PCE, and the PCC gets a PCUpd with the SYNC flag set to 1, the PCC MUST send a PCErr with the SRP-ID-number of that PCUpd, Error-type=20, and Error-value=4 'Attempt to trigger a synchronization when the PCE triggered synchronization capability has not been advertised' (see Section 8.1) 🚫💅.
Once the PCE triggers state resync, the procedures and error checks stay the same as full state synchronization [RFC8231] 🎀. That also covers the PCE triggering multiple state resynchronization requests while a synchronization is already in progress 🔁.
If a PCC implementation that doesn't implement this extension should not receive a PCUpd to trigger resync, based on the capability advertisement, but it somehow does, it will behave as per [RFC8231] 🤷♀️✨.
7. Advertising Support of Synchronization Optimizations ✨
Support for each optimization in this document requires advertising the matching capabilities during session establishment 🦋.
The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]. This document defines these new flags in the STATEFUL-PCE-CAPABILITY TLV 🌸:
Bit Description
------------------------- ---------------------------------
30 S bit (INCLUDE-DB-VERSION)
27 D bit (DELTA-LSP-SYNC-CAPABILITY)
26 F bit (TRIGGERED-INITIAL-SYNC)
28 T bit (TRIGGERED-RESYNC)If the S bit (INCLUDE-DB-VERSION) is set to 1 by both PCEP speakers, the PCC will include the LSP-DB-VERSION TLV in each LSP object 💖. See Section 3.2 for details.
If the D bit (DELTA-LSP-SYNC-CAPABILITY) is set to 1 by a PCEP speaker, it means that speaker allows incremental (delta) State Synchronization 🧠. See Section 4.2 for details.
If the F bit (TRIGGERED-INITIAL-SYNC) is set to 1 by both PCEP speakers, the PCE SHOULD trigger initial (first) State Synchronization 🎬. See Section 5.2 for details.
If the T bit (TRIGGERED-RESYNC) is set to 1 by both PCEP speakers, the PCE can trigger resynchronization of LSPs at any point in the life of the session 🔄. See Section 6.2 for details.
See Section 8.3 for IANA allocations 📋.
8. IANA Considerations 📋
IANA has allocated code points for the protocol elements defined in this document 🎀.
8.1. PCEP-Error Object
IANA has allocated the following values in the "PCEP-ERROR Object Error Types and Values" registry 🧾.
Error-Type Meaning Reference
------------------------------------------------------------
6 Mandatory Object missing [RFC5440]
Error-value
12: LSP-DB-VERSION TLV missing This document
20 LSP State Synchronization Error [RFC8231]
Error-value
2: LSP-DB version mismatch. This document
3: Attempt to trigger This document
synchronization before PCE
trigger.
4: Attempt to trigger a This document
synchronization when the
PCE triggered synchronization
capability has not been
advertised.
6: Received an invalid This document
LSP-DB Version Number.
7: Received an invalid This document
Speaker Entity Identifier.8.2. PCEP TLV Type Indicators
IANA has allocated the following values in the "PCEP TLV Type Indicators" registry 🪄.
Value Meaning Reference
------------------------- ----------------- -------------
23 LSP-DB-VERSION This document
24 SPEAKER-ENTITY-ID This document8.3. STATEFUL-PCE-CAPABILITY TLV
The STATEFUL-PCE-CAPABILITY TLV is defined in [RFC8231]. The "STATEFUL-PCE-CAPABILITY TLV Flag Field" registry has been created to manage the flags in the TLV 🗂️. IANA has allocated the following values in this registry 💜.
Bit Description Reference
-------------------------- -------------------------- -------------
26 TRIGGERED-INITIAL-SYNC This document
27 DELTA-LSP-SYNC-CAPABILITY This document
28 TRIGGERED-RESYNC This document
30 INCLUDE-DB-VERSION This document9. Manageability Considerations 🛠️
All manageability requirements and considerations listed in [RFC5440] and [RFC8231] apply to the PCEP protocol extensions defined in this document 🎀. On top of that, the requirements and considerations in this section apply too 💅.
9.1. Control of Function and Policy
A PCE or PCC implementation MUST allow configuring the State Synchronization optimization capabilities described in this document 🎛️. The implementation SHOULD also allow the operator to configure the Speaker Entity Identifier (Section 3.3.2) 🆔. Further, the operator SHOULD be allowed to trigger the resynchronization procedures as per Section 6.2 🔁.
9.2. Information and Data Models
An implementation SHOULD allow the operator to view the stateful capabilities advertised by each peer and the current synchronization status with each peer 👀. To serve this purpose, the PCEP YANG module [PCEP-YANG] can be extended to include advertised stateful capabilities and synchronization status 🌷.
9.3. Liveness Detection and Monitoring
Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements beyond those already listed in [RFC5440] 💖.
9.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation verification requirements beyond those already listed in [RFC5440] and [RFC8231] ✅.
9.5. Requirements on Other Protocols
Mechanisms defined in this document do not imply any new requirements on other protocols 🙌.
9.6. Impact on Network Operations
Mechanisms defined in [RFC5440] and [RFC8231] also apply to the PCEP extensions defined in this document 🧩.
The State Synchronization optimizations described in this document can reduce the amount of data exchanged, and the time it takes for a stateful PCE to be fully operational when a PCEP session is re-established ⚡. The ability to trigger resynchronization by the PCE can be used by the operator to sanity check its state and recover from any state mismatch without tearing down the session 🦋.
10. Security Considerations 🚨
The security considerations listed in [RFC8231] apply to this document as well 🔒. However, this document also introduces some new attack vectors, and these are serious 😱. An attacker could spoof the SPEAKER-ENTITY-ID and pretend to be another PCEP speaker 🥸. An attacker may flood the PCC with triggered resynchronization requests at a rate that exceeds the PCC's ability to process them, either by spoofing messages or by compromising the PCE itself 🌊. The PCC can respond with a PCErr message as described in Section 6.2 and terminate the session 🛑. Thus, securing the PCEP session using Transport Layer Security (TLS) [PCEPS], following the recommendations and best current practices in [RFC7525], is RECOMMENDED 🔐. An administrator could also expose the Speaker Entity Identifier as part of the certificate, for peer identity verification 🪪.
11. References 📚
11.1. Normative References
[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>.
[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,
<http://www.rfc-editor.org/info/rfc8231>.11.2. Informative References ✨
okay bestie, these are the informative refs 📚 the extra reading that's really good to know but isn't required to get the spec. Here's the whole list, no cap 💅
[PCEP-YANG]
Dhody, D., Hardwick, J., Beeram, V., and j.
jefftant@gmail.com, "A YANG Data Model for Path
Computation Element Communications Protocol (PCEP)", Work
in Progress, draft-ietf-pce-pcep-yang-05, July 2017.
[PCEPS] Lopez, D., Dios, O., Wu, Q., and D. Dhody, "Secure
Transport for PCEP", Work in Progress,
draft-ietf-pce-pceps-18, September 2017.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[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>.Acknowledgments 🫶
We would like to thank Young Lee, Sergio Belotti, and Cyril Margaria for their comments and discussions. they were so helpful 💖
Thanks to Jonathan Hardwick for being the document shepherd and providing comments and guidance. shepherd queen 👑
Thanks to Tomonori Takeda for the Routing Area Directorate review. 🌸
Thanks to Adrian Farrel for the TSVART review and providing detailed comments and suggestions. the detailed notes are giving thorough 🦋
Thanks to Daniel Franke for the SECDIR review. 🔥
Thanks to Alvaro Retana, Kathleen Moriarty, and Stephen Farrell for comments during the IESG evaluation. ✨
Thanks to Deborah Brungard for being the responsible AD and guiding the authors as needed. main character AD energy 🎀
Contributors 💜
Gang Xie
Huawei Technologies
F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong, 518129
China
Email: xiegang09@huawei.comAuthors' Addresses 🧚
Edward Crabbe
Oracle
Email: edward.crabbe@gmail.com
Ina Minei
Google, Inc.
1600 Amphitheatre Parkway
Mountain View, CA 94043
United States of America
Email: inaminei@google.com
Jan Medved
Cisco Systems, Inc.
170 West Tasman Dr.
San Jose, CA 95134
United States of America
Email: jmedved@cisco.com
Robert Varga
Pantheon Technologies SRO
Mlynske Nivy 56
Bratislava 821 05
Slovakia
Email: robert.varga@pantheon.tech
Xian Zhang
Huawei Technologies
F3-5-B R&D Center, Huawei Industrial Base, Bantian, Longgang District
Shenzhen, Guangdong 518129
China
Email: zhang.xian@huawei.com
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: dhruv.ietf@gmail.comthat's the whole RFC, we did it bestie 🌈🎀💅
📦 where this page comes from
- ietf: rfc8232 2017-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms