RFC 7490
Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)
RFC 7490 💖 Remote Loop-Free Alternate (LFA) Fast Reroute (FRR) 🦋
Okay bestie, this is RFC 7490, an IETF Internet Standards Track doc from April 2015 📅. It's published under ISSN 2070-1721 ✨. The authors are S. Bryant, C. Filsfils, and S. Previdi from Cisco Systems, plus M. Shand (Independent Contributor) and N. So from Vinci Systems 👑. The title block doesn't list anything it obsoletes or updates, so it stands on its own 🌸.
Abstract
okay so the vibe here is an extension to the basic IP fast reroute mechanism from RFC 5286 🔥. It gives you extra backup connectivity for point-to-point link failures in the situations where the basic mechanisms can't cover it at all 💅.
Status of This Memo
This is an Internet Standards Track document 🎀. It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want more on Internet Standards, check Section 2 of RFC 5741 📖.
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7490 🌈.
Copyright Notice
Copyright (c) 2015 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 (http://trustee.ietf.org/license-info), as in effect on the date of publication 📜. Please read these carefully, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Simplified BSD License 💀.
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Overview of Solution . . . . . . . . . . . . . . . . . . . . 4
4. Repair Paths . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Tunnels as Repair Paths . . . . . . . . . . . . . . . . . 6
4.2. Tunnel Requirements . . . . . . . . . . . . . . . . . . . 7
5. Construction of Repair Paths . . . . . . . . . . . . . . . . 8
5.1. Identifying Required Tunneled Repair Paths . . . . . . . 8
5.2. Determining Tunnel Endpoints . . . . . . . . . . . . . . 8
5.2.1. Computing Repair Paths . . . . . . . . . . . . . . . 9
5.2.2. Selecting Repair Paths . . . . . . . . . . . . . . . 11
5.3. A Cost-Based RLFA Algorithm . . . . . . . . . . . . . . . 12
5.4. Interactions with IS-IS Overload, RFC 6987, and Costed
Out Links . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Example Application of Remote LFAs . . . . . . . . . . . . . 17
7. Node Failures . . . . . . . . . . . . . . . . . . . . . . . . 18
8. Operation in an LDP Environment . . . . . . . . . . . . . . . 19
9. Analysis of Real World Topologies . . . . . . . . . . . . . . 21
9.1. Topology Details . . . . . . . . . . . . . . . . . . . . 21
9.2. LFA Only . . . . . . . . . . . . . . . . . . . . . . . . 22
9.3. RLFA . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.4. Comparison of LFA and RLFA results . . . . . . . . . . . 24
10. Management and Operational Considerations . . . . . . . . . . 25
11. Historical Note . . . . . . . . . . . . . . . . . . . . . . . 25
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 26
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 291. Introduction ✨
Okay so RFC 5714 [RFC5714] is the framework for IP Fast Reroute (IPFRR), and it sums up a bunch of the IPFRR solutions people have proposed 📚. The basic move is Loop-Free Alternates (LFAs), described in [RFC5286] 🔥. It gives really good repair coverage in lots of topologies [RFC6571], especially the highly meshed ones 💖. But some topologies, like ring-based ones, aren't well protected by LFAs alone 😭. That's because none of the Point of Local Repair (PLR)'s neighbors have a cost to the destination that avoids the failure and is cheaper than the cost through the failure 💀. Main character problem, honestly.
This document extends the LFA approach from [RFC5286] to cover a lot of those cases 🦋. The trick is to tunnel the packets that need IPFRR over to a node that is both reachable from the PLR and able to reach the destination 🧚.
2. Terminology 💅
This document uses the terms defined in [RFC5714] 📖. This section defines a few more terms that show up in the doc ✨.
Repair tunnel: A tunnel set up to give you a virtual neighbor that is a Loop-Free Alternate 🎀.
P-space: The P-space of a router with respect to a protected link is the set of routers that router can reach over its pre-convergence shortest paths, without any of those paths (including equal-cost path splits) going through that protected link 🌸.
For example, the P-space of S with respect to link S-E is the set of routers that S can reach without using the protected link S-E 🍓.
Extended P-space: Take the set of neighbors of a router that's protecting a link 🫶. Remove the router reachable over the protected link from that set 🙈. The extended P-space of the protecting router, with respect to the protected link, is the union of the P-spaces of the neighbors left in that set, with respect to the protected link (see Section 5.2.1.2) 🔥.
Q-space: The Q-space of a router with respect to a protected link is the set of routers from which that specific router can be reached without any path (including equal-cost path splits) going through that protected link 💜.
PQ node: A PQ node of a node S with respect to a protected link S-E is a node that's in both the P-space (or the extended P-space) of S for that protected link S-E, AND the Q-space of E for that same protected link 👑. A repair tunnel endpoint gets picked from the set of PQ-nodes ✨.
Remote LFA (RLFA): Using a PQ node, instead of a neighbor of the repairing node, as the next hop in an LFA repair [RFC5286] 🌈.
Quick notation check 🧚: in this document, X-Y means the path from X to Y over the link that directly connects X and Y. X->Y means the shortest path from X to Y through some set of unspecified nodes, and that set can be empty (so it includes a direct link between X and Y) 💖.
2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🫶. (These are the official key words, so they stay in caps 😭.)
3. Overview of Solution 🦋
okay so the LFA IPFRR reachability problem in some networks is best shown with this tiny network fragment 🧚
S---E
/ \
A D
\ /
B---C
Figure 1: A Simple Ring Topologyif every link cost is equal, traffic going across link S-E can't be fully protected by LFAs 😭. C is an Equal-Cost Multipath (ECMP) from S, so traffic to C is protectable when S-E fails, but traffic to D and E is NOT protectable using LFAs 💔.
this doc extends the basic repair mechanism with tunnels ✨. the tunnels give you extra logical links that can work as loop-free alternates, even where the original topology has none 🌸. in Figure 1, S can reach A, B, and C without going via S-E, so those form S's extended P-space with respect to S-E. the routers that can reach E without going through S-E are in E's Q-space with respect to link S-E, and those are D and C. B has equal-cost paths to E via B-A-S-E and B-C-D-E, so the forwarder at S might send a packet to E via link S-E. that means B is NOT in E's Q-space with respect to link S-E 🙈. the only node in both S's extended P-space and E's Q-space is C, so C gets picked as the repair tunnel's endpoint 👑. if you build a tunnel between S and C like in Figure 2, then C (now a direct neighbor of S) becomes an LFA for D and E 🎀. the definitions of (extended) P-space and Q-space are in Section 2, and the details of how the tunnel endpoints get calculated are in Section 5.2 💅.
S---E
/ \ \
A \ D
\ \ /
B---C
Figure 2: The Addition of a Tunnelthe non-failure traffic distribution isn't disrupted by this tunnel, because it's only used for repair traffic and MUST NOT be used for normal traffic 🫶. Operations, Administration, and Maintenance (OAM) traffic that's used specifically to check the repair is viable MAY cross the tunnel before a failure happens 🔥.
this technique isn't limited to ring topologies. it's a general mechanism for boosting the protection LFAs already give you 🌈. Section 9 studies how much protection remote LFA gets in typical service provider core networks, and Section 9.4 has a side-by-side comparison of LFA and remote LFA ⭐.
remote LFA can be deployed incrementally across a network, even one that's already running LFA 💜. computing the repair path needs acceptable CPU resources, and it happens entirely on the repairing node 🍓. in MPLS networks, the targeted LDP protocol needed to learn the label binding at the repair tunnel endpoint (Section 8) is a well understood and widely deployed technology 💖.
this technique is aimed at link failures. node failures are covered in Section 7 🙈. this memo solves the case where the failure happens on a point-to-point link. it also covers the case where the repair first hop is reached over a broadcast or non-broadcast multi-access (NBMA) link like a LAN, and the case where the P or Q node is attached through one of those links. what it does NOT cover is the more complicated case where the failed interface is itself a broadcast or NBMA link 💀.
this document only considers the case where the repair path stays inside a single area or inside the level two routing domain. in all other cases, the chosen PQ node should be regarded as a tunnel adjacency of the repairing node, and the considerations in Section 6 of [RFC5286] should be taken into account 📚.
4. Repair Paths 🌸
same as LFA FRR, when a router detects a failure on an adjacent link, it uses one or more repair paths in place of the failed link ⚡. repair paths are precomputed in anticipation of later failures, so they can be activated quickly once a failure is detected 🏃♀️.
a tunneled repair path sends traffic to some staging point in the network. from that point, as long as no worse-than-anticipated failure happens, the traffic goes to its destination using normal forwarding without looping back 🔁. that's basically a virtual loop-free alternate supplementing the physical ones, which is where the name "remote LFA FRR" comes from 🎀. in its simplest form, when a link can't be fully protected by local LFA neighbors, the protecting router asks a remote LFA staging point for help 🫶. network manageability considerations may push a repair strategy to use a remote LFA more often [LFA-MANAGE] 📋.
worse failures include node failures (see Section 7), failure of a Shared Risk Link Group (SRLG), independent concurrent failures of multiple links, or failures of broadcast or NBMA links (Section 3). protecting against these is out of scope for this specification 🚫.
4.1. Tunnels as Repair Paths 🦋
take any protected link S-E. in LFA FRR, if a path to the destination from a neighbor N of S doesn't make a packet loop back over link S-E (meaning N is a loop-free alternate), then S can send the packet to N, and the packet gets delivered to the destination using the pre-failure forwarding information 💅. if there's no such LFA neighbor, S might be able to create a virtual LFA by using a tunnel to carry the packet to a point in the network that isn't a direct neighbor of S. from there, the packet gets delivered to the destination without looping back to S ✨. this document calls that tunnel a repair tunnel 🌈. the tail end of the tunnel (the repair tunnel endpoint) is a "PQ node", and the repair mechanism is a "remote LFA" 💜. this tunnel MUST NOT traverse the link S-E ⛔.
notice that the repair tunnel ends at some intermediate router between S and E, not at E itself 🙈. that makes total sense, because if you could build a tunnel from S to E, a conventional LFA would already be enough to do the repair 🧠.
4.2. Tunnel Requirements 💖
there are a bunch of IP-in-IP tunnel mechanisms that can meet the requirements of this design, like IP-in-IP [RFC1853] and Generic Routing Encapsulation (GRE) [RFC1701] 🎀.
in an MPLS-enabled network that uses LDP [RFC5036], a simple label stack [RFC3032] can give you the repair tunnel you need 🧚. the outer label is S's neighbor's label for the repair tunnel endpoint, and the inner label is the repair tunnel endpoint's label for the packet destination 🏷️. for S to get the right inner label, it has to set up a targeted LDP session [RFC5036] to the tunnel endpoint 🤝.
which specific tunneling mechanism gets used (and any enhancements it needs) is outside the scope of this document 🙅♀️. the MPLS/LDP deployment is pretty simple on the data plane, since an LDP Label Switched Path (LSP) from S to the repair tunnel endpoint (the selected PQ node) is already readily available. no new protocol extension or design change is needed, because that LSP gets set up automatically as a basic property of LDP behavior 🦋. encapsulation and decapsulation are efficient: encapsulating is just pushing one label (like conventional MPLS-TE FRR), and decapsulation is normally configured to happen at the penultimate hop before the repair tunnel endpoint 🍓. on the control plane, a Targeted LDP (TLDP) session is needed between the repairing node and the repair tunnel endpoint 🛠️. that session has to be established and the labels processed before the tunnel can be used, and the time that takes limits how fast a new tunnel can go into service ⏳. this usually isn't a problem in normal operation, since managed introduction and removal of links is pretty rare, and failures are rare in a well-managed network 😌.
when a failure is detected, traffic has to be redirected to the repair path immediately 🚨. so the repair tunnel MUST be provisioned beforehand in anticipation of the failure 📦. since the location of repair tunnels is determined dynamically, the repair tunnels have to be established automatically 🤖. multiple repair tunnels can share a tunnel endpoint 🫂.
5. Construction of Repair Paths 🏗️
5.1. Identifying Required Tunneled Repair Paths 🔍
not every link needs protection with a tunneled repair path 🙅♀️. look at Figure 1: if E can already be protected via an LFA, then S-E doesn't need a repair tunnel, because every destination normally reachable through E must also be protectable by an LFA. that kind of LFA is often called a "link LFA" 💫. tunneled repair paths (which may be calculated per prefix) are only needed for links that don't have a link or per-prefix LFA 🎯.
it's worth knowing that using E's Q-space as a stand-in for the Q-space of each destination can make you miss valid remote LFAs 👀. how much that cuts down the effective protection coverage depends on the topology 🕸️.
5.2. Determining Tunnel Endpoints 💜
the repair tunnel endpoint has to be a node in the network that's reachable from S without traversing S-E ✨. the endpoint also has to be a node that packets will normally flow through toward their destination, without getting attracted back to the failed link S-E 🧲.
once a packet is released from the tunnel, it gets forwarded as normal, along the shortest path from the release point to its destination 🛤️. that might mean the packet goes through router E at the far end of the protected link S-E, but that's obviously not required 🙃.
the properties that repair tunnel endpoints must have are:
- The repair tunneled point MUST be reachable from the tunnel source without traversing the failed link; and
- when released from the tunnel, packets MUST proceed towards their destination without being attracted back over the failed link.
if both of these requirements are met, packets sent over the repair tunnel will reach their destination and won't loop after a single link failure 🎉.
in some topologies, you just can't find a repair tunnel endpoint with both of those properties 😩. for example, if the ring topology in Figure 1 had a cost of four on link B-C while the rest of the links cost one, then you couldn't establish a tunnel from S to C (unless you used some form of source routing) 🙈.
5.2.1. Computing Repair Paths
Okay so to compute the repair path for link S-E, we need two sets 💅. The first is the routers S can reach without going over S-E. The second is the routers that can reach E by normal forwarding without going over S-E. Then we match them up ✨
Our approach here goes like this:
- We work out the routers S can reach on its shortest path tree without traversing S-E. This is called S's P-space with respect to the failure of link S-E 🌸
- We stretch things a bit. S can use its neighbors' P-space with respect to the failure of link S-E, because S can figure out which neighbor it'll use as the next hop for the repair. This is S's extended P-space with respect to the failure of link S-E. It gives greater repair coverage and is the preferred approach 🦋
- Then we look at two methods for working out the routers from which node E can be reached by normal forwarding without traversing link S-E. This is the Q-space of E with respect to link S-E 🎀
The selection of the preferred node from the set of nodes in both extended P-space and Q-space with respect to S-E is covered in Section 5.2.2. A suitable cost-based algorithm for finding the set of nodes common to both extended P-space and Q-space with respect to S-E is provided in Section 5.3 💖
5.2.1.1. P-space
The set of routers S can reach on the shortest path tree without traversing S-E is called the P-space of S with respect to the link S-E 🧚. To get it, you compute a Shortest Path Tree (SPT) rooted at S and excise the subtree reached via the link S-E. That includes any routers that are members of an ECMP that includes link S-E 🙈. Excluding routers reachable via an ECMP that includes S-E keeps the forwarding subsystem from trying to run a repair via the failed link S-E. That's the whole point 💅.
For example, if the Shortest Path First (SPF) computation stores at each node the next hops used to reach that node from S, then a node can be added to P-space if none of its next hops are link S-E.
In the case of Figure 1, this P-space comprises nodes A and B only ✨. In cost terms, the set of routers {P} are the ones where the shortest path cost S->P is strictly less than the shortest path cost S->E->P.
5.2.1.2. Extended P-space
Okay, the P-space we just did was calculated rooted at S itself. But router S only uses a repair path after it has detected the failure of link S-E, so the initial hop of the repair path doesn't need to go through S's normal forwarding decision process 🌈. That's why extended P-space is a thing. Router S's extended P-space is the union of the P-spaces of each of S's neighbors (N).
You can calculate it by computing an SPT at each of S's neighbors (excluding E), and excising the subtree reached via the path N->S->E. Note this will excise those routers that are reachable through all ECMPs that include link S-E 🫶. Extended P-space may let router S reach potential repair tunnel endpoints that were otherwise unreachable. Iconic 👑
In cost terms, a router (P) is in extended P-space if the shortest path cost N->P is strictly less than the shortest path cost N->S->E->P. In other words, once S forces the packet to N, it's cheaper for it to keep going to P by any path except one that takes it back to S and then across the S->E link 😭.
Since in the case of Figure 1, node A is a per-prefix LFA for destination node C, the set of extended P-space nodes with respect to link S-E comprises nodes A, B, and C. Node C is also in E's Q-space with respect to link S-E, so now there's a node common to both extended P-space and Q-space that can be used as a repair tunnel endpoint to protect link S-E 🔥.
5.2.1.3. Q-space
The set of routers from which node E can be reached, by normal forwarding without traversing link S-E, is called the Q-space of E with respect to link S-E 🌸. You get it by computing a reverse Shortest Path Tree (rSPT) rooted at E, with the subtree that might traverse the protected link S-E excised. That means excising the nodes that would send the packet via S-E, plus the nodes that have an ECMP set to E with one or more members of that ECMP set traversing the protected link S-E 🙈.
The rSPT uses the cost towards the root rather than from it, and it yields the best paths towards the root from other nodes in the network 🦋.
In the case of Figure 1, the Q-space of E with respect to S-E comprises nodes C and D only. In cost terms, the set of routers {Q} are the ones where the shortest path cost Q<-E is strictly less than the shortest path cost Q<-S<-E. In Figure 1, the intersection of E's Q-space with respect to S-E and S's P-space with respect to S-E defines the set of viable repair tunnel endpoints, known as "PQ nodes" 💜. As you can see in the case of Figure 1, there's no common node, so there's no viable repair tunnel endpoint 💀. But when the extended P-space (Section 5.2.1.2) at S with respect to S-E is considered, a suitable intersection shows up at C 🎀.
Note that the Q-space calculation could be run for each individual destination, and a per-destination repair tunnel endpoint determined. However, in the worst case that would need an SPF computation per destination, which isn't currently considered scalable 😩. So the Q-space of E with respect to link S-E is used as a proxy for the Q-space of each destination. This approximation is obviously correct, since the repair is only used for the set of destinations that were routed through node E before the failure. It's analogous to using link LFAs rather than per-prefix LFAs 🧚.
5.2.2. Selecting Repair Paths
The mechanisms above will identify all the possible repair tunnel endpoints that can protect a particular link. In a well-connected network, there are likely to be multiple possible release points for each protected link 🌈. They'll all deliver the packets correctly, so arguably it doesn't matter which one gets chosen 🤷♀️. Still, one repair tunnel endpoint may be preferred over the others based on path cost or some other selection criteria 💅.
There's no technical requirement for the selection criteria to be consistent across all routers, but consistency may be desirable from an operational point of view 🫶. In general, there are advantages to choosing the repair tunnel endpoint closest to S (shortest metric). Choosing the closest one maximizes the opportunity for the traffic to be load balanced once it's been released from the tunnel ✨.
For consistency in behavior, it is RECOMMENDED that the member of the set of routers {PQ} with the lowest cost S->P be the default choice for P 👑. In the event of a tie, the router with the lowest node identifier SHOULD be selected 🍓.
It's a local matter whether the repair path selection policy used by the router favors LFA repairs over RLFA repairs 🦋. An LFA repair has the advantage of not requiring the use of a tunnel. However, network manageability considerations may lead to a repair strategy that uses a remote LFA more frequently [LFA-MANAGE] 🌸.
As described in [RFC5286], always selecting a PQ node that is downstream to the destination with respect to the repairing node prevents the formation of loops when the failure is worse than expected 🔥. The catch is that using downstream nodes reduces the repair coverage, so operators are advised to determine whether adequate coverage is achieved before enabling this selection feature 💀.
5.3. A Cost-Based RLFA Algorithm ✨
okay so the last bit explained how to find the remote LFA repair target (PQ) by intersecting two reachability graphs that you run SPF on 🧠. this section shows a cost-based way to find that PQ node for one specific failed link 💅. the pseudocode skips pointless SPF runs, but it isn't trying to be super optimized because it's built for readability, bestie 🎀. it handles the case where the repair first hop is reached over a broadcast or NBMA link (like a LAN), and where the P or Q node is attached through one of those too 🫶. it does not cover the case where the failed interface is itself a broadcast or NBMA link 😭. for that one you have to compute the Q-space of each neighbor of the repairing router that's reachable through the LAN, which means treating the pseudonode [RFC1195] as a node failure. the reason is that the Q-spaces of the pseudonode's neighbors can be totally disjoint and need a neighbor-specific PQ node 🌈. if you want more on using RLFA for node repairs, go check [NODE-PROTECTION] 🦋
here's the notation the code uses:
D_opt(a,b)is the shortest distance from node a to node b, as computed by the SPF.destis the packet destination.fail_intfis the failed interface (S-E in the example).fail_intf.remote_nodeis the node reachable over interfacefail_intf(node E in the example).intf.remote_nodeis the set of nodes reachable over interfaceintf.rootis the root of the SPF calculation.selfis the node carrying out the computation.yis the node in the network under consideration.y.pseudonodeis true ifyis a pseudonode.
and now the full algorithm, untouched 👑
//////////////////////////////////////////////////////////////////
//
// Main Function
//////////////////////////////////////////////////////////////////
//
// We have already computed the forward SPF from self to all nodes
// y in network and thus we know D_opt (self, y). This is needed
// for normal forwarding.
// However, for completeness:
Compute_and_Store_Forward_SPF(self)
// To extend P-space, we compute the SPF at each neighbor except
// the neighbor that is reached via the link being protected.
// We will also need D_opt(fail_intf.remote_node,y), so we
// compute that at the same time.
Compute_Neighbor_SPFs()
// Compute the set of nodes {P} reachable other than via the
// failed link.
Compute_Extended_P_Space(fail_intf)
// Compute the set of nodes that can reach the node on the far
// side of the failed link without traversing the failed link.
Compute_Q_Space(fail_intf)
// Compute the set of candidate RLFA tunnel endpoints.
Intersect_Extended_P_and_Q_Space()
// Make sure that we cannot get looping repairs when the
// failure is worse than expected.
if (guarantee_no_looping_on_worse_than_protected_failure)
Apply_Downstream_Constraint()
//
// End of Main Function
//
//////////////////////////////////////////////////////////////////
//////////////////////////////////////////////////////////////////
//
// Procedures
//
/////////////////////////////////////////////////////////////////
//
// This computes the SPF from root and stores the optimum
// distance from root to each node y.
Compute_and_Store_Forward_SPF(root)
Compute_Forward_SPF(root)
foreach node y in network
store D_opt(root,y)
/////////////////////////////////////////////////////////////////
//
// This computes the optimum distance from each neighbor (other
// than the neighbor reachable through the failed link) and
// every other node in the network.
//
// Note that we compute this for all neighbors, including the
// neighbor on the far side the failure. This is done on the
// expectation that more than one link will be protected and
// that the results are stored for later use.
//
Compute_Neighbor_SPFs()
foreach interface intf in self
Compute_and_Store_Forward_SPF(intf.remote_node)
/////////////////////////////////////////////////////////////////
//
// The reverse SPF computes the cost from each remote node to
// root. This is achieved by running the normal SPF algorithm
// but using the link cost in the direction from the next hop
// back towards root in place of the link cost in the direction
// away from root towards the next hop.
Compute_and_Store_Reverse_SPF(root)
Compute_Reverse_SPF(root)
foreach node y in network
store D_opt(y,root)
/////////////////////////////////////////////////////////////////
//
// Calculate Extended P-space
//
// Note that the "strictly less than" operator is needed to
// avoid ECMP issues.
Compute_Extended_P_Space(fail_intf)
foreach node y in network
y.in_extended_P_space = false
// Extend P-space to the P-spaces of all reachable
// neighbors
foreach interface intf in self
// Exclude failed interface, noting that
// the node reachable via that interface may be
// reachable via another interface (parallel path)
if (intf != fail_intf)
foreach neighbor n in intf.remote_node
// Apply RFC 5286 Inequality 1
if ( D_opt(n, y) <
D_opt(n,self) + D_opt(self, y))
y.in_extended_P_space = true
/////////////////////////////////////////////////////////////////
//
// Compute the Nodes in Q-space
//
Compute_Q_Space(fail_intf)
// Compute the cost from every node in the network to the
// node normally reachable across the failed link
Compute_and_Store_Reverse_SPF(fail_intf.remote_node)
// Compute the cost from every node in the network to self
Compute_and_Store_Reverse_SPF(self)
foreach node y in network
if ( D_opt(y,fail_intf.remote_node) < D_opt(y,self) +
D_opt(self,fail_intf.remote_node) )
y.in_Q_space = true
else
y.in_Q_space = false
/////////////////////////////////////////////////////////////////
//
// Compute Set of Nodes in Both Extended P-space and in Q-space
Intersect_Extended_P_and_Q_Space()
foreach node y in network
if ( y.in_extended_P_space && y.in_Q_space &&
y.pseudonode == False)
y.valid_tunnel_endpoint = true
else
y.valid_tunnel_endpoint = false
/////////////////////////////////////////////////////////////////
//
// A downstream route is one where the next hop is strictly
// closer to the destination. By sending the packet to a
// PQ node that is downstream, we know that if the PQ node
// detects a failure it will not loop the packet back to self.
// This is useful when there are two failures or when a node has
// failed rather than a link.
Apply_Downstream_Constraint()
foreach node y in network
if (y.valid_tunnel_endpoint)
Compute_and_Store_Forward_SPF(y)
if ((D_opt(y,dest) < D_opt(self,dest))
y.valid_tunnel_endpoint = true
else
y.valid_tunnel_endpoint = false
//
/////////////////////////////////////////////////////////////////5.4. Interactions with IS-IS Overload, RFC 6987, and Costed Out Links 🙈
okay this one's about making sure the overload and costing-out rules still work when we're running all those extra SPFs 🧠. normal link state routing already respects the IS-IS overload bit, the OSPF stub router advertisement [RFC6987], and costed out links (as described in Section 3.5 of [RFC5286]). so the forward SPFs the PLR runs rooted at its neighbors also have to respect all of that 💖. a repair tunnel path from a neighbor of the PLR to a repair tunnel endpoint will usually steer clear of the nodes and links those rules exclude. BUT there are two sneaky situations where it can still end up going through something it shouldn't 😭
- first sneaky situation: the first hop on the repair tunnel path (from the PLR to a direct neighbor) doesn't follow the IGP shortest path. in that case the PLR MUST NOT use a repair tunnel path whose first hop runs along a link with a cost or reverse cost equal to MaxLinkMetric (for OSPF) or the maximum cost (for IS-IS), or whose first hop has the overload bit set (for IS-IS) 🚫
- second sneaky situation: the IS-IS overload bit and the mechanism of [RFC6987] only stop transit traffic from crossing a node. they don't stop traffic that's destined to that node 🫠. the per-neighbor forward SPFs using the standard IGP overload rules won't stop a PLR from picking a repair tunnel endpoint that's basically saying "don't send me transit traffic." so the PLR MUST NOT use a repair tunnel endpoint with the IS-IS overload bit set, or one where all outgoing interfaces have the cost set to MaxLinkMetric for OSPF 🚫💅
6. Example Application of Remote LFAs 🧚
okay here's a super common SP topology that LFAs alone can't fully protect 🌸. PE1 and PE2 are in the same site. P1 and P2 might be geographically separated (intersite). to guarantee the lowest latency path to and from all the other remote PEs, the shortest path normally follows the geographical distance between the site locations. so to make that happen, a lower IGP metric (5) is set between PE1 and PE2 🍓. a high metric (1000) goes on the P-PE links so the PEs don't get used for transit traffic 🙅♀️. and the PEs aren't individually dual-homed, just to keep costs down 💸
this is a super common setup in Service Provider (SP) networks, so it's giving real-world 🌍
when the link between PE1 and P1 fails, PE1 doesn't have an LFA for traffic reachable via P1 😭. by symmetry, if the link between PE2 and P2 fails, PE2 doesn't have an LFA for traffic reachable via P2 💀
bumping up the metric between PE1 and PE2 so an LFA becomes possible would hurt normal traffic, because it could raise the latency 🥲 nope.
here's the topology (Figure 3) ✨
| 100 |
-P1---------P2-
\ /
1000 \ / 1000
PE1---PE2
5
Figure 3: Example SP Topologyand the big finish 👑 with the techniques in this document, PE1 can fully protect itself by picking P2 as its remote LFA repair target node, and PE2 can pick P1 as its remote LFA repair target. full protection, no cap 💖🎀
7. Node Failures ✨
okay so this is the part where things get spicy 🌶️. When the thing that dies is a whole node and not just one point-to-point link, there's a real danger that the RLFA repair ends up looping 🔁😭. [IP-FRR] goes into this in full detail, but the short version is: two or more of E's neighbors can each have E as their next hop to some destination D. Then they each try to repair a packet headed for D by bouncing it to the other neighbor, which sends it right back to E. Loop city 💀. A similar mess shows up with a shared risk link group failure, where the PLR for each failure tries to repair through the other failure. As [IP-FRR] points out, this gets complicated fast 🫠.
There are a few ways to make a loop less likely when a node fails, and there's also the possibility that two of E's neighbors end up making a mutual repair 🤝.
- Detect when a packet has arrived on some interface I that is also the interface used to reach the first hop on the RLFA path to the remote LFA repair target, and drop the packet. This is useful in the case of a ring topology 💍.
- Require that the path from the remote LFA repair target to destination D never passes through E (including in the ECMP case), i.e., only use node protecting paths in which the cost from the remote LFA repair target to D is strictly less than the cost from the remote LFA repair target to E plus the cost E to D. 🙅♀️
- Require that where the packet may pass through another neighbor of E, that node is down stream (i.e., strictly closer to D than the repairing node). This means that some neighbor of E (X) can repair via some other neighbor of E (Y), but Y cannot repair via X. 🎯
Case 1 accepts that loops might form and then squashes them by dropping packets 🗑️. Dropping packets can be seen as less harmful than letting them loop around forever. The catch is that this approach can also drop some legit packets 😬. Cases 2 and 3 stop the loop from forming at all, but the price is less repair coverage and extra complexity in the algorithm that computes the repair path 🧠. Or, you could decide the chance of a node failure is rare enough that looping RLFA repairs can just be ignored 🤷♀️.
How likely a node failure is, and how bad it is in a particular topology, depends on the node design, the topology being used, and the strategy chosen for node failure. It is recommended that a network operator analyze the consequences and probability of node failure in their network and decide whether the likelihood and impact are acceptable 📊✨.
This topic is further discussed in [NODE-PROTECTION] 📚.
8. Operation in an LDP Environment 🎀
okay, so if this technique is used in an MPLS network that runs LDP [RFC5036], and S is a transit node, then S has to swap the top label in the stack for the remote LFA repair target's (PQ's) label to the destination, and then push its own label for the remote LFA repair target 🏷️💖.
In the example, S in Figure 2 already has the first hop (A) label for the remote LFA repair target (C) because of ordinary LDP operation 🌸. To get C's label for the destination (D), S needs to set up a targeted LDP session with C 🤝. Here's what the label stack looks like for normal operation and for RLFA operation, shown in Figure 4 🦋.
+-----------------+ +-----------------+ +-----------------+
| datalink | | datalink | | datalink |
+-----------------+ +-----------------+ +-----------------+
| S's label for D | | E's label for D | | A's label for C |
+-----------------+ +-----------------+ +-----------------+
| Payload | | Payload | | C's label for D |
+-----------------+ +-----------------+ +-----------------+
X Y | Payload |
+-----------------+
Z
X = Normal label stack packet arriving at S
Y = Normal label stack packet leaving S
Z = RLFA label stack to D via C as the remote LFA repair target
Figure 4To set up a targeted LDP session with a candidate remote LFA repair target node, the repairing node (S) needs to know which IP address the remote LFA repair target is willing to use for targeted LDP sessions 🔍. Ideally, the remote LFA repair target advertises that address in the IGP being used 📣. Which address gets used, how it gets advertised in the IGP, and whether it's a special IP address or one that's also used for something else is out of scope for this document, and must be specified in an IGP-specific RFC 📝.
If there's no protocol to learn the preferred IP address for targeted LDP, an LSR should try a targeted LDP session with the Router ID [RFC2328] [RFC5305] [RFC5340] [RFC6119] [OSPF-RI], unless it's configured otherwise ⚙️.
No protection is available until the TLDP session has been established and a label for the destination has been learned from the remote LFA repair target 🙅♀️. If the TLDP session can't be established for any reason, an implementation SHOULD advise the operator about the protection setup issue through the network management system 📟🚨.
9. Analysis of Real World Topologies 💅
this section shares the results of analyzing a bunch of real service provider topologies that were collected between the end of 2012 and early 2013 🌍✨.
9.1. Topology Details 🗺️
The figure below breaks down each topology (topo) that was studied, in terms of:
- the number of nodes (# nodes) excluding pseudonodes;
- the number of bidirectional links (# links) including parallel links and links to and from pseudonodes;
- the number of node pairs that are connected by one or more links (# pairs);
- the number of node pairs that are connected by more than one (i.e., parallel) link (# para); and
- the number of links (excluding pseudonode links, which are by definition asymmetric) that have asymmetric metrics (# asym).
+------+---------+---------+---------+--------+--------+
| topo | # nodes | # links | # pairs | # para | # asym |
+------+---------+---------+---------+--------+--------+
| 1 | 315 | 570 | 560 | 10 | 3 |
| 2 | 158 | 373 | 312 | 33 | 0 |
| 3 | 655 | 1768 | 1314 | 275 | 1195 |
| 4 | 1281 | 2326 | 2248 | 70 | 10 |
| 5 | 364 | 811 | 659 | 80 | 86 |
| 6 | 114 | 318 | 197 | 101 | 4 |
| 7 | 55 | 237 | 159 | 67 | 2 |
| 8 | 779 | 1848 | 1441 | 199 | 437 |
| 9 | 263 | 482 | 413 | 41 | 12 |
| 10 | 86 | 375 | 145 | 64 | 22 |
| 11 | 162 | 1083 | 351 | 201 | 49 |
| 12 | 380 | 1174 | 763 | 231 | 0 |
| 13 | 1051 | 2087 | 2037 | 48 | 64 |
| 14 | 92 | 291 | 204 | 64 | 2 |
+------+---------+---------+---------+--------+--------+9.2. LFA Only 🦋
The figure below shows the percentage of protected destinations (% prot) and the percentage of guaranteed node protected destinations (% gtd N) for the topologies characterized in Section 9.1, achieved using only LFA repairs 📈.
These stats were generated by looking at each node, then each link to each next hop to each destination. The percentage of those links across the whole network that are protected against link failure was worked out. That's the percentage of protected destinations 🛡️. If a link is protected against the failure of the next hop node, it counts as Guaranteed Node Protecting (GNP), and the percentage of guaranteed node protected destinations is calculated with the same method used for the link protection coverage 💜.
GNP is identical to node-protecting as defined in [RFC6571], and it does not include the extra node protection coverage from the de facto node-protecting condition described in [RFC6571] 🙅♀️.
+------+--------+---------+
| topo | % prot | % gtd N |
+------+--------+---------+
| 1 | 78.5 | 36.9 |
| 2 | 97.3 | 52.4 |
| 3 | 99.3 | 58 |
| 4 | 83.1 | 63.1 |
| 5 | 99 | 59.1 |
| 6 | 86.4 | 21.4 |
| 7 | 93.9 | 35.4 |
| 8 | 95.3 | 48.1 |
| 9 | 82.2 | 49.5 |
| 10 | 98.5 | 14.9 |
| 11 | 99.6 | 24.8 |
| 12 | 99.5 | 62.4 |
| 13 | 92.4 | 51.6 |
| 14 | 99.3 | 48.6 |
+------+--------+---------+9.3. RLFA ✨
okay so this part is the big reveal bestie 💅 The figure below shows the percentage of protected destinations (% prot) and the % guaranteed node protected destinations (% gtd N) for RLFA protection across the topologies studied. It also tells us the percentage of destinations using an RLFA repair (% PQ), the total number of unidirectional RLFA targeted LDP sessions established (# PQ), and the number of PQ sessions that would've been needed for complete protection but couldn't be set up because there was no PQ node (no PQ). That last one counts the cases where neither LFA nor RLFA protection was possible 🥺. Finally, it lists the 50 (p50), 90 (p90), and 100 (p100) percentiles for how many individual LDP sessions end at a single node, whether they're used for TX, RX, or both 🌸
Here's a quick example so the counting makes sense 🦋 Say there are LDP sessions that need A->B, A->C, C->A, and C->D. Those get counted as 2, 1, 2, and 1 at nodes A, B, C, and D, respectively:
- A has two sessions (to nodes B and C) 💖
- B has one session (to node A) 💖
- C has two sessions (to nodes A and D) 💖
- D has one session (to node D) 💖
In this study, remote LFA only kicks in when it's actually needed 🧚. That means there's at least one destination that a per destination LFA can't repair, and a single remote LFA tunnel (if one is available) is used to repair traffic to all of those destinations. The remote LFA repair target points are computed using extended P-space, and the repairing node picks the PQ node with the lowest metric cost from itself ✨
+------+--------+--------+------+------+-------+-----+-----+------+
| topo | % prot |% gtd N | % PQ | # PQ | no PQ | p50 | p90 | p100 |
+------+--------+--------+------+------+-------+-----+-----+------+
| 1 | 99.7 | 53.3 | 21.2 | 295 | 3 | 1 | 5 | 14 |
| 2 | 97.5 | 52.4 | 0.2 | 7 | 40 | 0 | 0 | 2 |
| 3 | 99.999 | 58.4 | 0.7 | 63 | 5 | 0 | 1 | 5 |
| 4 | 99 | 74.8 | 16 | 1424 | 54 | 1 | 3 | 23 |
| 5 | 99.5 | 59.5 | 0.5 | 151 | 7 | 0 | 2 | 7 |
| 6 | 100 | 34.9 | 13.6 | 63 | 0 | 1 | 2 | 6 |
| 7 | 99.999 | 40.6 | 6.1 | 16 | 2 | 0 | 2 | 4 |
| 8 | 99.5 | 50.2 | 4.3 | 350 | 39 | 0 | 2 | 15 |
| 9 | 99.5 | 55 | 17.3 | 428 | 5 | 1 | 2 | 67 |
| 10 | 99.6 | 14.1 | 1 | 49 | 7 | 1 | 2 | 5 |
| 11 | 99.9 | 24.9 | 0.3 | 85 | 1 | 0 | 2 | 8 |
| 12 | 99.999 | 62.8 | 0.5 | 512 | 4 | 0 | 0 | 3 |
| 13 | 97.5 | 54.6 | 5.1 | 1188 | 95 | 0 | 2 | 27 |
| 14 | 100 | 48.6 | 0.7 | 79 | 0 | 0 | 2 | 4 |
+------+--------+--------+------+------+-------+-----+-----+------+Another study [ISOCORE2010] backs this up and confirms the big coverage boost you get from remote LFAs 🎀
9.4. Comparison of LFA and RLFA results
Here's the side-by-side showdown between LFA and remote LFA 👑 The vibe is clear: remote LFA gives a huge jump in the percentage of protected destinations, and usually a modest bump in the percentage of guaranteed node protected destinations 🔥
+------+--------+--------+---------+---------+
| topo | LFA | RLFA | LFA | RLFA |
| | % prot | %prot | % gtd N | % gtd N |
+------+--------+--------+---------+---------+
| 1 | 78.5 | 99.7 | 36.9 | 53.3 |
| 2 | 97.3 | 97.5 | 52.4 | 52.4 |
| 3 | 99.3 | 99.999 | 58 | 58.4 |
| 4 | 83.1 | 99 | 63.1 | 74.8 |
| 5 | 99 | 99.5 | 59.1 | 59.5 |
| 6 | 86.4 |100 | 21.4 | 34.9 |
| 7 | 93.9 | 99.999 | 35.4 | 40.6 |
| 8 | 95.3 | 99.5 | 48.1 | 50.2 |
| 9 | 82.2 | 99.5 | 49.5 | 55 |
| 10 | 98.5 | 99.6 | 14.9 | 14.1 |
| 11 | 99.6 | 99.9 | 24.8 | 24.9 |
| 12 | 99.5 | 99.999 | 62.4 | 62.8 |
| 13 | 92.4 | 97.5 | 51.6 | 54.6 |
| 14 | 99.3 |100 | 48.6 | 48.6 |
+------+--------+--------+---------+---------+So, as the table shows, remote LFA gets close to 100% prefix protection against link failure in 11 of the 14 topologies studied 🥳 It also gives a significant improvement in two of the other three cases. Also, in an MPLS network, the tunnels to the PQ nodes are always there, because that's just how an LDP-based deployment works 🌈
Now, in the small number of cases where the (extended) P-space and the Q-space don't overlap at all, the working group has talked through a few ways to build a suitable path across that gap 🧚 For example, an explicitly routed LSP between P and Q could be set up with RSVP-TE, or with Segment Routing [SEGMENT-ROUTING]. Those extended repair methods are outside the scope of this document, so we're leaving them for another day 🫶
10. Management and Operational Considerations
The management of LFA and remote LFA is the subject of ongoing work within the IETF [LFA-MANAGE], so go check that out if you're curious 🦋 Management considerations might lead to a preference for remote LFA over an available LFA. That's a call for the network operator, not a matter of protocol correctness 💜
When the network reconverges, micro-loops [RFC5715] can form because the forwarding tables on different routers are briefly out of sync 😭 If micro-loops turn out to be a significant issue in the deployment, then a suitable loop-free convergence method, such as one of those described in [RFC5715], [RFC6976], or [ULOOP-DELAY], should be implemented 🔥
11. Historical Note
The basic concepts behind remote LFA were invented in 2002, and they were later included in [IP-FRR], which was submitted in 2004 🕰️
[IP-FRR] aimed for 100% protection coverage, so it added extra mechanisms on top of the remote LFA concept 🙈 Those mechanisms made the proposal super complex and computationally intensive, so it wasn't pursued as a working group item. Not the vibe 💀
As explained in [RFC6571], LFA FRR isn't about getting coverage at any cost ✨ A solution for that already exists in MPLS-TE FRR. MPLS-TE FRR is a mature technology that can protect in any topology, thanks to the explicit routing capability of MPLS-TE 👑
The whole point of LFA FRR is to offer a simple FRR solution whenever one is possible 🌸 The first step on that simplicity path was "local" LFA [RFC5286], and this specification of "remote LFA" is a natural second step 🦋
12. Security Considerations
The security considerations of [RFC5286] also apply, so don't skip that one bestie 🔐
Targeted LDP sessions and MPLS tunnels are normal features of an MPLS network, and using them here doesn't raise any extra security concerns 🎀
IP repair tunnel endpoints (where they're used) SHOULD be assigned from a set of addresses that are not reachable from outside the routing domain 🚫 That way, nobody can use them as an attack vector 😱
Other than OAM traffic used to verify that a repair tunnel is working correctly, only traffic being protected because of a link failure goes into a repair tunnel 🔥 And the repair tunnel MUST NOT be advertised by the routing protocol as a link that may be used to carry normal user traffic or routing protocol traffic. Main character rule, no exceptions 💅
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008, <http://www.rfc-editor.org/info/rfc5286>.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010, <http://www.rfc-editor.org/info/rfc5714>.
13.2. Informative References 📚✨
okay bestie, this is the extra reading list 🤓 these are not required to get the main idea, but they're where the authors pulled in the rest of the story. 💅
[IP-FRR]Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP Fast Reroute using tunnels", Work in Progress, draft-bryant-ipfrr-tunnels-03, November 2007. 🦋[ISOCORE2010]So, N., Lin, T., and C. Chen, "LFA (Loop Free Alternates) Case Studies in Verizon's LDP Network", 13th Annual MPLS Conference, 2010. 🌸[LFA-MANAGE]Litkowski, S., Decraene, B., Filsfils, C., Raza, K., Horneffer, M., and P. Sarkar, "Operational management of Loop Free Alternates", Work in Progress, draft-ietf-rtgwg-lfa-manageability-08, March 2015. 🎀[NODE-PROTECTION]Sarkar, P., Gredler, H., Hegde, S., Bowers, C., Litkowski, S., and H. Raghuveer, "Remote-LFA Node Protection and Manageability", Work in Progress, draft-ietf-rtgwg-rlfa-node-protection-01, December 2014. 🧚[OSPF-RI]Xu, X., Chunduri, U., and M. Bhatia, "Carrying Routable IP Addresses in OSPF RI LSA", Work in Progress, draft-ietf-ospf-routable-ip-address-02, April 2015. 💜[RFC1195]Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990,<http://www.rfc-editor.org/info/rfc1195>. 🍓[RFC1701]Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994,<http://www.rfc-editor.org/info/rfc1701>. ✨[RFC1853]Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995,<http://www.rfc-editor.org/info/rfc1853>. 🌈[RFC2328]Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998,<http://www.rfc-editor.org/info/rfc2328>. 💖[RFC3032]Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001,<http://www.rfc-editor.org/info/rfc3032>. 🫶[RFC5036]Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007,<http://www.rfc-editor.org/info/rfc5036>. 🔥[RFC5305]Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, October 2008,<http://www.rfc-editor.org/info/rfc5305>. 👑[RFC5340]Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008,<http://www.rfc-editor.org/info/rfc5340>. 🦋[RFC5715]Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, January 2010,<http://www.rfc-editor.org/info/rfc5715>. 🌸[RFC6119]Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, February 2011,<http://www.rfc-editor.org/info/rfc6119>. 🎀[RFC6571]Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene, B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks", RFC 6571, June 2012,<http://www.rfc-editor.org/info/rfc6571>. 🧚[RFC6976]Shand, M., Bryant, S., Previdi, S., Filsfils, C., Francois, P., and O. Bonaventure, "Framework for Loop-Free Convergence Using the Ordered Forwarding Information Base (oFIB) Approach", RFC 6976, July 2013,<http://www.rfc-editor.org/info/rfc6976>. 💜[RFC6987]Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, September 2013,<http://www.rfc-editor.org/info/rfc6987>. 🍓[SEGMENT-ROUTING]Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., Litkowski, S., Horneffer, M., Shakir, R., Tantsura, J., and E. Crabbe, "Segment Routing Architecture", Work in Progress, draft-ietf-spring-segment-routing-01, February 2015. ✨[ULOOP-DELAY]Litkowski, S., Decraene, B., Filsfils, C., and P. Francois, "Microloop prevention by introducing a local convergence delay", Work in Progress, draft-litkowski-rtgwg-uloop-delay-03, February 2014. 🌈
Acknowledgements 💖
big thank-yous 🫶 the authors want to shout out Levente Csikor and Chris Bowers for helping write the cost-based algorithm text. They also thank Alia Atlas, Ross Callon, Stephane Litkowski, Bharath R, Pushpasis Sarkar, and Adrian Farrel for reviewing this document. the squad really showed up 👑
Authors' Addresses 🌸
here's who wrote it, with their contact details 💌
Stewart Bryant
Cisco Systems
9-11 New Square,
Bedfont Lakes,
Feltham,
Middlesex TW14 8HA
United Kingdom
EMail: stbryant@cisco.com
Clarence Filsfils
Cisco Systems
De Kleetlaan 6a
1831 Diegem
Belgium
EMail: cfilsfil@cisco.com
Stefano Previdi
Cisco Systems
EMail: sprevidi@cisco.com
Mike Shand
Independent Contributor
EMail: imc.shand@gmail.com
Ning So
Vinci Systems
EMail: ningso@vinci-systems.comand that's the whole RFC, bestie 🦋✨ you made it to the end! 🎉
📦 where this page comes from
- ietf: rfc7490 2015-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms