RFC 8679
MPLS Egress Protection Framework
RFC 8679: MPLS Egress Protection Framework 🎀
okay bestie, this one is from December 2019 and it's a Standards Track doc, so it's the real deal 💅. The main people behind it are Y. Shen, M. Jeyananth (Juniper Networks), B. Decraene (Orange), H. Gredler (RtBrick Inc.), C. Michel (Deutsche Telekom), and H. Chen (Futurewei). It's been through public review and got approved by the IESG, the group that signs off on Internet Standards 🌸. Its ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨.
Abstract 💖
okay so this doc is a fast reroute framework that protects IP/MPLS services and MPLS transport tunnels when an egress node or an egress link dies 😭. For each kind of egress failure, it sets up the roles: the Point of Local Repair (PLR), the protector, and the backup egress router. It also explains how to build a bypass tunnel from the PLR to the protector 🦋. Then it walks through what each router does when things go wrong, which is local repair on the PLR and context-based forwarding on the protector. The whole point is to cut down traffic loss before global repair kicks in and before the control-plane protocols finish converging on the new topology 🫶.
Status of This Memo 📜
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8679.
Copyright Notice ⚖️
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents 🗂️
1. Introduction
2. Specification of Requirements
3. Terminology
4. Requirements
5. Egress Node Protection
5.1. Reference Topology
5.2. Egress Node Failure and Detection
5.3. Protector and PLR
5.4. Protected Egress
5.5. Egress-Protected Tunnel and Service
5.6. Egress-Protection Bypass Tunnel
5.7. Context ID, Context Label, and Context-Based Forwarding
5.8. Advertisement and Path Resolution for Context ID
5.9. Egress-Protection Bypass Tunnel Establishment
5.10. Local Repair on PLR
5.11. Service Label Distribution from Egress Router to Protector
5.12. Centralized Protector Mode
6. Egress Link Protection
7. Global Repair
8. Operational Considerations
9. General Context-Based Forwarding
10. Example: Layer 3 VPN Egress Protection
10.1. Egress Node Protection
10.2. Egress Link Protection
10.3. Global Repair
10.4. Other Modes of VPN Label Allocation
11. IANA Considerations
12. Security Considerations
13. References
13.1. Normative References
13.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction ✨
okay so in MPLS networks, Label Switched Paths (LSPs) are the go-to transport tunnels for carrying IP and MPLS services across MPLS domains 🧚. The services can be Layer 2 VPNs, Layer 3 VPNs, hierarchical LSPs, and more. A single tunnel can carry several services, even of different types, as long as the tunnel meets both the individual and the aggregate needs of those services (think Class of Service (CoS) and QoS) 💜. The tunnel's egress router hosts the service instances. An MPLS service instance pushes service packets out an egress link toward the service destination, based on a service label. An IP service instance does the same thing, but based on an IP service address 🌈. That egress link is often called a Provider Edge - Customer Edge (PE-CE) link or an Attachment Circuit (AC).
now, local-repair fast reroute is already a big deal. Mechanisms like [RFC4090], [RFC5286], [RFC7490], and [RFC7812] are widely deployed to protect MPLS tunnels against transit link and node failures, and they restore traffic in the tens of milliseconds 🔥. The idea is that the router right upstream of a failure, the PLR, pre-establishes a bypass tunnel to the router right downstream of it, which is the Merge Point (MP). It pre-installs the bypass tunnel's forwarding state in the data plane, and then uses a rapid mechanism (like link-layer Operations, Administration, and Maintenance (OAM), Bidirectional Forwarding Detection (BFD), and others) to spot the failure locally in the data plane 👀. When the failure happens, the PLR sends traffic over the bypass to the MP, and traffic keeps flowing on to the tunnel's egress router. iconic 😭.
this doc specifies a fast reroute framework for egress node and egress link protection 🦋. It's a lot like transit protection, so it also leans on a PLR to do the local failure detection and local repair. The difference is where the PLR sits. For egress node protection, the PLR is the penultimate hop router of the tunnel. For egress link protection, the PLR is the tunnel's egress router itself 🎀. The framework also brings in a so-called "protector," which acts as the tail end of the bypass tunnel. The protector is a router that hosts "protection service instances" and has its own connectivity or paths to the service destinations. When a PLR does local repair, the protector does "context label switching" for rerouted MPLS service packets, and "context IP forwarding" for rerouted IP service packets, so those packets still reach their destinations 💅.
so the framework treats an egress node failure as two things at once: a failure of the tunnel, and a failure of all the services on that tunnel, because the service packets can't reach the service instances on the egress router anymore 😭. That means it handles egress node protection at both the tunnel level and the service level at the same time. An egress link failure gets treated as a failure of every service crossing that link, so egress link protection happens at the service level 🫶.
⚠️ heads up bestie: this framework MUST be used with dual homing. The destination of a service (a CE or a site) MUST be dual-homed, or have dual paths, to an MPLS network through two MPLS edge routers. One of those routers is the egress router of the service's transport tunnel. The other is a backup egress router that hosts a "backup service instance" 🚨.
in the "co-located" protector mode, the backup egress router doubles as the protector, so the backup service instance is also the protection service instance 💖. In the "centralized" protector mode (Section 5.12), the protector and the backup egress router are split apart. The protection service instance and the backup service instance get hosted separately by those two routers 🧚.
this framework is described mostly in terms of point-to-point (P2P) tunnels, but it works just as well for point-to-multipoint (P2MP), multipoint-to-point (MP2P), and multipoint-to-multipoint (MP2MP) tunnels, since the sub-LSPs of those tunnels can be viewed as P2P tunnels 🌸.
it's a multi-service and multi-transport framework, which is giving versatility 👑. The generic model says every service is made up of the same core parts: a service instance, a service label, a service label distribution protocol, and an MPLS transport tunnel. It also assumes the service label is downstream assigned, meaning the egress router assigns it. So the framework should fit most existing and future services. BUT there are some services with certain modes where the protector can't pre-establish the forwarding state for egress protection, or where the PLR isn't allowed to reroute traffic to other routers because that would duplicate traffic. Examples are the broadcast, multicast, and unknown unicast traffic in Virtual Private LAN Service (VPLS) and Ethernet VPN (EVPN) 🙈. Those cases are left for future study. Services that use upstream-assigned service labels are also out of scope and left for future study 💀.
the framework doesn't need any extensions to the existing signaling and label distribution protocols (like RSVP, LDP, BGP, etc.) for MPLS tunnels 🍓. It assumes transport tunnels and bypass tunnels get set up using the generic procedures those protocols already provide. That said, it doesn't block extensions that might make things easier, and [RFC8400] is one example of that. The framework does see a need for extensions to IGPs and service label distribution protocols in some procedures, especially for supporting protection establishment and context label switching. This document gives guidelines for those extensions, but leaves the specific details to separate documents 📜.
the framework is meant to complement control-plane convergence and global repair 🌈. Control-plane convergence relies on control protocols reacting to the topology changes caused by a failure. Global repair relies on an ingress router to detect a failure remotely and switch traffic to an alternative path. An example of global repair is the BGP prefix independent convergence mechanism [BGP-PIC] for BGP-established services. Compared to those, this framework is faster at restoring traffic, because it detects and repairs failures locally ⚡. So it's RECOMMENDED that the framework be used together with control-plane convergence or global repair, so you get the best of both worlds. The framework provides fast and temporary repair, while control-plane convergence or global repair provides the ultimate and permanent repair 🦋.
2. Specification of Requirements 📜
okay so the key words in this doc are the BCP 14 ones, and they only count when they show up in ALL CAPS like this:
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 ✨
okay so this section is basically the glossary, bestie. we need these words locked in before anything else makes sense 💅
Egress router: A router at the egress endpoint of a tunnel. It hosts service instances for all the services carried by the tunnel and has connectivity with the destinations of the services. 🎀
Egress node failure: A failure of an egress router. 💀
Egress link failure: A failure of the egress link (e.g., PE-CE link, attachment circuit) of a service. 🔌
Egress failure: An egress node failure or an egress link failure. 😭
Egress-protected tunnel: A tunnel whose egress router is protected by a mechanism according to this framework. The egress router is hence called a protected egress router. 🛡
Egress-protected service: An IP or MPLS service that is carried by an egress-protected tunnel and hence protected by a mechanism according to this framework. ✨
Backup egress router: Given an egress-protected tunnel and its egress router, this is another router that has connectivity with all or a subset of the destinations of the egress-protected services carried by the egress-protected tunnel. 🧚
Backup service instance: A service instance that is hosted by a backup egress router and corresponds to an egress-protected service on a protected egress router. 🌸
Protector: A role acted by a router as an alternate of a protected egress router, to handle service packets in the event of an egress failure. A protector may be physically co-located with or decoupled from a backup egress router, depending on the co-located or centralized protector mode. 👑
Protection service instance: A service instance hosted by a protector that corresponds to the service instance of an egress-protected service on a protected egress router. A protection service instance is a backup service instance, if the protector is co-located with a backup egress router. 🦋
PLR: A router at the point of local repair. In egress node protection, it is the penultimate hop router on an egress-protected tunnel. In egress link protection, it is the egress router of the egress-protected tunnel. 🔧
Protected egress {E, P}: A virtual node consisting of an ordered pair of egress router E and protector P. It serves as the virtual destination of an egress-protected tunnel and as the virtual location of the egress-protected services carried by the tunnel. 💜
Context identifier (ID): A globally unique IP address assigned to a protected egress {E, P}. 🌈
Context label: A non-reserved label assigned to a context ID by a protector. 🏷
Egress-protection bypass tunnel: A tunnel used to reroute service packets around an egress failure. 🚇
Co-located protector mode: The scenario where a protector and a backup egress router are co-located as one router; hence, each backup service instance serves as a protection service instance. 🤝
Centralized protector mode: The scenario where a protector is a dedicated router and is decoupled from backup egress routers. 🏝
Context label switching: Label switching performed by a protector in the label space of an egress router indicated by a context label. 🔀
Context IP forwarding: IP forwarding performed by a protector in the IP address space of an egress router indicated by a context label. 📬
4. Requirements
okay bestie, here's what this egress protection framework is aiming for ✨
- The framework must support P2P tunnels. It should equally support P2MP, MP2P, and MP2MP tunnels, by treating each sub-LSP as a P2P tunnel. 🧩
- The framework must support multi-service and multi-transport networks. It must accommodate existing and future signaling and label-distribution protocols of tunnels and bypass tunnels, including RSVP, LDP, BGP, IGP, Segment Routing, and others. It must also accommodate existing and future IP/MPLS services, including Layer 2 VPNs, Layer 3 VPNs, hierarchical LSP, and others. It MUST provide a general solution for networks where different types of services and tunnels co-exist. 🌍
- The framework must consider minimizing disruption during deployment. It should only involve routers close to the egress and be transparent to ingress routers and other transit routers. 🤫
- In egress node protection, for scalability and performance reasons, a PLR must be agnostic to services and service labels. It must maintain bypass tunnels and bypass forwarding state on a per-transport-tunnel basis rather than on a per-service-destination or per-service-label basis. It should also support bypass tunnel sharing between transport tunnels. 📈
- A PLR must be able to use its local visibility or information of routing or TE topology to compute or resolve a path for a bypass tunnel. 🗺
- A protector must be able to perform context label switching for rerouted MPLS service packets, based on a service label(s) assigned by an egress router. It must be able to perform context IP forwarding for rerouted IP service packets, in the public or private IP address space used by an egress router. 🔁
- The framework must be able to work seamlessly with transit link/node protection mechanisms to achieve end-to-end coverage. 🧵
- The framework must be able to work in conjunction with global repair and control-plane convergence. 🤝
5. Egress Node Protection
5.1. Reference Topology
this is the topology the doc uses when it walks through egress node protection, so keep it in your head 🗺
services 1, ..., N
=====================================> tunnel
I ------ R1 ------- PLR --------------- E ----
ingress penultimate hop egress \
| . (primary \
| . service \
| . instances ) \
| . \
| . \ service
| . destinations
| . / (CEs, sites)
| . /
| . bypass /
| . tunnel /
| . /
| ............... /
R2 --------------- P ----
protector
(protection
service
instances)
Figure 15.2. Egress Node Failure and Detection
an egress node failure is when an MPLS tunnel's egress router goes down. at the service level, that's also a service instance failure for every IP/MPLS service riding that tunnel 💔
an egress node failure can be spotted by an adjacent router (that's the PLR in this framework) using a node liveness detection mechanism, or a mechanism based on a collective failure of all the links to that node. these mechanisms MUST be reasonably fast, i.e., faster than control-plane failure detection and remote failure detection. otherwise, local repair won't be able to give much benefit compared to control-plane convergence or global repair. in general, the speed, accuracy, and reliability of a failure detection mechanism are the key factors in deciding whether it's a fit for egress node protection. this doc gives network operators the following guidelines for picking the right type of protection on a PLR 🔍
- If the PLR has a mechanism to detect and differentiate a link failure (of the link between the PLR and the egress node) and an egress node failure, it SHOULD set up both link protection and egress node protection and trigger one and only one protection upon a corresponding failure. 🎯
- If the PLR has a fast mechanism to detect a link failure and an egress node failure, but it cannot distinguish them, or if the PLR has a fast mechanism to detect a link failure only, but not an egress node failure, the PLR has two options:
- It MAY set up link protection only and leave the egress node failure to be handled by global repair and control-plane convergence.
- It MAY set up egress node protection only and treat a link failure as a trigger for the egress node protection. The assumption is that treating a link failure as an egress node failure MUST NOT have a negative impact on services. Otherwise, it SHOULD adopt the previous option. 🧠
5.3. Protector and PLR
a router gets the "protector" role to protect a tunnel and the services riding on it against an egress node failure. the protector is responsible for hosting a protection service instance for each protected service, acting as the tail end of a bypass tunnel, and doing context label switching and/or context IP forwarding for rerouted service packets 👑
a tunnel is protected by only one protector. multiple tunnels to a given egress router can share a common protector or use different protectors. a protector can protect multiple tunnels with a common egress router or with different egress routers 🦋
for each tunnel, its penultimate hop router acts as a PLR. the PLR pre-establishes a bypass tunnel to the protector and pre-installs bypass forwarding state in the data plane. when it detects an egress node failure, the PLR reroutes all the service packets received on the tunnel through the bypass tunnel to the protector. for MPLS service packets, the PLR keeps service labels intact in the packets. then the protector forwards the service packets towards the ultimate service destinations. specifically, it performs context label switching for MPLS service packets, based on the service labels assigned by the protected egress router, and it performs context IP forwarding for IP service packets, based on their destination addresses 🔀
the protector MUST have its own connectivity with each service destination, via a direct link or a multi-hop path, which MUST NOT traverse the protected egress router or be affected by the egress node failure. this also means that each service destination MUST be dual-homed or have dual paths to the egress router and a backup egress router that may serve as the protector. each protection service instance on the protector relies on that connectivity to set up forwarding state for context label switching and context IP forwarding 💖
5.4. Protected Egress 💖
Okay so this part introduces "protected egress" 🎀, which is a virtual node made of the egress router E of a tunnel plus a protector P. We write it as the ordered pair {E, P} 🦋, and the order tells you the primary-and-protector relationship between the two routers. It's the virtual destination of the tunnel and the virtual location of the service instances carried by that tunnel. The tunnel and services are considered "associated" with {E, P} ✨.
One egress router E can be the tail end of multiple tunnels 🌸. Those tunnels might be protected by multiple protectors (P1, P2, and so on), with each Pi protecting a subset of them. So these routers form multiple protected egresses: {E, P1}, {E, P2}, and so on. Each tunnel is associated with one and only one protected egress {E, Pi}, and all the services carried by that tunnel are automatically associated with {E, Pi} 💅. The reverse is strict too: a service associated with {E, Pi} MUST be carried by a tunnel associated with {E, Pi}. This mapping MUST be ensured by the ingress router of the tunnel and the service (Section 5.5). No exceptions 😭.
Two routers X and Y can be protectors for each other 👯♀️. When they are, they form two distinct protected egresses: {X, Y} and {Y, X}. Iconic 👑.
5.5. Egress-Protected Tunnel and Service 🦄
A tunnel associated with a protected egress {E, P} is called an egress-protected tunnel 🫶. It's associated with one and only one {E, P}, but multiple egress-protected tunnels can be associated with the same {E, P}. They share the common egress router and protector, but they may or may not share a common ingress router or a common PLR (i.e., penultimate hop router) 🙈.
An egress-protected tunnel is logically "destined" for its protected egress {E, P} 🧚. Its path MUST be resolved and established with E as the physical tail end. So physically it ends at E, even though it's logically for the whole pair.
A service associated with a protected egress {E, P} is called an egress-protected service. Egress router E hosts the primary instance of the service, and protector P hosts the protection instance 💜. Again, one and only one protected egress, and multiple services can share the same one. These services share the common egress router and protector, but they may or may not be carried by a common egress-protected tunnel or a common ingress router.
An egress-protected service MUST be mapped to an egress-protected tunnel by its ingress router, based on the common protected egress {E, P} of the service and the tunnel. This is done by introducing a "context ID" for {E, P}, as described in Section 5.7 ✨.
5.6. Egress-Protection Bypass Tunnel 🌈
An egress-protected tunnel destined for a protected egress {E, P} MUST have a bypass tunnel from its PLR to protector P. This is called an egress-protection bypass tunnel 🛡️. The bypass tunnel is considered logically "destined" for {E, P}. Because it's a bypass, it MUST be established with P as the physical tail end and E as the node to avoid 🚧. The bypass tunnel MUST NOT be affected by the topology change caused by an egress node failure, so it MUST contain a property that protects it from this scenario. Big protection energy 💪.
An egress-protection bypass tunnel is associated with one and only one protected egress {E, P}. A PLR may share one egress-protection bypass tunnel across multiple egress-protected tunnels associated with a common protected egress {E, P} 🤝.
5.7. Context ID, Context Label, and Context-Based Forwarding 🔮
In this framework, a globally unique IPv4 or IPv6 address is assigned as the identifier of the protected egress {E, P} 🍓. It's called a "context ID" because of its specific job in context label switching and context IP forwarding on the protector. It's an IP address that is logically owned by both the egress router and the protector. For the egress router, it indicates the protector. For the protector, it indicates the egress router, particularly the egress router's forwarding context. For other routers in the network, it's an address reachable via both the egress router and the protector (Section 5.8), kinda like an anycast address 🌊.
The main purpose of a context ID is to coordinate the ingress router, egress router, PLR, and protector so they can set up egress protection together. Here's how it goes, given an egress-protected service associated with a protected egress {E, P} that has a context ID 📋:
- If the service is an MPLS service, when E distributes a service label binding message to the ingress router, E attaches the context ID to the message. If the service is an IP service, when E advertises the service destination address to the ingress router, E attaches the context ID to the advertisement message. The service protocol chooses how the context ID is encoded in those messages. A protocol extension of a "context ID" object may be needed if there's no existing mechanism for this purpose 📨.
- The ingress router uses the service's context ID as the destination to establish or resolve an egress-protected tunnel, then maps the service onto that tunnel for transport. The semantics of the context ID are transparent to the ingress router. It only treats the context ID as an IP address of E, the same way it handles a regular transport tunnel 🤷♀️.
- The context ID is conveyed to the PLR by the signaling protocol of the egress-protected tunnel, or the PLR learns it via an IGP (i.e., OSPF or IS-IS) or a topology-driven label distribution protocol (e.g., LDP) 📡. The PLR uses the context ID as the destination to establish or resolve an egress-protection bypass tunnel to P while avoiding E.
- P maintains a dedicated label space and a dedicated IP address space for E. They're called "E's label space" and "E's IP address space" 🗂️. P uses the context ID to identify them.
- If the service is an MPLS service, E also distributes the service label binding message to P. This is the same label binding message that E advertises to the ingress router, and it includes the context ID. Based on the context ID, P installs the service label in an MPLS forwarding table corresponding to E's label space. If the service is an IP service, P installs an IP route in an IP forwarding table corresponding to E's IP address space. Either way, the protection service instance on P builds the forwarding state for the label route or IP route based on P's own connectivity with the service's destination 🏗️.
- P assigns a non-reserved label to the context ID. In the data plane, this label represents the context ID and indicates E's label space and IP address space. That's why it's called a "context label" 🏷️.
- The PLR may establish the egress-protection bypass tunnel to P in several manners 🎢:
- If the bypass tunnel is established by RSVP, the PLR signals it with the context ID as the destination, and P binds the context label to the bypass tunnel.
- If the bypass tunnel is established by LDP, P advertises the context label for the context ID as an IP prefix Forwarding Equivalence Class (FEC).
- If the bypass tunnel is established by the PLR in a hierarchical manner, the PLR treats the context label as a one-hop LSP over a regular bypass tunnel to P (e.g., a bypass tunnel to P's loopback IP address).
- If the bypass tunnel is constructed by using Segment Routing, it's represented by a stack of Segment Identifier (SID) labels with the context label as the inner-most SID label (Section 5.9).
- In any case, the bypass tunnel is an ultimate hop-popping (UHP) tunnel whose incoming label on P is the context label.
- During local repair, all the service packets P receives on the bypass tunnel have the context label as the top label. P first pops the context label 🎉. For an MPLS service packet, P looks up the service label in E's label space indicated by the context label. This kind of forwarding is called context label switching. For an IP service packet, P looks up the IP destination address in E's IP address space indicated by the context label. This kind of forwarding is called context IP forwarding 🚀.
5.8. Advertisement and Path Resolution for Context ID ✨
Okay bestie, so path resolution and computation for a context ID happen on ingress routers for egress-protected tunnels, and on PLRs for egress-protection bypass tunnels 💅 Given a protected egress {E, P} and its context ID, E and P MUST coordinate on the reachability of the context ID in the routing domain and the TE domain. The context ID MUST be advertised in such a way that all egress-protected tunnels MUST have E as the tail end, and all egress-protection bypass tunnels MUST have P as the tail end while avoiding E 🫶
This document suggests three approaches 🌈
- Proxy mode 🎀 This one requires E and P, but not the PLR, to know the egress protection schema. E and P advertise the context ID as a virtual proxy node (i.e., a logical node) connected to the two routers. The link between the proxy node and E has more preferable IGP and TE metrics than the link between the proxy node and P. So all egress-protected tunnels destined for the context ID will automatically follow the IGP or TE paths to E. Each PLR stops seeing itself as a penultimate hop and instead sees itself as two hops away from the proxy node, via E. The PLR can find a bypass path via P to the proxy node, even though the bypass tunnel is actually terminated by P. Iconic, no cap 👑
- Alias mode 🦋 This one requires P and the PLR, but not E, to know the egress protection schema. E simply advertises the context ID as an IP address. P advertises the context ID and the context label by using a "context ID label binding" advertisement. In both the routing domain and the TE domain, the context ID is only reachable via E. So all egress-protected tunnels destined for the context ID will have E as the tail end. Based on the "context ID label binding" advertisement, the PLR can establish an egress-protection bypass tunnel in several manners (Section 5.9). The "context ID label binding" advertisement is defined as the IGP Mirroring Context segment in [RFC8402] and [RFC8667]. These IGP extensions are generic in nature and hence can be used for egress protection purposes. It is RECOMMENDED that a similar advertisement be defined for OSPF as well 🧚
- Stub link mode 💜 In this mode, both E and P advertise the context ID as a link to a stub network, which basically models the context ID as an anycast IP address owned by the two routers. E, P, and the PLR do not need to know the egress protection schema. The correctness of the egress-protected tunnels and the bypass tunnels relies on the path computations for the anycast IP address performed by the ingress routers and PLR. So care MUST be taken for the applicability of this approach to a network. Not me being dramatic, but this one needs real thought 💀
This framework treats the above approaches as technically equal. Whether each one works in a given network depends on the topology, manageability, and available protocols of that network 🌸 For a given context ID, all relevant routers, including the primary PE, protector, and PLR, MUST support and agree on the chosen approach. The coordination between these routers can be achieved by configuration.
In a scenario where an egress-protected tunnel is an inter-area or inter-Autonomous-System (inter-AS) tunnel, its associated context ID MUST be propagated by IGP or BGP from the original area or AS to the area or AS of the ingress router. The propagation process of the context ID SHOULD be the same as that of an IP address in an inter-area or inter-AS environment ✨
5.9. Egress-Protection Bypass Tunnel Establishment 🔥
A PLR MUST know the context ID of a protected egress {E, P} in order to establish an egress-protection bypass tunnel. The information is obtained from the signaling or label distribution protocol of the egress-protected tunnel. The PLR may or may not need to know the egress-protection schema. All it does is set up a bypass tunnel to a context ID while avoiding the next-hop router (i.e., egress router). This is achievable by using a constraint-based computation algorithm, similar to those commonly used for traffic engineering paths and Loop-Free Alternate (LFA) paths. Since the context ID is advertised in the routing domain and in the TE domain by IGP according to Section 5.8, the PLR is able to resolve or establish such a bypass path with the protector as the tail end. In the case of proxy mode, the PLR may do so in the same manner as transit node protection.
An egress-protection bypass tunnel may be established via several methods:
- It may be established by a signaling protocol (e.g., RSVP), with the context ID as the destination. The protector binds the context label to the bypass tunnel.
- It may be formed by a topology-driven protocol (e.g., LDP with various LFA mechanisms). The protector advertises the context ID as an IP prefix FEC, with the context label bound to it.
- It may be constructed as a hierarchical tunnel. When the protector uses the alias mode (Section 5.8), the PLR will know the context ID, context label, and protector (i.e., the advertiser). The PLR can then establish the bypass tunnel in a hierarchical manner, with the context label as a one-hop LSP over a regular bypass tunnel to the protector's IP address (e.g., loopback address). This regular bypass tunnel may be established by RSVP, LDP, Segment Routing, or another protocol 🍓
5.10. Local Repair on PLR 🌷
In this framework, a PLR is agnostic to services and service labels. That means there's no need to maintain bypass forwarding state on a per-service basis, and bypass tunnels can be shared between egress-protected tunnels, which is so efficient 🤌 The PLR may share an egress-protection bypass tunnel for multiple egress-protected tunnels associated with a common protected egress {E, P}. During local repair, the PLR reroutes all service packets received on the egress-protected tunnels to the egress-protection bypass tunnel. Service labels remain intact in MPLS service packets.
The label operation performed by the PLR depends on the bypass tunnel's characteristics:
- If the bypass tunnel is a single level tunnel, the rerouting involves swapping the incoming label of an egress-protected tunnel to the outgoing label of the bypass tunnel.
- If the bypass tunnel is a hierarchical tunnel, the rerouting involves swapping the incoming label of an egress-protected tunnel to a context label and pushing the outgoing label of a regular bypass tunnel.
- If the bypass tunnel is constructed by Segment Routing, the rerouting involves swapping the incoming label of an egress-protected tunnel to a context label and pushing the stack of SID labels of the bypass tunnel.
5.11. Service Label Distribution from Egress Router to Protector 💖
When a protector receives a rerouted MPLS service packet, it performs context label switching based on the packet's service label, which is assigned by the corresponding egress router. To make this work, the protector MUST maintain the labels of egress-protected services in dedicated label spaces on a per-protected-egress {E, P} basis, i.e., one label space for each egress router that it protects.
Also, there MUST be a service label distribution protocol session between each egress router and the protector. Through this protocol, the protector learns the label binding of each egress-protected service. This is the same label binding that the egress router advertises to the service's ingress router, which includes a context ID. The corresponding protection service instance on the protector recognizes the service and resolves forwarding state based on its own connectivity with the service's destination. It then installs the service label with the forwarding state in the label space of the egress router, which is indicated by the context ID (i.e., context label).
Different service protocols may use different mechanisms for this kind of label distribution. Specific extensions may be needed on a per-protocol or per-service-type basis. The details of the extensions should be specified in separate documents. As an example, the LDP extensions for pseudowire services are specified in [RFC8104] 🦋
5.12. Centralized Protector Mode 🏰
okay bestie, so in this framework we assume that the service destination of an egress-protected service MUST be dual-homed to two edge routers of an MPLS network 🌸 One is the protected egress router and the other is a backup egress router. So far, we've mostly been talking about the setup where a protector and a backup egress router are squished together into one router 🫶 That means the number of protectors in the network is equal to the number of backup egress routers. But there's another vibe too: a network can pick a small number of routers to be dedicated protectors, with each one covering a subset of egress routers. These are called centralized protectors ✨
Topologically, a centralized protector can be totally decoupled from all the backup egress routers, or it can be co-located with one backup egress router and decoupled from the rest 🦋 The procedures in this section assume that a protector and a backup egress router are decoupled.
services 1, ..., N
=====================================> tunnel
I ------ R1 ------- PLR --------------- E ----
ingress penultimate hop egress \
| . (primary \
| . service \
| . instances) \
| . \
| . bypass \ service
R2 . tunnel destinations
| . / (CEs, sites)
| . /
| . /
| . /
| . tunnel /
| =============> /
P ---------------- E' ---
protector backup egress
(protection (backup
service service
instances) instances)
Figure 2Like a co-located protector, a centralized protector hosts protection service instances, receives rerouted service packets from PLRs, and does context label switching and/or context IP forwarding 💅 For each service, the protector MUST send the packets through another transport tunnel to the matching backup service instance on a backup egress router, instead of sending them straight to the service destination. Then the backup service instance forwards the service packets on to the service destination 🎀 If the service is an MPLS service, the protector MUST swap the service label in each received service packet to the label of the backup service that the backup egress router advertised, and then push the label (or label stack) of the transport tunnel 🧚
Now, for a centralized protector to map an egress-protected MPLS service to a service hosted on a backup egress router, there MUST be a service label distribution protocol session between the backup egress router and the protector 🍓 Over this session, the backup egress router advertises the service label of the backup service, attached with the FEC of the egress-protected service and the context ID of the protected egress {E, P}. With that info, the protector links the egress-protected service to the backup service, resolves or sets up a transport tunnel to the backup egress router, and builds forwarding state for the label of the egress-protected service in the label space of the egress router 💜
The service label that the backup egress router advertises to the protector can be the same as the label it advertises to the ingress router(s), but only if the forwarding state of that label does not direct service packets toward the protected egress router 🙈 Otherwise the label MUST NOT be used for egress protection, because it would create a loop for the service packets 💀 In that case, the backup egress router MUST advertise a unique service label for egress protection and set up the forwarding state of that label to use the backup egress router's own connectivity with the service destination 😭
6. Egress Link Protection 🔗
Egress link protection can be achieved with procedures that are similar to egress node protection ✨ In normal situations, an egress router forwards service packets to a service destination based on a service label, and that label's forwarding state points to an egress link. For egress link protection, the egress router acts as the PLR and does the local failure detection and local repair itself 💖 Specifically, the egress router pre-establishes an egress-protection bypass tunnel to a protector and sets up the bypass forwarding state for the service label so it points to that bypass tunnel. During local repair, the egress router reroutes service packets through the bypass tunnel to the protector. The protector then forwards the packets to the service destination (in the co-located protector mode, as shown in Figure 3) or forwards them to a backup egress router (in the centralized protector mode, as shown in Figure 4) 🦋
service
=====================================> tunnel
I ------ R1 ------- R2 --------------- E ----
ingress | ............. egress \
| . PLR \
| . (primary \
| . service \
| . instance) \
| . \
| . bypass service
| . tunnel destination
| . / (CE, site)
| . /
| . /
| . /
| . /
| ............... /
R3 --------------- P ----
protector
(protection
service
instance)
Figure 3 service
=====================================> tunnel
I ------ R1 ------- R2 --------------- E ----
ingress | ............. egress \
| . PLR \
| . (primary \
| . service \
| . instance) \
| . \
| . bypass service
| . tunnel destination
| . / (CE, site)
| . /
| . /
| . /
| . tunnel /
| =============> /
R3 --------------- P ----
protector backup egress
(protection (backup
service service
instance) instance)
Figure 4There are two ways to set up the bypass forwarding state on the egress router, and which one you use depends on whether the egress router knows the service label that the backup egress router allocated 🌈 The big difference is that one approach makes the protector do context label switching, and the other one doesn't. Both approaches are equally supported by this framework 👑
- The first approach applies when the egress router does not know the service label allocated by the backup egress router. In this case, the egress router sets up the bypass forwarding state as a label push with the outgoing label of the egress-protection bypass tunnel. Rerouted packets keep the egress router's service label intact 🧚 So the protector MUST perform context label switching, and the bypass tunnel MUST be destined for the context ID of the protected egress {E, P} and established as described in Section 5.9. This approach is consistent with egress node protection 💅 That means a protector can serve in egress node protection and egress link protection in a consistent way, and both the co-located protector mode and the centralized protector mode are supported (see Figures 3 and 4) ✨
- The second approach applies when the egress router knows the service label allocated by the backup egress router, via a label distribution protocol session. In this case, the backup egress router serves as the protector for egress link protection, no matter who the protector is for egress node protection. That one will be the same router in the co-located protector mode, but a different router in the centralized protector mode 🍓 The egress router sets up the bypass forwarding state as a label swap from the incoming service label to the service label of the backup egress router (that is, the protector), followed by a push with the outgoing label (or label stack) of the egress link protection bypass tunnel. The bypass tunnel is a regular tunnel destined for an IP address of the protector, instead of the context ID of the protected egress {E, P}. The protector just forwards rerouted service packets based on its own service label, rather than doing context label switching 🫶 With this approach, only the co-located protector mode applies 🙈
Note that for a bidirectional service, the physical link of an egress link may carry service traffic in both directions 🔥 So an egress link failure might also be an ingress link failure for the traffic going the other way. Protection for ingress link failure SHOULD be provided by a separate mechanism, so it's out of scope for this document 😭
7. Global Repair 🌈
This framework gives you a fast but temporary repair for egress node and egress link failures ⭐ For a permanent fix, the services affected by a failure SHOULD be moved to an alternative tunnel, or replaced by alternative services that are fully functional. This is called global repair 👑 Possible triggers for global repair include control-plane notifications of tunnel status and service status, end-to-end OAM and fault detection at the tunnel and service level, and others 💖 The alternative tunnel and services can be pre-established in standby state, or dynamically established as a result of the triggers or network protocol convergence 🦋
8. Operational Considerations ✨
okay bestie, so when a PLR does local repair, the router SHOULD generate an alert for that event 🚨 It can log the alert locally so you can keep track of stuff, or send it up to the operator at a management station 🧚 How the PLR and the management station talk to each other can change depending on the network, and that's totally out of scope for this doc 💅
9. General Context-Based Forwarding 🌸
so far this doc has been all about cases where the service packets are MPLS or IP packets, and protectors do context label switching or context IP forwarding 💖 That covers most of the common services, but the framework also works for services (or sub-modes of services) where the service packets are Layer 2 packets or wrapped in non-IP and non-MPLS formats 🦋 The only special thing for these cases is that a protector MUST perform context-based forwarding based on the Layer 2 table or the corresponding lookup table, and that's indicated by a context ID (aka the context label) 🫶
10. Example: Layer 3 VPN Egress Protection 🎀
okay this section is a full example of egress protection for Layer 3 IPv4 and IPv6 VPNs, and it's giving real-world vibes 👑
---------- R1 ----------- PE2 -
/ (PLR) (PLR) \
( ) / | | ( )
( ) / | | ( )
( site 1 )-- PE1 < | R3 ( site 2 )
( ) \ | | ( )
( ) \ | | ( )
\ | | /
---------- R2 ----------- PE3 -
(protector)Figure 5 🧚
so in this setup the core network is IPv4 and MPLS 🌈 Both the IPv4 and IPv6 VPNs have sites 1 and 2. Site 1 hangs off PE1, and site 2 is dual-homed to PE2 and PE3 💜 Site 1 has the IPv4 subnet 203.0.113.64/26 and the IPv6 subnet 2001:db8:1:1::/64. Site 2 has the IPv4 subnet 203.0.113.128/26 and the IPv6 subnet 2001:db8:1:2::/64 ✨ PE2 is the primary PE for site 2, and PE3 is the backup 🔥 Each of PE1, PE2, and PE3 hosts an IPv4 VPN instance and an IPv6 VPN instance. The PEs use BGP to swap VPN prefixes and VPN labels with each other 💅 In the core, R1 and R2 are transit routers, OSPF is the routing protocol, and RSVP-TE is the tunnel signaling protocol 🦋
using the framework from this doc, the network makes PE3 the protector of PE2, so it protects the VPN traffic going from site 1 to site 2 💖 This is the co-located protector mode 🫶 PE2 and PE3 form a protected egress {PE2, PE3}, and the context ID 198.51.100.1 is assigned to that protected egress 🌸 (If the core network is IPv6, the context ID would be an IPv6 address instead, iykyk 🙈) The IPv4 and IPv6 VPN instances on PE3 act as protection instances for the matching VPN instances on PE2 ✨ On PE3, context label 100 gets assigned to the context ID, and a label table called pe2.mpls is created to represent PE2's label space 👑 PE3 installs label 100 in its MPLS forwarding table, with the next hop pointing at the label table pe2.mpls 💜 PE2 and PE3 are coordinated to use the proxy mode to advertise the context ID in the routing domain and the TE domain 🌈
PE2 uses the per-VRF label allocation mode for both its IPv4 and IPv6 VPN instances 🎀 It assigns label 9000 to the IPv4 VRF and label 9001 to the IPv6 VRF. For the IPv4 prefix 203.0.113.128/26 in site 2, PE2 advertises it with label 9000 and NEXT_HOP 198.51.100.1 to PE1 and PE3 over BGP 💖 Same deal for the IPv6 prefix 2001:db8:1:2::/64 in site 2: PE2 advertises it with label 9001 and NEXT_HOP 198.51.100.1 to PE1 and PE3 over BGP 🦋
PE3 also uses per-VRF VPN label allocation mode for both its IPv4 and IPv6 VPN instances 🧚 It assigns label 10000 to the IPv4 VRF and label 10001 to the IPv6 VRF. For the prefix 203.0.113.128/26 in site 2, PE3 advertises it with label 10000 and NEXT_HOP as itself to PE1 and PE2 over BGP ✨ For the IPv6 prefix 2001:db8:1:2::/64 in site 2, PE3 advertises it with label 10001 and NEXT_HOP as itself to PE1 and PE2 over BGP 🌸
when PE1 gets those BGP advertisements from PE2, it uses the context ID 198.51.100.1 as the destination to compute a path for an egress-protected tunnel 🔥 The path it comes up with is PE1->R1->PE2. PE1 then uses RSVP to signal the tunnel, with the context ID 198.51.100.1 as the destination, and it sets the "node protection desired" flag in the SESSION_ATTRIBUTE of the RSVP Path message 💅 Once the tunnel is up, PE1 maps the VPN prefixes 203.0.113.128/26 and 2001:db8:1:2::/64 to the tunnel and installs a route for each prefix in the matching IPv4 or IPv6 VRF 🫶 The next hop for route 203.0.113.128/26 is a push of the VPN label 9000, followed by a push of the outgoing label of the egress-protected tunnel 💖 The next hop for route 2001:db8:1:2::/64 is a push of the VPN label 9001, followed by a push of the outgoing label of the egress-protected tunnel 👑
when PE3 gets those same BGP advertisements from PE2, it recognizes the context ID 198.51.100.1 in the NEXT_HOP attribute and installs a route for label 9000 and a route for label 9001 in the label table pe2.mpls 🌈 PE3 sets the next hop of route 9000 to the IPv4 protection VRF, and the next hop of route 9001 to the IPv6 protection VRF 🎀 The IPv4 protection VRF has the routes to the IPv4 prefixes in site 2. The IPv6 protection VRF has the routes to the IPv6 prefixes in site 2 🦋 The next hops of these routes must be based on PE3's connectivity with site 2, even if that connectivity doesn't have the best metrics (e.g., Multi-Exit Discriminator (MED), local preference, etc.) that PE3's own VRF would use 🧚 The next hops must not use any path traversing PE2. Note that the protection VRFs are a logical concept, and they may simply be PE3's own VRFs if those satisfy the requirement 🌸
10.1. Egress Node Protection 💜
R1 is the penultimate hop router of the egress-protected tunnel, so it serves as the PLR for egress node protection 🔥 Based on the "node protection desired" flag and the tunnel's destination address (the context ID 198.51.100.1), R1 computes a bypass path to 198.51.100.1 that avoids PE2 ✨ The resulting bypass path is R1->R2->PE3. R1 then signals that path (the egress-protection bypass tunnel) with 198.51.100.1 as the destination 💖
when PE3 gets an RSVP Path message for the egress-protection bypass tunnel, it recognizes the context ID 198.51.100.1 as the destination and answers with context label 100 in an RSVP Resv message 🫶
once the egress-protection bypass tunnel is up, R1 installs a bypass next hop for the egress-protected tunnel 🦋 That bypass next hop is a label swap from the incoming label of the egress-protected tunnel to the outgoing label of the egress-protection bypass tunnel 🌈
when R1 detects that PE2 has failed, it invokes that bypass next hop to reroute the VPN packets 🚨 Each IPv4 VPN packet has the label of the bypass tunnel as its outer label and the IPv4 VPN label 9000 as its inner label. Each IPv6 VPN packet has the label of the bypass tunnel as its outer label and the IPv6 VPN label 9001 as its inner label 💅 When the packets arrive at PE3, they have the context label 100 as the outer label and the VPN label 9000 or 9001 as the inner label. The context label gets popped first, then the VPN label is looked up in the label table pe2.mpls 🎀 That lookup pops the VPN label, and the IPv4 and IPv6 packets get forwarded to site 2 based on the IPv4 and IPv6 protection VRFs, respectively 👑
10.2. Egress Link Protection 🌸
PE2 is the PLR for egress link protection 🧚 It has already learned PE3's IPv4 VPN label 10000 and IPv6 VPN label 10001. So it uses approach (2) as described in Section 6 to set up the bypass forwarding state ✨ It signals an egress-protection bypass tunnel to PE3 by using the path PE2->R3->PE3, with PE3's IP address as the destination 💖 After the bypass tunnel comes up, PE2 installs a bypass next hop for the IPv4 VPN label 9000 and another for the IPv6 VPN label 9001 🦋 For label 9000, the bypass next hop is a label swap to label 10000, followed by a label push with the outgoing label of the bypass tunnel. For label 9001, the bypass next hop is a label swap to label 10001, followed by a label push with the outgoing label of the bypass tunnel 🫶
when PE2 detects that the egress link has failed, it invokes the bypass next hop above to reroute the VPN packets 🚨 Each IPv4 VPN packet has the label of the bypass tunnel as its outer label and label 10000 as its inner label. Each IPv6 VPN packet has the label of the bypass tunnel as its outer label and label 10001 as its inner label 🌈 When the packets arrive at PE3, the VPN label 10000 or 10001 gets popped, and the exposed IPv4 or IPv6 packets get forwarded based on PE3's IPv4 and IPv6 VRFs, respectively 💅
10.3. Global Repair 🎀
eventually global repair kicks in, as the control-plane protocols converge on the new topology 👑 PE1 will pick PE3 as its new entrance to site 2 🌸 Until that happens, the VPN traffic is already protected by the local repair above 💜
10.4. Other Modes of VPN Label Allocation 🧚
it's also possible that PE2 uses per-route or per-interface VPN label allocation mode instead ✨ Either way, PE3 ends up with multiple VPN label routes in the pe2.mpls table, one for each VPN label PE2 advertises 💖 PE3 forwards the rerouted packets by popping a VPN label and doing an IP lookup in the matching protection VRF 🦋 That's consistent with the case above where PE2 uses per-VRF VPN label allocation mode 🫶 PE3 doesn't need to know PE2's VPN label allocation mode, and it doesn't need to build a specific next hop for each VPN label route in the pe2.mpls table 🌈
11. IANA Considerations 🌈
this document has no IANA actions 💅
12. Security Considerations 🔐
Okay so this framework is basically about rerouting traffic when an egress node or link goes down. The traffic takes a bypass path from a PLR to a protector, and then ends up at a backup egress router. ✨ The data plane forwarding is expected, since it's already part of planning the egress protection. 🎀
Control-plane protocols MAY be used to help set up the egress protection on the routers. 💅 The big thing is that the framework requires a service label distribution protocol between an egress router and a protector over a secure session. 🔥 How secure all this provisioning and label distribution is depends entirely on whichever underlying protocol gets picked to do it. Those protocols' own security considerations apply, and this framework adds no new security requirements or guarantees on top of them. 🫶
Also, the PLR, protector, and backup egress router are all sitting close to the protected egress router, which is usually in the same administrative domain. 🏠 If they're not in the same domain, a certain level of trust MUST be established between them so the protocols can run securely across the domain boundary. 🚨 The basis for that trust is the security model of the protocols (as described above). Further security considerations for inter-domain scenarios should be handled by the protocols as a common requirement. 💜
Security attacks can sometimes come from a customer domain. 😭 This framework doesn't introduce those attacks, and they might happen whether or not egress protection exists. One possible case is the egress link between an egress router and a CE, which could become a point of attack. An attacker who takes control of the CE could use it to fake link failures and set off constant, cascading activity in the network. 💀 If egress link protection is in place, those egress link protection activities can get triggered too. The general fix is a damping mechanism, which SHOULD be used by the egress router to quickly shut down the services tied to the link or CE. 🛑 The egress router would stop advertising those services, basically detaching them from the network so the fake link failures stop having any effect. 🙅♀️
So overall, from all of these angles, this framework does not introduce any new security threat to networks. 🌸👑
13. References 📚
13.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>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8667] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Gredler, H., and B. Decraene, "IS-IS Extensions for
Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December
2019, <https://www.rfc-editor.org/info/rfc8667>.13.2. Informative References
[BGP-PIC] Bashandy, A., Filsfils, C., and P. Mohapatra, "BGP Prefix
Independent Convergence", Work in Progress, Internet-
Draft, draft-ietf-rtgwg-bgp-pic-10, 2 October 2019,
<https://tools.ietf.org/html/draft-ietf-rtgwg-bgp-pic-10>.
[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>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>.
[RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
RFC 7490, DOI 10.17487/RFC7490, April 2015,
<https://www.rfc-editor.org/info/rfc7490>.
[RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-
FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
<https://www.rfc-editor.org/info/rfc7812>.
[RFC8104] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang,
"Pseudowire (PW) Endpoint Fast Failure Protection",
RFC 8104, DOI 10.17487/RFC8104, March 2017,
<https://www.rfc-editor.org/info/rfc8104>.
[RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang,
"Extensions to RSVP-TE for Label Switched Path (LSP)
Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June
2018, <https://www.rfc-editor.org/info/rfc8400>.Acknowledgements 🫶
This document builds on work done by Yakov Rekhter, Kevin Wang, and Zhaohui Zhang on MPLS egress protection. 🧚 Huge thanks to Alexander Vainshtein, Rolf Winter, Lizhong Jin, Krzysztof Szarkowicz, Roman Danyliw, and Yuanlong Jiang for their valuable comments, which helped shape this document and make it clearer. 💖
Authors' Addresses 🦋
Yimin Shen
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
United States of America
Phone: +1 978 589 0722
Email: yshen@juniper.net
Minto Jeyananth
Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
United States of America
Phone: +1 408 936 7563
Email: minto@juniper.net
Bruno Decraene
Orange
Email: bruno.decraene@orange.com
Hannes Gredler
RtBrick Inc.
Email: hannes@rtbrick.com
Carsten Michel
Deutsche Telekom
Email: c.michel@telekom.de
Huaimo Chen
Futurewei
Boston, MA
United States of America
Email: Huaimo.chen@futurewei.com📦 where this page comes from
- ietf: rfc8679 2019-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms