RFC 8400
Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection
RFC 8400: Extensions to RSVP-TE for Label Switched Path (LSP) Egress Protection 🦋
Okay bestie, this is RFC 8400 💖 It's a Standards Track doc from the IETF (Internet Engineering Task Force, the crew that writes the rules for how the internet talks to itself). It was published in June 2018 and it's giving real, official, approved-by-the-IESG energy ✨ The ISSN is 2070-1721. The authors are H. Chen (Huawei Technologies), A. Liu (Ciena), T. Saad (Cisco Systems), F. Xu (Verizon), and L. Huang (China Mobile) 👑 The header doesn't list anything it obsoletes or updates, so this one is standing on its own 🌸
Abstract ✨
This doc describes extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) so that the egress node(s) of a Point-to-Point (P2P) or Point-to-Multipoint (P2MP) Traffic Engineered (TE) Label Switched Path (LSP) can be protected locally 🛡️🎀
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 got public review and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 7841 🫶
Info about the current status of this doc, any errata, and how to send feedback is at https://www.rfc-editor.org/info/rfc8400 🧚
Copyright Notice ©️
Copyright (c) 2018 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 stood on the publication date. Read those carefully, bestie, because they explain your rights and restrictions for this doc 💅
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Local Protection of Egress Nodes . . . . . . . . . . . . 3
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 5
4.1. Extensions to SERO . . . . . . . . . . . . . . . . . . . 5
4.1.1. Primary Egress Subobject . . . . . . . . . . . . . . 7
4.1.2. P2P LSP ID Subobject . . . . . . . . . . . . . . . . 8
5. Egress Protection Behaviors . . . . . . . . . . . . . . . . . 9
5.1. Ingress Behavior . . . . . . . . . . . . . . . . . . . . 9
5.2. Primary Egress Behavior . . . . . . . . . . . . . . . . . 10
5.3. Backup Egress Behavior . . . . . . . . . . . . . . . . . 10
5.4. Transit Node and PLR Behavior . . . . . . . . . . . . . . 11
5.4.1. Signaling for One-to-One Protection . . . . . . . . . 12
5.4.2. Signaling for Facility Protection . . . . . . . . . . 12
5.4.3. Signaling for S2L Sub-LSP Protection . . . . . . . . 13
5.4.4. PLR Procedures during Local Repair . . . . . . . . . 14
6. Application Traffic Considerations . . . . . . . . . . . . . 14
6.1. A Typical Application . . . . . . . . . . . . . . . . . . 14
6.2. PLR Procedure for Applications . . . . . . . . . . . . . 17
6.3. Egress Procedures for Applications . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 211. Introduction 🌈
Okay so [RFC4090] describes two ways to locally protect the transit nodes of a P2P LSP: one-to-one and facility protection. [RFC4875] explains how those methods can be used to protect the transit nodes of a P2MP LSP. Neither doc talks about how to locally protect the egress node(s) of an LSP, which is kind of a plot hole 🙈
This doc fills that gap! It specifies RSVP-TE extensions for local protection of the egress node(s) of an LSP. "Egress node" and "egress" mean the same thing here, so use whichever you like 💖
1.1. Local Protection of Egress Nodes 🛡️
So the main idea: if you locally protect an egress node of an LSP, then when that egress node fails, the upstream node directly before it delivers the LSP's traffic to its destination through a backup egress node instead. If you don't protect the egress node, the traffic gets lost when it fails (aka it never reaches its destination) 😭
Figure 1 shows backup LSPs locally protecting egress nodes L1 and L2 of a primary P2MP LSP that starts at ingress node R1. La and Lb are the designated backup egress nodes for primary egress nodes L1 and L2, respectively. The backup LSP for L1 runs from its upstream node R3 to backup egress La, and the backup LSP for L2 runs from R5 to Lb 🦋
******* ******* S Source
[R2]-----[R3]-----[L1] CEx Customer Edge
*/ &\ \ Rx Non-Egress
*/ &\ \ Lx Egress
*/ &\ [CE1] *** Primary LSP
*/ &\ / &&& Backup LSP
*/ &\ /
*/ [La]
*/
*/
*/
*/ ******** ******** *******
[S]---[R1]------[R4]------[R5]-----[L2]
&\ \
&\ \
&\ [CE2]
&\ /
&\ /
[Lb]Figure 1: Backup LSP for Locally Protecting Egress
Here's the flow. During normal operations, the P2MP LSP's traffic goes through R3 to L1, and L1 delivers it to its destination CE1. When R3 detects that L1 failed, R3 switches the traffic onto the backup LSP to backup egress La, and La delivers it to CE1. The switch happens within tens of milliseconds, which is super fast ⚡
The exact way the upstream node R3 detects that the primary egress node has failed is out of scope for this doc 🙈
At the start, the primary P2MP LSP from ingress R1 to primary egress nodes L1 and L2 gets configured. It may carry traffic from source S (connected to R1) to destinations CE1 and CE2 (connected to L1 and L2, respectively) 🧚
To protect primary egress nodes L1 and L2, you configure on ingress R1 a backup egress node for L1, another backup egress node for L2, and any other options. After that config, the ingress sends a Path message for the LSP. That message carries information such as the Secondary Explicit Route Objects (SEROs), which you can read about in Section 4.1. The SEROs contain the backup egress nodes that protect the primary egress nodes 💅
After the upstream node of a primary egress node receives that Path message with the information, it sets up a backup LSP to the matching backup egress node that protects the primary egress node 🎀
2. Conventions Used in This Document 💜
Bestie, this section is where the capital-letter words get their special meaning, 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 🔥
3. Terminology 🧚
Here's the terminology this doc uses. Think of it as your glossary, bestie 📖
LSP: Label Switched Path
TE: Traffic Engineering
P2MP: Point-to-Multipoint
P2P: Point-to-Point
LSR: Label Switching Router
RSVP: Resource Reservation Protocol
S2L: Source-to-Leaf
SERO: Secondary Explicit Route Object
RRO: Record Route Object
BFD: Bidirectional Forwarding Detection
VPN: Virtual Private Network
L3VPN: Layer 3 VPN
VRF: Virtual Routing and Forwarding
LFIB: Label Forwarding Information Base
UA: Upstream Assigned
PLR: Point of Local Repair
BGP: Border Gateway Protocol
CE: Customer Edge
PE: Provider Edge4. Protocol Extensions 🌸
Part 1 ends right here, bestie! Part 2 picks up with the protocol extensions 🫶
4.1. Extensions to SERO ✨
okay so the Secondary Explicit Route Object (SERO) is already defined over in [RFC4873] 💖 we're not reinventing it, we're just reusing its format. the vibe is iconic 🎀
the SERO that protects a primary egress node of a primary LSP can get tucked into the Path messages for that LSP. the ingress node sends them to the upstream node of the egress node 🦋 and this SERO has three subobjects.
the first subobject (see Section 4.2 of [RFC4873]) names the branch node that's gonna originate the backup LSP (heading to a backup egress node). usually the branch node is the direct upstream neighbor of the primary egress node 👑 but if that neighbor doesn't do local protection against the primary egress node failing, the branch node can be any upstream node on the primary LSP 🌸 in that case, the backup LSP from the branch node to the backup egress node covers failures on the whole stretch of the primary LSP from the branch node up to and including the primary egress node. no cap, that's a lot of coverage 😭
the second subobject is the Egress Protection subobject. it's a PROTECTION object with a brand new C-Type (3) ✨ here's how it's laid out:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Type | Length | Reserved | C-Type (3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |E-Flags|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Subobjects |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+the E-Flags are the bits for local protection of egress nodes 🔥 there are two:
- Bit 31 ("egress local protection" flag): the least significant bit of the 32-bit word. set it to 1 and you're saying local protection of egress nodes is wanted 💅
- Bit 30 ("S2L sub-LSP backup desired" flag): the second least significant bit. set it to 1 and you're saying an S2L sub-LSP (see [RFC4875]) is wanted to protect an egress node of a P2MP LSP 🧚
the Reserved parts MUST be set to zero on transmission and MUST be ignored on receipt 🙈
there are four optional subobjects: IPv4 and IPv6 primary egress node subobjects, plus IPv4 and IPv6 P2P LSP ID subobjects 🌈 the primary egress ones carry the IPv4 or IPv6 address of the primary egress node, and the P2P LSP ID ones are how you identify IPv4 or IPv6 backup P2P LSP tunnels. all the details are in Sections 4.1.1 through 4.1.2.2 ✨ and they all share this format:
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 | Reserved (zero) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents / Body of Subobject |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+where Type is the subobject's type and Length is the total size of the subobject in bytes, counting the Type, Length, and Contents fields 💜 the Reserved field MUST be set to zero on transmission and MUST be ignored on receipt 🙈
the third and final subobject (see Section 4.2 of [RFC4873]) is the egress node of the backup LSP. basically it's the address of the backup egress node standing in for the merge node 🍓
once the upstream node of the primary egress node (aka the branch node) gets the SERO and figures out a backup egress node for the primary egress node, it works out a path from itself to that backup egress node and sets up a backup LSP along it 🦋 it uses the FAST_REROUTE object in the Path message to decide how to protect the primary egress node. so if facility protection is wanted, that's what it gives the primary egress node 💖
the upstream node then builds a new SERO based on the one it got and drops it into the Path message for the backup LSP ✨ this new SERO also has three subobjects, just like the primary LSP's SERO. the first one names the upstream node and can be copied from the first subobject of the SERO it received 👑 the second one holds the primary egress node's address, and the third one has the backup egress node 🌸
last step: the upstream node updates the SERO in the Path message for the primary LSP 💅 the Egress Protection subobject in there carries a P2P LSP ID subobject with the info needed to identify the backup LSP, and the final subobject gives the address of the backup egress node 🫶
4.1.1. Primary Egress Subobject
there are two of these: the IPv4 primary egress subobject and the IPv6 primary egress subobject 🎀
an IPv4 primary egress subobject has Type 1, and its body looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Address (4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- IPv4 Address: the IPv4 address of the primary egress node 🌸
an IPv6 primary egress subobject has Type 2, and its body looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address (16 bytes) |
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- IPv6 Address: the IPv6 address of the primary egress node 🌈
4.1.2. P2P LSP ID Subobject
a P2P LSP ID subobject is how you identify a backup P2P LSP tunnel 🔥
4.1.2.1. IPv4 P2P LSP ID Subobject
the IPv4 P2P LSP ID subobject has Type 3, and its body looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P2P LSP Tunnel Egress IPv4 Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (MUST be zero) | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- P2P LSP Tunnel Egress IPv4 Address: the IPv4 address of the tunnel's egress node 💖
- Tunnel ID (see [RFC4875] and [RFC3209]): a 16-bit identifier that stays the same for the whole life of the tunnel, sitting in the least significant 16 bits of the 32-bit word ✨
- Extended Tunnel ID (see [RFC4875] and [RFC3209]): a 4-byte identifier that also stays constant for the tunnel's whole life 🦋
4.1.2.2. IPv6 P2P LSP ID Subobject
the IPv6 P2P LSP ID subobject has Type 4, and its body looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ P2P LSP Tunnel Egress IPv6 Address (16 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved (MUST be zero) | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Extended Tunnel ID (16 bytes) ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- P2P LSP Tunnel Egress IPv6 Address: the IPv6 address of the tunnel's egress node 🌸
- Tunnel ID (see [RFC4875] and [RFC3209]): a 16-bit identifier that stays the same for the whole life of the tunnel, sitting in the least significant 16 bits of the 32-bit word 💜
- Extended Tunnel ID (see [RFC4875] and [RFC3209]): a 16-byte identifier that stays constant for the tunnel's whole life 🫶
5. Egress Protection Behaviors 💅
5.1. Ingress Behavior
to protect a primary egress node of an LSP, the ingress node MUST set the "label recording desired" flag and the "node protection desired" flag in the SESSION_ATTRIBUTE object 🔥
if one-to-one backup or facility backup is wanted to protect a primary egress node of an LSP, the ingress node MUST include a FAST_REROUTE object and set the "one-to-one backup desired" or "facility backup desired" flag, respectively 🎀
if S2L sub-LSP backup is wanted to protect a primary egress node of a P2MP LSP, the ingress node MUST set the "S2L sub-LSP backup desired" flag in an SERO object 🧚
deciding to set up a backup egress node to protect the primary egress node of an LSP can be started by either the ingress node or the primary egress node of that LSP, but not both 👑
a backup egress node MUST be configured on the ingress node of an LSP to protect a primary egress node of that LSP if and only if the backup egress node is not configured on the primary egress node (see Section 5.2) ✨
the ingress node MUST send a Path message for the LSP with the objects above, plus the SEROs for protecting the LSP's egress nodes if egress protection is wanted 🦋 for each primary egress node of the LSP to be protected, the ingress node MUST add an SERO object into the Path message if a backup egress node or some options are given 💖 if a backup egress node is given, the final subobject in the SERO contains it; otherwise, the address in the final subobject is zero 🌸
5.2. Primary Egress Behavior
to protect a primary egress node of an LSP, a backup egress node MUST be configured on the primary egress node of that LSP if and only if the backup egress node is not configured on the ingress node of the LSP (see Section 5.1) 🌈
if the backup egress node is configured on the primary egress node of the LSP, the primary egress node MUST send its upstream node a Resv message for the LSP with an SERO for protecting the primary egress node 💅 it sets the flags in that SERO the same way an ingress node would 🫶
if the LSP carries service traffic with a service label, the primary egress node sends its matching backup egress node the info about that service label as a UA label (see [RFC5331]) and the related forwarding 🌟
5.3. Backup Egress Behavior ✨
Okay so, when a backup egress node gets a Path message for an LSP, it has to figure out if that LSP is being used for egress local protection 💅 It checks the SERO for an Egress Protection subobject. If that subobject is in the Path message and the "egress local protection" flag in it is set to 1, then yes, this LSP is the backup LSP for local protection of an egress node 🦋 The primary egress node being protected is listed in the primary egress subobject inside the SERO. iykyk 🫶
When the backup egress node receives the UA label and its related forwarding info from the primary egress node, it uses the backup LSP label as a context label. Then it makes a forwarding entry using that UA label info and the related forwarding 🎀
This forwarding entry lives in a forwarding table for the primary egress node. Main character energy 👑
When the primary egress node fails, its upstream node switches the traffic from the primary LSP over to the backup LSP, heading to the backup egress node 🌸 The backup egress node then delivers the traffic to its receiver (like a CE) 💖 It uses the backup LSP label as a context label to get the forwarding table for the primary egress node, and it uses the service label as a UA label to find the right forwarding entry in that table. Then it forwards the traffic to the receiver ✨
5.4. Transit Node and PLR Behavior ✨
So if a transit node of an LSP gets a Path message with the SEROs, and it's not an upstream node of any primary egress node of that LSP as a branch node, it MUST forward them unchanged 🧚
If the transit node is the upstream node of a primary egress node to be protected, as a branch node, then it figures out the backup egress node, gets a path for the backup LSP, and sets up the backup LSP along that path 🛤️ If the upstream node gets a Resv message with an SERO object, it MUST send its own upstream node the Resv message without that object. Bestie, that's just being tidy 💅
The PLR (that's the upstream node of the primary egress node, a.k.a. the branch node) MUST pull the backup egress node out of the matching SERO object, whether it's in a Path or a Resv message 🔍 If no matching SERO object shows up, the PLR tries to find a backup egress node that isn't the primary egress node but has the same IP address as the LSP's destination IP address. Resourceful 💀
Quick note 🙈 If a backup egress node isn't configured explicitly for protecting a primary egress node, the two nodes SHOULD have the same local address configured, and the cost to that local address on the backup egress node SHOULD be much bigger than the cost to it on the primary egress node. So the primary egress node and backup egress node are treated as a "virtual node" 🦋 The backup egress node is still different from that local address (from the primary egress node's point of view), so it's identified by an address that isn't that local address. Lowkey genius, ngl 😭
After getting the backup egress node, the PLR works out a backup path from itself to it and sets up a backup LSP along that path 🛣️ When it computes that path, it leaves out the segment that includes the primary egress node being protected. Then the PLR sends the primary egress node a Path message with an SERO for the primary LSP. That SERO points to the backup egress node in its final subobject 💌 The PLR also puts an SERO into the Path messages for the backup LSP, and that one points to the primary egress node. It's giving connected 🫶
The PLR MUST provide one-to-one backup protection for the primary egress node if the "one-to-one backup desired" flag is set in the message. Otherwise, it MUST provide facility backup protection if the "facility backup desired" flag is set 🔥
The PLR MUST set the protection flags in the RRO subobject for the primary egress node in the Resv message. It sets them based on the status of the primary egress node and the backup LSP that's protecting it. For example, it sets the "local protection available" flag and the "node protection" flag. Those say the primary egress node is protected when the backup LSP is up and ready to protect it ✨
5.4.1. Signaling for One-to-One Protection
Here's the vibe: the upstream node of a primary egress node (acting as a PLR) behaves exactly like a PLR doing one-to-one backup, as described in [RFC4090]. The only difference is that the upstream node, as a PLR, creates a backup LSP from itself to a backup egress node in a session that's different from the primary LSP 🌈
If the LSP is a P2MP LSP and a primary egress node of it is also a transit node (aka a bud node), then the upstream node of that primary egress node (as a PLR) creates a backup LSP from itself to each of the primary egress node's next hops 🌿
When the PLR detects the failure of the primary egress node, it switches the packets from the primary LSP to the backup LSP heading to the backup egress node 🦋 For the failure of the bud node of a P2MP LSP, the PLR also switches the packets to the backup LSPs going to the bud node's next hops. There, the packets get merged back into the primary LSP. Merge city 🎀
5.4.2. Signaling for Facility Protection
Except for the backup LSP and the downstream label, the upstream node of the primary egress node (as a PLR) follows the PLR behavior for facility backup, which is described in [RFC4090] 💖
For a bunch of primary P2P LSPs that go through the same PLR to the same primary egress node, that primary egress node MAY be protected by one backup LSP from the PLR to the backup egress node that was picked to protect it 🍓
The PLR selects or creates a backup LSP from itself to the backup egress node. If there's already a backup LSP that meets the constraints given in the Path message, that one gets picked. Otherwise, a new backup LSP to the backup egress node gets created 🧚
After it has the backup LSP, the PLR links it to a primary LSP so it can protect that primary egress node. The PLR records that this backup LSP protects the primary LSP against failure of the primary egress node. It MUST include an SERO object in the Path message for the primary LSP, and that object MUST contain the backup LSP ID. This tells the primary egress node that it MUST send the backup egress node the service label as a UA label. If there's a service carried by the LSP, it also has to send info about forwarding the traffic to its destination using that label. And if the primary LSP label isn't implicit null, the primary egress node sends that label as a UA label too 💅 How a UA label gets sent is out of scope for this document (refer to [FRAMEWK]). Bestie, that's a whole other conversation 🫶
When the PLR detects the failure of the primary egress node, it redirects the packets from the primary LSP into the backup LSP going to the backup egress node. If the label isn't implicit null, it keeps the primary LSP label from the primary egress node in the label stack ✨ The backup egress node delivers the packets to the same destinations the primary egress node would have, using the backup LSP label as a context label and the labels under it as UA labels 🌸
5.4.3. Signaling for S2L Sub-LSP Protection
The S2L sub-LSP protection uses an S2L sub-LSP (refer to [RFC4875]) as a backup LSP to protect a primary egress node of a P2MP LSP 🦋 The PLR MUST decide to protect a primary egress node of a P2MP LSP through S2L sub-LSP protection whenever it receives a Path message with the "S2L sub-LSP backup desired" flag set 🔥
The PLR MUST set up the backup S2L sub-LSP to the backup egress node. It creates and maintains its state the same way it would for an S2L sub-LSP defined in [RFC4875], from the signaling's point of view. It computes a path for the backup LSP from itself to the backup egress node, builds and sends a Path message along that path, and then receives and processes the Resv message that answers it 🛤️
After it gets the Resv message for the backup LSP, the PLR creates a forwarding entry in an inactive state (or flag) called an "inactive forwarding entry". That inactive forwarding entry doesn't forward any data traffic during normal operations. Sleepy but ready 😴
When the PLR detects that the primary egress node failed, it changes the forwarding entry for the backup LSP to "active". So now the PLR forwards traffic to the backup egress node through the backup LSP, and that node sends the traffic on to its destination 💜
5.4.4. PLR Procedures during Local Repair
When the upstream node of a primary egress node of an LSP (as a PLR) detects that the primary egress node failed, it follows the procedures defined in Section 6.5 of [RFC4090] 🧯 It SHOULD notify the ingress node about the primary egress node's failure, in the same way a PLR tells the ingress node about a transit node failure 📣
Also, the PLR MUST keep the upstream part of the primary LSP alive after the primary egress node fails. It does that by sending the Resv message to its upstream node along the primary LSP 🌈 The downstream part of the primary LSP (from the PLR to the primary egress node) SHOULD be removed. When a bypass LSP from the PLR to a backup egress node is protecting the primary egress node, the PLR MUST NOT send any Path message for the primary LSP through the bypass LSP to the backup egress node 🙅♀️
In the local revertive mode, the PLR re-signals each of the primary LSPs that were routed over the restored resource, once it detects that the resource is restored. Every primary LSP that gets successfully re-signaled along the restored resource gets switched back. Full glow-up arc 🦋✨
Note that the procedure for protecting the primary egress node gets triggered on the PLR if the primary egress node failure is determined. If the link (from the PLR to the primary egress node) failure is determined and the primary egress node is alive, then the link protection procedure gets triggered on the PLR instead. How to determine these is out of scope for this document 🫶
6. Application Traffic Considerations 🎀
Okay, this section is all about an example where the application traffic rides on P2P LSPs 💖 Let's see how it plays out 👀
6.1. A Typical Application
okay so L3VPN is the classic example and it's giving main character energy 💅 Figure 2 shows a simple VPN with two CEs, CE1 and CE2, hooked up to two PEs, R1 and L1. There's a P2P LSP from R1 to L1, drawn with stars (). This one is called the primary LSP. R1 is the ingress node of the LSP, and L1 is the (primary) egress node. R1 sends the VPN traffic it gets from CE1 down the P2P LSP to L1, and then L1 delivers it to CE2. R1 stacks an LSP label and a VPN label on the traffic when it sends it along the LSP. When the traffic hits L1, the egress node, L1 pops the LSP label and uses the VPN label to get the traffic to CE2 🎀
In older ingress-protection solutions for protecting VPN traffic against the failure of egress node L1, the ingress node R1 handles the reroute when the egress node dies (see Figure 2). That approach came with a few things:
- A multi-hop BFD session between ingress node R1 and egress node L1 of the primary LSP. This BFD session is drawn with dots (....).
- A backup LSP from ingress node R1 to backup egress node La, drawn with ampersands (&&&&).
- La sends R1 a VPN backup label and related information via BGP.
- R1 has a VRF with two sets of routes for CE2. One set uses the primary LSP and L1 as the next hop. The other uses the backup LSP and La as the next hop.
***** *****
CE1,CE2 in [R2]-----[R3]-----[L1] **** Primary LSP
one VPN */ : \ &&&& Backup LSP
*/ .................: \ .... BFD Session
[CE1]--[R1] ..: [CE2]
&\ /
&\ /
[R4]-----[R5]-----[La](BGP sends R1 VPN backup label)
&&&&& &&&&&
Figure 2: Protect Egress for L3VPN TrafficIn normal operations, R1 sends the VPN traffic from CE1 through the primary LSP, with the VPN label received from L1 as the inner label, to L1. L1 then delivers the traffic to CE2 using the VPN label.
When R1 detects the failure of L1, R1 sends the traffic from CE1 over the backup LSP, with the VPN backup label received from La as the inner label, to La. La then delivers the traffic to CE2 using the VPN backup label.
The solution in this document uses egress local protection for L3VPN traffic, and it works like this (see Figure 3):
- A BFD session between R3 (i.e., the upstream node of L1) and egress node L1 of the primary LSP. This is different from the BFD session in Figure 2, which is multi-hop between ingress node R1 and egress node L1. The PLR, R3, is closer to L1 than the ingress node R1 is. It may detect the failure of egress node L1 faster and more reliably. So this solution can provide faster protection for an egress node failure ⚡
- A backup LSP from R3 to backup egress node La. This is different from the backup LSP in Figure 2, which is an end-to-end LSP from ingress node R1 to backup egress node La.
- Primary egress node L1 sends backup egress node La the VPN label as a UA label, plus related information. Backup egress node La uses the backup LSP label as a context label and creates a forwarding entry, using the VPN label, in an LFIB for primary egress node L1.
- L1 and La are virtualized as one node (or address). R1 has a VRF with one set of routes for CE2, which uses the primary LSP from R1 to L1 and a virtualized node as the next hop. This is set up by configuring the same local address on L1 and La, and using that address as the destination of the LSP and as the BGP next hop for the VPN traffic. The cost to L1 is configured to be less than the cost to La 🦋
***** *****
CE1,CE2 in [R2]-----[R3]-----[L1] **** Primary LSP
one VPN */ &\:.....: \ &&&& Backup LSP
*/ &\ \ .... BFD Session
[CE1]--[R1] &\ [CE2]
&\ /
&\ /
[La](VPN label from L1 as a UA label)
Figure 3: Locally Protect Egress for L3VPN TrafficIn normal operations, R1 sends the VPN traffic from CE1 over the primary LSP, with the VPN label as the inner label, to L1. L1 delivers the traffic to CE2 using the VPN label.
When the primary egress node L1 fails, its upstream node R3 detects it and switches the VPN traffic from the primary LSP to the backup LSP to La. La delivers the traffic to CE2 using the backup LSP label as a context label, to get the LFIB for L1, and the VPN label as a UA label, to find the forwarding entry in the LFIB that forwards the traffic to CE2 🫶
6.2. PLR Procedure for Applications
When the PLR gets a backup LSP from itself to a backup egress node to protect a primary egress node of a primary LSP, it includes an SERO object in the Path message for the primary LSP. The object carries the ID information of the backup LSP and indicates that the primary egress node sends the backup egress node the application traffic label (e.g., the VPN label) as a UA label when needed 🧚
6.3. Egress Procedures for Applications
When a primary egress node of an LSP sends the ingress node of that LSP a label for an application, like a VPN label, it sends the label (as a UA label) to the backup egress node that protects it. Exactly how the label is sent is out of scope for this document 🙈
When the backup egress node receives a UA label from the primary egress node, it adds a forwarding entry with that label into the LFIB for the primary egress node. When the backup egress node receives a packet from the backup LSP, it uses the top label as a context label to find the LFIB for the primary egress node. Then it uses the inner label to deliver the packet to the same destination as the primary egress node, according to the LFIB 💜
7. Security Considerations ✨🔒
okay bestie, this section is SERIOUS 💀 This document builds on existing work, so the security considerations of [RFC4090], [RFC4875], [RFC3209], and [RFC2205] still apply. On top of that, protecting a primary egress node of a P2P LSP that carries service traffic through a backup egress node needs out-of-band communication between the two egress nodes. The primary egress node has to convey a service label as a UA label, and it also has to convey its related forwarding information to the backup egress node. It is important to confirm that the identifiers used to identify the primary and backup egress nodes in the LSP are verified to match the identifiers used in the out-of-band protocol (such as BGP). No skipping this part, it's the whole vibe 🚨
8. IANA Considerations 📋
IANA maintains a registry called "Class Names, Class Numbers, and Class Types" under "Resource Reservation Protocol (RSVP) Parameters". IANA has assigned a new C-Type under the PROTECTION object class, Class Number 37:
Value Description Definition
----- ----------- ----------
3 Egress Protection Section 4.1IANA has created and now maintains a registry under the PROTECTION object class (Class Number 37) and Egress Protection (C-Type 3). The initial values for the registry are below. Future assignments are to be made through IETF Review [RFC8216] 🌈
Value Description Definition
----- ----------- ----------
0 Reserved
1 IPv4_PRIMARY_EGRESS Section 4.1.1
2 IPv6_PRIMARY_EGRESS Section 4.1.1
3 IPv4_P2P_LSP_ID Section 4.1.2
4 IPv6_P2P_LSP_ID Section 4.1.2
5-127 Unassigned
128-255 Reserved9. References 📚
9.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>. - [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI
10.17487/RFC3209, December 2001,<https://www.rfc-editor.org/info/rfc3209>. - [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, DOI
10.17487/RFC4090, May 2005,<https://www.rfc-editor.org/info/rfc4090>. - [RFC4873] Berger, L., Bryskin, I., Papadimitriou, D., and A. Farrel, "GMPLS Segment Recovery", RFC 4873, DOI
10.17487/RFC4873, May 2007,<https://www.rfc-editor.org/info/rfc4873>. - [RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, DOI
10.17487/RFC4875, May 2007,<https://www.rfc-editor.org/info/rfc4875>. - [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>. - [RFC8216] Pantos, R., Ed. and W. May, "HTTP Live Streaming", RFC 8216, DOI
10.17487/RFC8216, August 2017,<https://www.rfc-editor.org/info/rfc8216>.
9.2. Informative References
- [FRAMEWK] Shen, Y., Jeganathan, J., Decraene, B., Gredler, H., Michel, C., Chen, H., and Y. Jiang, "MPLS Egress Protection Framework", Work in Progress, draft-ietf-mpls-egress-protection-framework-00, January 2018.
- [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI
10.17487/RFC2205, September 1997,<https://www.rfc-editor.org/info/rfc2205>. - [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI
10.17487/RFC5331, August 2008,<https://www.rfc-editor.org/info/rfc5331>.
Acknowledgements 🫶
big thank-you to Richard Li, Nobo Akiya, Lou Berger, Jeffrey Zhang, Lizhong Jin, Ravi Torvi, Eric Gray, Olufemi Komolafe, Michael Yue, Daniel King, Rob Rennison, Neil Harrison, Kannan Sampath, Yimin Shen, Ronhazli Adam, and Quintin Zhao for their valuable comments and suggestions on this document 💖
Contributors 🌸
The following people contributed significantly to the content of this document and should be considered coauthors:
Ning So
Tata
Email: ningso01@gmail.com
Mehmet Toy
Verizon
Email: mehmet.toy@verizon.com
Lei Liu
Fujitsu
Email: lliu@us.fujitsu.com
Zhenbin Li
Huawei Technologies
Email: lizhenbin@huawei.comWe also acknowledge the contributions of the following individuals:
Boris Zhang
Telus Communications
Email: Boris.Zhang@telus.com
Nan Meng
Huawei Technologies
Email: mengnan@huawei.com
Prejeeth Kaladharan
Huawei Technologies
Email: prejeeth@gmail.com
Vic Liu
China Mobile
Email: liu.cmri@gmail.comAuthors' Addresses 💌
Okay bestie, here's the squad that wrote this spec 🫶
Huaimo Chen 🎀 Huawei Technologies Boston, MA United States of America
Email: huaimo.chen@huawei.com
Autumn Liu 🦋 Ciena United States of America
Email: hliu@ciena.com
Tarek Saad 🍓 Cisco Systems
Email: tsaad@cisco.com
Fengman Xu 🌸 Verizon 2400 N. Glenville Dr Richardson, TX 75082 United States of America
Email: fengman.xu@verizon.com
Lu Huang 🧚 China Mobile No.32 Xuanwumen West Street, Xicheng District Beijing 100053 China
Email: huanglu@chinamobile.com
📦 where this page comes from
- ietf: rfc8400 2018-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms