RFC 5286
Basic Specification for IP Fast Reroute: Loop-Free Alternates
RFC 5286: Basic Specification for IP Fast Reroute: Loop-Free Alternates 🎀
- Authors: A. Atlas, Ed. (BT) and A. Zinin, Ed. (Alcatel-Lucent) 💅
- Category: Standards Track ✨
- Date: September 2008 🌸
- Obsoletes / Updates: the title block has no Obsoletes or Updates line, so this one doesn't replace or update anything 🫶
Status of This Memo 📜
okay so this doc is an Internet standards track protocol for the whole Internet community 🌈 It's open for discussion and suggestions for improvements, so bring your ideas! For the current standardization state and status of this protocol, check the latest edition of the "Internet Official Protocol Standards" (STD 1). And the memo can be distributed freely, no limits 🦋
Abstract 💜
this document is all about loop-free alternates 🧚 They give local protection for unicast traffic in pure IP and MPLS/LDP networks when there's a single failure, whether that's a link, a node, or a shared risk link group (SRLG) 💀 The big goal is to cut down on the packet loss that happens while routers converge after a topology change 😭
The trick is precalculated backup next-hops. They're loop-free and safe to use until the distributed convergence process finishes, so repair is super fast ⚡ And the best part? It doesn't need any help from other routers 🫶 How much of that goal you actually hit depends on the topology of the network, so it's not a guarantee for every network 🙈
Table of Contents 📚
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Failure Scenarios . . . . . . . . . . . . . . . . . . . . 5
1.2. Requirement Language . . . . . . . . . . . . . . . . . . . 8
2. Applicability of Described Mechanisms . . . . . . . . . . . . 8
3. Alternate Next-Hop Calculation . . . . . . . . . . . . . . . . 9
3.1. Basic Loop-Free Condition . . . . . . . . . . . . . . . . 10
3.2. Node-Protecting Alternate Next-Hops . . . . . . . . . . . 10
3.3. Broadcast and Non-Broadcast Multi-Access (NBMA) Links . . 11
3.4. ECMP and Alternates . . . . . . . . . . . . . . . . . . . 12
3.5. Interactions with IS-IS Overload, RFC 3137, and Costed
Out Links . . . . . . . . . . . . . . . . . . . . . . . . 13
3.5.1. Interactions with IS-IS Link Attributes . . . . . . . 14
3.6. Selection Procedure . . . . . . . . . . . . . . . . . . . 14
3.7. LFA Types and Trade-Offs . . . . . . . . . . . . . . . . . 18
3.8. A Simplification: Per-Next-Hop LFAs . . . . . . . . . . . 19
4. Using an Alternate . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Terminating Use of Alternate . . . . . . . . . . . . . . . 20
5. Requirements on LDP Mode . . . . . . . . . . . . . . . . . . . 22
6. Routing Aspects . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Multi-Homed Prefixes . . . . . . . . . . . . . . . . . . . 22
6.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
6.3.1. OSPF External Routing . . . . . . . . . . . . . . . . 24
6.3.2. OSPF Multi-Topology . . . . . . . . . . . . . . . . . 25
6.4. BGP Next-Hop Synchronization . . . . . . . . . . . . . . . 25
6.5. Multicast Considerations . . . . . . . . . . . . . . . . . 25
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. OSPF Example Where LFA Based on Local Area
Topology Is Insufficient . . . . . . . . . . . . . . 271. Introduction ✨
okay bestie, so interactive multimedia like Voice over IP (VoIP) and pseudowires is super sensitive to traffic loss 😭 That's what happens when a link or router in the network fails. A router's convergence time is usually on the order of hundreds of milliseconds, but the app traffic can be sensitive to losses greater than tens of milliseconds 💀
As discussed in [FRAMEWORK], cutting down on traffic loss needs a way for the router next to a failure to quickly invoke a repair path, one that barely gets affected by any reconvergence that comes after 🦋 This spec describes exactly that. It lets a router whose local link has failed keep forwarding traffic to a pre-computed alternate until it installs new primary next-hops based on the changed topology 🫶 The terminology here comes from [FRAMEWORK] too. The mechanism assumes routing is done with a link-state routing protocol, either OSPF [RFC2328] [RFC2740] [RFC5340] or IS-IS [RFC1195] [RFC2966] (for IPv4 or IPv6). It also assumes that the primary path and the alternate path are in the same routing area 🌸
When a local link fails, a router currently must signal the event to its neighbors through the IGP, recompute new primary next-hops for all affected prefixes, and only then install those new primary next-hops into the forwarding plane 😩 Until those new primary next-hops are installed, traffic headed for the affected prefixes gets discarded 💔 That whole process can take hundreds of milliseconds 🙈
<--
+-----+
/------| S |--\
/ +-----+ \
/ 5 8 \
/ \
+-----+ +-----+
| E | | N_1 |
+-----+ +-----+
\ /
\ \ 4 3 / /
\| \ / |/
-+ \ +-----+ / +-
\---| D |---/
+-----+
Figure 1: Basic Topologythe goal of IP Fast Reroute (IPFRR) is to drop failure reaction time to 10s of milliseconds 🌈 It does this by using a pre-computed alternate next-hop, for when the currently selected primary next-hop fails, so the alternate can be used the moment the failure is detected ⚡ A network with this feature sees less traffic loss and less micro-looping of packets than one without IPFRR 👑 There are still cases where traffic loss can happen, since IPFRR coverage varies. But in the worst possible situation, a network with IPFRR is equivalent to a network without it, as far as traffic convergence goes 🫠
let's look at the simple topology in Figure 1 to get the vibe. When router S computes its shortest path to router D, S picks the link to router E as its primary next-hop. Without IP Fast Reroute, that's the only next-hop S computes to reach D. With IPFRR, S also looks for an alternate next-hop 🧠 In this example, S works out that it could send traffic for D over the link to router N_1, so S installs the link to N_1 as its alternate next-hop 💖 Later on, the link between S and E could fail. S and E are the first to notice, since they detect it right away. Once S detects the failure, it stops sending traffic for D toward E over the failed link, and sends it to the pre-computed alternate next-hop (the link to N_1) instead. That keeps going until a new SPF runs and its results get installed ✨ Just like the primary next-hop, an alternate next-hop is computed for each destination. Computing the alternate does not change the primary next-hop that a standard SPF gives you 🎀
now here's the plot twist 🙃 If, in the Figure 1 example, the link cost from N_1 to D went up to 30 from 3, then N_1 would not be a loop-free alternate. Why? The cost of the path from N_1 to D via S would be 17, but the cost from N_1 directly to D would be 30. So N_1 just isn't a good backup anymore 💀 In real networks, we run into this situation a lot 😭 Whether a suitable loop-free alternate next-hop exists depends on the topology and on the nature of the failure the alternate is calculated for 🌈
This specification uses the terminology from [FRAMEWORK] 📖 Specifically, it uses Distance_opt(X,Y), shortened to D_opt(X,Y), to mean the shortest distance from X to Y 🧚 S is the calculating router. N_i is a neighbor of S, and N is shorthand for when we're only talking about one neighbor. D is the destination under consideration 💜
A neighbor N can provide a loop-free alternate (LFA) if and only if this holds:
Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)
Inequality 1: Loop-Free Criterionthen there's a more restrictive subset. Some loop-free alternates are downstream paths, and they have to meet a stricter condition that matters for more complex failure scenarios 🔥 That's the downstream path criterion:
Distance_opt(N, D) < Distance_opt(S, D)
Inequality 2: Downstream Path Criterion1.1. Failure Scenarios 💥
okay so the alternate next-hop can protect against a single link failure, a single node failure, failure of one or more links within a shared risk link group, or a combination of these 🦋. Whenever a failure is bigger than what the alternate was built to cover, traffic can temporarily loop 🌀. (Again, that loop only lasts until the next complete SPF calculation.) The example where a node fails but the alternate only protected against a link failure is shown below. If unexpected simultaneous failures happen, micro-looping can occur too, because the alternates weren't pre-computed to avoid that whole set of failed links 🙈.
If only link protection is provided and the node fails, traffic using the alternates can experience micro-looping. This is shown in Figure 2 💅. If Link(S->E) fails, the link-protecting alternate via N works just fine ✨. But if router E fails, then both S and N detect a failure and switch to their alternates. In this example, S redirects the traffic to N, and N redirects it right back to S, which creates a forwarding loop 💀. This can happen because the key assumption, that all other routers in the network are forwarding along the shortest path, gets broken by a second simultaneous correlated failure: another link connected to the same primary neighbor. If there are no other protection mechanisms for node failure, a node failure is still a concern when you're only using link-protecting LFAs 😭.
<@@@
@@@>
+-----+ +-----+
| S |-------| N |
+-+---+ 5 +-----+
| |
| 5 4 | |
| | | \|/
\|/ | |
| +-----+ |
+----| E |---+
+--+--+
|
|
| 10
|
+--+--+
| D |
+-----+
Figure 2: Link-Protecting Alternates Causing Loop on Node FailureMicro-looping via the alternates, caused when a failure bigger than planned for happens, can be prevented by only selecting downstream paths as alternates 🦋. A micro-loop from using alternates can be avoided with downstream paths because each router along the path to the destination must be closer to the destination than the router before it (according to the topology prior to the failures) 🧚. Downstream paths do keep micro-loops via alternates from happening, but that restriction can seriously limit how much the alternates cover 😩. In Figure 2, S could use N as a downstream alternate, but N couldn't use S. So N would have no alternate and would discard the traffic, which avoids the micro-loop 🌸.
Here's the tea: either a node-protecting LFA (described in Section 3.2) or a downstream path protects against micro-looping when a node fails 🫶. Some topologies have a node-protecting LFA, a downstream path, both, or neither ✨. A node can pick either a node-protecting LFA or a downstream path without risking micro-loops when a neighbor node fails 💜. A link-and-node-protecting LFA guarantees protection against either link or node failure. A downstream path only protects against a link failure, and it may or may not protect against a node failure depending on what protection the downstream node has. It cannot cause a micro-loop though 🔥. For example, in Figure 2, if S uses N as a downstream path, no looping can occur. But the traffic won't be protected if E fails, because N has no viable repair path, so it just discards the packet 😭. However, if N had a link-and-node-protecting LFA or a downstream path via some other path (not shown), the repair might succeed 🎀.
Since link-and-node-protecting LFAs do more than link-protecting downstream paths, a router SHOULD select a link-and-node-protecting LFA over a link-protecting downstream path 👑. If there are any destinations with no link-and-node-protecting LFA available, then by definition the path to all of those destinations from any neighbor of the computing router (S) must go through the node being protected (E). Otherwise there would be a node-protecting LFA for that destination 🧠. So if a downstream path to the protected node exists as a destination, that downstream path can be used for all those destinations that lack a link-and-node-protecting LFA. You can check whether a downstream path exists with one simple check: Distance_opt(N, E) < Distance_opt(S, E) ✨.
It might be nice to find an alternate that can protect against other correlated failures, and node failure is just one specific example of those 🌈. In general, these get handled by shared risk link groups (SRLGs), where any links in the network can belong to an SRLG. General SRLGs can add an unacceptable amount of computational complexity to finding a loop-free alternate 😵💫.
But a sub-category of SRLGs is really interesting, and it can be applied only while selecting an acceptable alternate 💖. This sub-category covers correlated failures of links that connect to the same router. For example, multiple logical sub-interfaces on the same physical interface (like VLANs on an Ethernet interface), multiple interfaces using the same physical port because of channelization, or multiple interfaces sharing a correlated failure because they're on the same line-card 🍓. This sub-category is called local-SRLGs. A local-SRLG has all of its member links with one end connected to the same router. So router S could select a loop-free alternate that doesn't use a link in the same local-SRLG as the primary next-hop 🦋. Failure of local-SRLGs belonging to E can be protected against through node protection, meaning by picking a loop-free node-protecting alternate 👑.
SRLG protection, where it's provided, applies within a particular OSPF or IS-IS area. That area's topology is what gets used in the SPF computations to find the loop-free alternates 🗺️. If an SRLG contains links in multiple areas, then separate SRLG-protecting alternates would be required in each area that the affected traffic passes through 🫶.
1.2. Requirement 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] 🎀.
2. Applicability of Described Mechanisms 🌷
IP Fast Reroute mechanisms in this memo only cover intra-domain routing, with OSPF [RFC2328] [RFC2740] [RFC5340] or IS-IS [RFC1195] [RFC2966] as the IGP 🌍. Fast Reroute for BGP inter-domain routing is NOT part of this specification, so don't go looking for it here 🙅♀️.
Certain aspects of OSPF inter-area routing behavior, explained in Section 6.3 and Appendix A, affect how well the router calculating the backup next-hops can figure out traffic trajectories 🧭. To avoid micro-looping and make sure the required coverage happens, certain constraints apply to multi-area OSPF networks 💅:
a. Loop-free alternates should not be used in the backbone area if there are any virtual links configured, unless, for each transit area, there is a full mesh of virtual links between all Area Border Routers (ABRs) in that area. Loop-free alternates may be used in non-backbone areas regardless of whether there are virtual links configured 🦋.
b. Loop-free alternates should not be used for inter-area routes in an area that contains more than one alternate ABR [RFC3509] 🌸.
c. Loop-free alternates should not be used for AS External routes or Autonomous System Border Router (ASBR) routes in a non-backbone area of a network where there exists an ABR that is announced as an ASBR in multiple non-backbone areas, and there exists another ABR that is in at least two of the same non-backbone areas 🫠.
d. Loop-free alternates should not be used in a non-backbone area of a network for AS External routes where an AS External prefix is advertised with the same type of external metric by multiple ASBRs, which are in different non-backbone areas, with a forwarding address of 0.0.0.0, or by one or more ASBRs with forwarding addresses in multiple non-backbone areas when an ABR exists simultaneously in two or more of those non-backbone areas 🌈.
3. Alternate Next-Hop Calculation ✨
okay so, besides the primary next-hops you get from the shortest path tree (SPT) computation that's already part of normal link-state routing, routers doing IP Fast Reroute also work out a set of backup next-hops 🦋 these kick in when a local failure happens. The backups are picked to give the protection type that's needed (link-protecting, node-protecting, or both) and to make sure that when the expected failure hits, sending traffic through them won't make a loop. 🔄 Throughout this spec, these are called loop-free alternates, or LFAs 💖
To work out the LFAs for a particular destination D, a router needs to know these basic things 👀
- Shortest-path distance from the calculating router to the destination (
Distance_opt(S, D)) - Shortest-path distance from the router's IGP neighbors to the destination (
Distance_opt(N, D)) - Shortest path distance from the router's IGP neighbors to itself (
Distance_opt(N, S)) Distance_opt(S, D)is usually already there from the regular SPF calculation that link-state protocols run 💅Distance_opt(N, D)andDistance_opt(N, S)come from running extra SPF calculations from the view of each IGP neighbor. So you treat the neighbor's vertex as the root of the SPT (called SPT(N) from here on), instead of the calculating router's SPT (called SPT(S)) 🌸
This spec defines a form of SRLG protection that's limited to SRLGs including a link the calculating router is directly connected to. 🧚 Only those SRLGs can cause a local failure, and the calculating router only computes alternates to handle local failures, so that's all that matters here. Local link SRLG membership is manually configured. Remote link SRLG membership may be dynamically learned using [RFC4205] or [RFC4203]. Define SRLG_local(S) as the set of SRLGs that include a link to which the calculating router S is directly connected. Only SRLG_local(S) is of interest during the calculation, but the calculating router must correctly handle changes to SRLG_local(S) triggered by local link SRLG membership changes. 🫶
To pick among all the available LFAs that give the required SRLG protection for a given destination, the calculating router has to track which SRLGs in SRLG_local(S) the path through a specific IGP neighbor involves. 🔥 So each node D in the network topology gets associated with SRLG_set(N, D), which is the set of SRLGs that would get crossed if traffic to D was forwarded through N. To work this out, the router starts SRLG_set(N, N) as empty for each of its IGP neighbors. During the SPT(N) calculation, when a new vertex V gets added to the SPT, its SRLG_set(N, V) is set to the union of the SRLG sets associated with its parents, plus the SRLG sets in SRLG_local(S) that are associated with the links from V's parents to V. The union of the SRLGs associated with a candidate alternate next-hop and the SRLG_set(N, D) for the neighbor reached through that candidate next-hop is what gets used to decide SRLG protection. ⭐
The next sections give the info needed to calculate LFAs. Sections 3.1 through 3.4 define the different LFA conditions. Section 3.5 covers the constraints that come from the IS-IS overload and OSPF stub router functionality. Section 3.6 gives the summarized LFA calculation algorithm, using the definitions from the earlier sections. 💜
3.1. Basic Loop-Free Condition 🎀
okay this one's the foundation bestie 💅 Alternate next hops used by implementations following this specification MUST conform to at least the loop-freeness condition stated above in Inequality 1. This condition is what guarantees that forwarding traffic to an LFA won't cause a loop after a link failure. 🔁
Extra conditions may be applied when figuring out link-protecting and/or node-protecting alternate next-hops, as described in Sections 3.2 and 3.3. ✨
3.2. Node-Protecting Alternate Next-Hops 🦢
so for an alternate next-hop N to protect against the node failure of a primary neighbor E for destination D, N must be loop-free with respect to both E and D. In other words, N's path to D must not go through E. 🙈 That's the case when Inequality 3 holds, where N is the neighbor providing a loop-free alternate.
Distance_opt(N, D) < Distance_opt(N, E) + Distance_opt(E, D)
Inequality 3: Criteria for a Node-Protecting Loop-Free AlternateIf Distance_opt(N,D) = Distance_opt(N, E) + Distance_opt(E, D), then it's possible that N has equal-cost paths and one of them could protect against E's node failure. 🥺 But it's equally possible that one of N's paths goes through E, and the calculating router has no way to influence N's decision to use it. So it SHOULD be assumed that an alternate next-hop does not offer node protection if Inequality 3 is not met. 🚫
3.3. Broadcast and Non-Broadcast Multi-Access (NBMA) Links 📡
checking link protection on a broadcast link is way more involved than on a point-to-point link 😭 That's because a broadcast link is modelled as a pseudo-node, with zero-cost links connecting it to the other nodes.
Since a failure of an interface on a broadcast segment can mean losing connectivity to the whole segment, the condition for broadcast link protection is pessimistic. It requires that the alternate is loop-free with regard to the pseudo-node. Check out the example in Figure 3 👇
+-----+ 15
| S |--------
+-----+ |
| 5 |
| |
| 0 |
/----\ 0 5 +-----+
| PN |-----| N |
\----/ +-----+
| 0 |
| | 8
| 5 |
+-----+ 5 +-----+
| E |----| D |
+-----+ +-----+
Figure 3: Loop-Free Alternate That Is Link-ProtectingIn Figure 3, N offers a loop-free alternate that is link-protecting. 🌈 If the primary next-hop uses a broadcast link, then an alternate SHOULD be loop-free with respect to that link's pseudo-node (PN) to provide link protection. This requirement is described in Inequality 4 below.
D_opt(N, D) < D_opt(N, PN) + D_opt(PN, D)
Inequality 4: Loop-Free Link-Protecting Criterion for Broadcast LinksBecause the shortest path from the pseudo-node goes through E, if a loop-free alternate from a neighbor N is node-protecting, then the alternate is also link-protecting, unless the router S can only reach the alternate neighbor N via the same pseudo-node. 🧐 That's the only case where a node-protecting LFA isn't link-protecting, which means that for point-to-point interfaces, an LFA that's node-protecting is always link-protecting. ✅ Because S can steer traffic off the shortest path and onto the alternate N, the traffic might cross the same broadcast link it would have crossed when S sent it to the primary E. So an LFA from N that's node-protecting is NOT automatically link-protecting for a broadcast or NBMA link. Wait, careful: the spec doesn't say NOT in caps, so bestie, that one's lowercase vibes: an LFA from N that is node-protecting is not automatically link-protecting for a broadcast or NBMA link. 🙃
To get link protection, two things are needed: the path from the selected alternate next-hop must not traverse the link of interest, and the link S uses to reach that alternate next-hop must not be the link of interest. The second part can only happen with non-point-to-point links. So if the primary next-hop is across a broadcast or NBMA interface, link protection has to be considered during alternate selection. 🦋 Using the Figure 3 topology: for N to provide link protection, N's shortest path to D first has to avoid the pseudo-node PN. Second, the alternate next-hop S picks must not traverse PN. In this example, S's shortest path to N goes through the pseudo-node, so to get link protection, S must find a next-hop to N (here, the point-to-point link from S to N) that avoids the pseudo-node PN. 🫠
The same kind of check on the link from S to the selected alternate next-hop, plus the path from that alternate next-hop, is also needed for SRLG protection. S's shortest path to the selected neighbor N might not be acceptable as an alternate next-hop for SRLG protection, even if the path from N to D can give SRLG protection. 💀
3.4. ECMP and Alternates 🍓
With Equal-Cost Multi-Path (ECMP), a prefix can have several primary next-hops for forwarding traffic. When one particular primary next-hop fails, alternate next-hops should be used to preserve the traffic. 🌸 These alternate next-hops may themselves be primary next-hops, but they don't have to be. Other primary next-hops aren't guaranteed to protect against the failure scenarios we care about.
20 L1 L3 3
[ N ]----[ S ]--------[ E3 ]
| | |
| 5 | L2 |
20 | | |
| --------- | 2
| 5 | | 5 |
| [ E1 ] [ E2 ]-----|
| | |
| 10 | 10 |
|---[ A ] [ B ]
| |
2 |--[ D ]-| 2
Figure 4: ECMP Where Primary Next-Hops Provide Limited ProtectionIn Figure 4, S has three primary next-hops to reach D: L2 to E1, L2 to E2, and L3 to E3. 🧚 The primary next-hop L2 to E1 can get link and node protection from L3 to E3, which is one of the other primary next-hops. L2 to E1 can't get link protection from the other primary next-hop, L2 to E2. Similarly, the primary next-hop L2 to E2 can only get node protection from L2 to E1, and can only get link protection from L3 to E3. 😬 The third primary next-hop, L3 to E3, can get link and node protection from L2 to E1 and from L2 to E2. It's possible for both the primary next-hop L2 to E2 and the primary next-hop L2 to E1 to get an alternate next-hop that provides both link and node protection, by using L1. 🎀
Alternate next-hops get figured out for each primary next-hop separately. Just like alternate selection in the non-ECMP case, these alternate next-hops should maximize coverage of the failure cases. 💖
3.5. Interactions with IS-IS Overload, RFC 3137, and Costed Out Links ✨
Okay bestie, so [RFC3137] explains that sometimes you really want a router to NOT be used as a transit node 🙅♀️ For those cases, it's also desirable to keep that router off the alternate path too. Same energy, different lane 💅
When a router is computing an alternate, it MUST NOT use an alternate next-hop that sits along a link whose cost or reverse cost is LSInfinity (for OSPF) or the maximum cost (for IS-IS), or that has the overload bit set (for IS-IS). 🚫 For a broadcast link, the reverse cost of a potential alternate next-hop is the cost toward the pseudo-node advertised by the next-hop router. For point-to-point links, if a specific link from the next-hop router can't be matched to a particular link, then the reverse cost we use is the minimum cost link from the next-hop router back to S.
In OSPF, if all links from router S to a neighbor N_i have a reverse cost of LSInfinity, then router S MUST NOT use N_i as an alternate.
Similarly, in IS-IS, if N_i has the overload bit set, then S MUST NOT consider using N_i as an alternate.
This keeps the behavior of steering traffic away from a router that is following [RFC3137] 🦋 It also keeps the behavior where an operator sets a link's cost to LSInfinity for maintenance, so traffic isn't allowed across that link unless there's no other path. Iconic, honestly 👑
If a link or router that is costed out was the only possible alternate to protect traffic from a particular router S to a particular destination, then there should be no alternate provided for protection. No backup means no backup, periodt 💀
3.5.1. Interactions with IS-IS Link Attributes
[RFC5029] describes several flags whose interactions with LFAs still need to be defined 🧐 So here's the deal: a router SHOULD NOT specify the "local protection available" flag just because it has LFAs. Also, a router SHOULD NOT use an alternate next-hop that's along a link advertised with the attribute "link excluded from local protection path" or with the attribute "local maintenance required". Those links are giving "do not touch" 🙈
3.6. Selection Procedure 🌸
A router supporting this specification SHOULD attempt to select at least one loop-free alternate next-hop for each primary next-hop used for a given prefix. A router MAY decide not to use an available loop-free alternate next-hop. A reason for that might be that the loop-free alternate next-hop doesn't protect against the failure scenario you care about. Totally valid 💖
The alternate selection should maximize the coverage of the failure cases. Think main character energy for coverage: the more failures covered, the better ✨
When calculating alternate next-hops, the calculating router S follows these rules:
- S SHOULD select a loop-free node-protecting alternate next-hop, if one is available. If no loop-free node-protecting alternate is available, then S MAY select a loop-free link-protecting alternate.
- If S has a choice between a loop-free link-and-node-protecting alternate and a loop-free node-protecting alternate that is not link-protecting, S SHOULD select a loop-free link-and-node-protecting alternate. This can happen as explained in Section 3.3. 🫶
- If S has multiple primary next-hops, then S SHOULD select as a loop-free alternate either one of the other primary next-hops or a loop-free node-protecting alternate if one is available. If no loop-free node-protecting alternate is available and no other primary next-hop can provide link-protection, then S SHOULD select a loop-free link-protecting alternate.
- Implementations SHOULD support a mode where other primary next-hops that satisfy the basic loop-free condition and provide at least link or node protection are preferred over any non-primary alternates. This mode lets the administrator keep traffic patterns based on regular ECMP behavior 🍓
- Implementations that consider SRLGs MAY use SRLG protection to determine that a node-protecting or link-protecting alternate is not available for use.
Following the above rules maximizes the level of protection and the use of primary (ECMP) next-hops. Protection AND efficiency, that's the dream 😭🔥
Each next-hop has a set of non-mutually-exclusive characteristics. These depend on whether it's used as a primary next-hop to a particular destination D, and on the type of protection it can provide relative to a specific primary next-hop E:
- Primary Path - The next-hop is used by S as primary.
- Loop-Free Node-Protecting Alternate - This next-hop satisfies Inequality 1 and Inequality 3. The path avoids S, S's primary neighbor E, and the link from S to E. 💜
- Loop-Free Link-Protecting Alternate - This next-hop satisfies Inequality 1 but not Inequality 3. If the primary next-hop uses a broadcast link, then this next-hop satisfies Inequality 4. 🌈
An alternate path may also provide none, some, or complete SRLG protection, as well as node and link protection or just link protection. For instance, a link may belong to two SRLGs, G1 and G2. The alternate path might avoid other links in G1 but not G2, in which case the alternate would only provide partial SRLG protection. Partial protection is still protection, bestie 🦋
Below is an algorithm you can use to calculate loop-free alternate next-hops. It's given for informational purposes, and implementations are free to use any other algorithm as long as it satisfies the rules above. ✨
The following procedure describes how to select an alternate next-hop. It's used to find alternate next-hops for reaching each router in the topology. Prefixes advertised by a single router can use the alternate next-hop computed for the router they're attached to. The same procedure can be used to reach a prefix advertised by more than one router when the logical topological transformation described in Section 6.1 is used. 🧚
S is the computing router. S has neighbors N_1 to N_j. A candidate next-hop is indicated by (outgoing link, neighbor), and the outgoing link must be bidirectionally connected, as determined by the IGP. The candidate next-hops of S are enumerated as H_1 through H_k. Remember that S may have multiple next-hops over different interfaces to a neighbor. H_i.link refers to the outgoing link of that next-hop, and H_i.neighbor refers to the neighbor of that next-hop.
For a particular destination router D, let S have already computed D_opt(S, D), and for each neighbor N_i, D_opt(N_i, D), D_opt(N_i, S), and D_opt(N_i, N_j) (the distance from N_i to each other neighbor N_j), along with the set of SRLGs traversed by the path D_opt(N_i, D). S should follow the procedure below for every primary next-hop selected to reach D. This set of primary next-hops is represented as P_1 to P_p. This procedure finds the alternate next-hop(s) for P_i.
First, initialize the alternate information for P_i as follows:
P_i.alt_next_hops = {}
P_i.alt_type = NONE
P_i.alt_link-protect = FALSE
P_i.alt_node-protect = FALSE
P_i.alt_srlg-protect = {}For each candidate next-hop H_h:
- Initialize variables as follows:
cand_type = NONE
cand_link-protect = FALSE
cand_node-protect = FALSE
cand_srlg-protect = {}- If H_h is P_i, skip it and continue to the next candidate next-hop.
- If H_h.link is administratively allowed to be used as an alternate, and the cost of H_h.link is less than the maximum, and the reverse cost of H_h is less than the maximum, and H_h.neighbor is not overloaded (for IS-IS), and H_h.link is bidirectional, then H_h can be considered as an alternate. Otherwise, skip it and continue to the next candidate next-hop. 🔍
- If
D_opt( H_h.neighbor, D) >= D_opt( H_h.neighbor, S) + D_opt(S, D), then H_h is not loop-free. Skip it and continue to the next candidate next-hop. 🚫 - Set
cand_type = LOOP-FREE. - If H_h is a primary next-hop, set
cand_typeto PRIMARY. - If H_h.link is not P_i.link, set
cand_link-protectto TRUE. - If
D_opt(H_h.neighbor, D) < D_opt(H_h.neighbor, P_i.neighbor) + D_opt(P_i.neighbor, D), setcand_node-protectto TRUE. - If the router considers SRLGs, then set
cand_srlg-protectto the set of SRLGs traversed on the path from S via P_i.link to P_i.neighbor. Remove the set of SRLGs to which H_h belongs fromcand_srlg-protect. Remove fromcand_srlg-protectthe set of SRLGs traversed on the path from H_h.neighbor to D. Nowcand_srlg-protectholds the set of SRLGs to which P_i belongs and that are not traversed on the path from S via H_h to D. 🎀 - If
cand_typeis PRIMARY, the router prefers other primary next-hops for use as the alternate, andP_i.alt_typeis not PRIMARY, goto Step 20. - If
cand_typeis not PRIMARY,P_i.alt_typeis PRIMARY, and the router prefers other primary next-hops for use as the alternate, then continue to the next candidate next-hop. - If
cand_node-protectis TRUE andP_i.alt_node-protectis FALSE, goto Paragraph 20. - If
cand_link-protectis TRUE andP_i.alt_link-protectis FALSE, goto Step 20. - If
cand_srlg-protecthas a better set of SRLGs thanP_i.alt_srlg-protect, goto Step 20. - If
cand_srlg-protectis different fromP_i.alt_srlg-protect, then select between H_h andP_i.alt_next_hopsbased upon distance, IP addresses, or any router-local tie-breaker. If H_h is preferred, goto Step 20. IfP_i.alt_next_hopsis preferred, skip H_h and continue to the next candidate next-hop. ⚖️ - If
D_opt(H_h.neighbor, D) < D_opt(P_i.neighbor, D)andD_opt(P_i.alt_next_hops, D) >= D_opt(P_i.neighbor, D), then H_h is a downstream alternate andP_i.alt_next_hopsis simply an LFA. Prefer H_h and goto Step 20. 👑 - Based upon the alternate types, the alternate distances, IP addresses, or other tie-breakers, decide if H_h is preferred to
P_i.alt_next_hops. If so, goto Step 20. - Decide if
P_i.alt_next_hopsis preferred to H_h. If so, then skip H_h and continue to the next candidate next-hop. - Add H_h into
P_i.alt_next_hops. SetP_i.alt_typeto the better type ofH_h.alt_typeandP_i.alt_type. Continue to the next candidate next-hop. - Replace the P_i alternate next-hop set with H_h as follows:
P_i.alt_next_hops = {H_h}
P_i.alt_type = cand_type
P_i.alt_link-protect = cand_link-protect
P_i.alt_node-protect = cand_node-protect
P_i.alt_srlg-protect = cand_srlg-protectContinue to the next candidate next-hop. 🎉
3.7. LFA Types and Trade-Offs 🎀
okay bestie, LFAs don't all protect you the same amount 💅 which type you should prefer depends on your network topology and what other techniques you're already running 🌸 this section breaks down the different protection levels and the trade-offs that come with each one ✨
- Primary Next-hop 🦋: when there are equal-cost primary next-hops, using one of them as an alternate is guaranteed not to cause micro-loops involving S 🙌 traffic goes across the paths the network is going to converge to, but congestion might show up on the primary paths since traffic is spread across fewer of them 😬 and all primary next-hops are downstream paths.
- Downstream Paths 💖: a downstream path, unlike an LFA, is guaranteed not to cause a micro-loop involving S no matter what failure actually gets detected. however, its expected coverage across a network is poor 💀 and all downstream paths are LFAs.
- LFA 🧚: an LFA can have good coverage of a network, depending on topology. however, it's possible to get micro-loops involving S if an unprotected failure happens (e.g., a node fails when the LFA was only link-protecting).
the different types of protection are abbreviated as LP (link-protecting), NP (node-protecting), and SP (SRLG-protecting) 🫶
a. LP, NP, and SP 👑: if an alternate like this exists, it gives protection against all failures.
b. LP and NP only 🌈: many networks may handle SRLG failures another way, or they may focus on node and link failures since those are more common.
c. LP only ⭐: a network may handle node failures with a high-availability technique and care mainly about protecting the more common link failure case.
d. NP only 🍓: these only exist on interfaces that aren't point-to-point. if link protection is handled at a different layer, then an NP alternate may be acceptable.
3.8. A Simplification: Per-Next-Hop LFAs 🌸
it's possible to simplify the computation and use of LFAs when you only want link protection 🙈 you just consider and compute one link-protecting LFA for each next-hop connected to the router. every prefix that uses that next-hop as a primary will use the LFA computed for that next-hop as its LFA 💅
even a prefix with multiple primary next-hops gets each primary next-hop protected individually, by the LFA associated with that primary next-hop 🦋 that associated LFA might or might not be another one of the prefix's primary next-hops, so no promises there 😅
this simplification may reduce coverage in a network 💜 on top of limiting protection for multi-homed prefixes (see Section 6.1), computing per next-hop might also fail to find an LFA even when one could've been found for some of the prefixes that use that next-hop 😭
for example, consider Figure 4 where S has three ECMP next-hops, E1, E2, and E3 to reach D. for the prefix D, E3 can give link protection for the next-hops E1 and E2, and E1 and E2 can give link protection for the next-hop E3. however, if you use this simplification to compute LFAs for E1, E2, and E3 individually, there's no link-protecting LFA for E1 🥺 E3 and E2 can protect each other, but E1 is left out in the cold.
4. Using an Alternate 🦋
if an alternate next-hop is available, the router redirects traffic to the alternate next-hop when a primary next-hop fails ✨ here's how it goes:
when a next-hop failure is detected, either through a local interface failure or another failure detection mechanism (see [FRAMEWORK]), the router SHOULD:
- Remove the primary next-hop associated with the failure.
- Install the loop-free alternate calculated for the failed next-hop if it isn't already installed (e.g., the alternate is also a primary next-hop).
note that the router MAY remove other next-hops if it believes (via SRLG analysis) that they may have been hit by the same failure, even if that isn't visible at the time the failure is detected 🔍
the alternate next-hop MUST be used only for traffic types that are routed according to the shortest path 🙅♀️ multicast traffic is specifically out of scope for this specification 💀
4.1. Terminating Use of Alternate 💅
a router MUST limit the amount of time an alternate next-hop is used after the primary next-hop has become unavailable 🕰️ this makes sure the router starts using the new primary next-hops. it also makes sure all the possible transient conditions get cleared out so the network converges according to the deployed routing protocol 🫶
there are techniques available to handle the micro-forwarding loops that can occur in a network during convergence 🌀
a router that implements [MICROLOOP] SHOULD follow the rules given there for terminating the use of an alternate 🌷
a router that implements [ORDERED-FIB] SHOULD follow the rules given there for terminating the use of an alternate 🌷
it's really desirable to avoid micro-forwarding loops involving S 😤 here's an example that shows the problem, in Figure 5. if the link from S to E fails, S will use N1 as an alternate and S will compute N2 as the new primary next-hop to reach D. if S starts using N2 as soon as S can compute and install its new primary, it's probable that N2 hasn't installed its new primary next-hop yet 😱 that would make traffic loop and get dropped until N2 has installed the new topology. this can be avoided by S delaying its installation and leaving traffic on the alternate next-hop 🙌
+-----+
| N2 |-------- |
+-----+ 1 | \|/
| |
| +-----+ @@> +-----+
| | S |---------| N1 |
10 | +-----+ 10 +-----+
| | |
| 1 | | |
| | \|/ 10 |
| +-----+ | |
| | E | | \|/
| +-----+ |
| | |
| 1 | | |
| | \|/ |
| +-----+ |
|----| D |--------------
+-----+Figure 5: Example Where Continued Use of Alternate Is Desirable
this is an example of a case where the new primary wasn't a loop-free alternate before the failure, so it may have been forwarding traffic through S 🌊 that happens when the path via a previously upstream node is shorter than the path via a loop-free alternate neighbor. in these cases, it's useful to give enough time to make sure the new primary neighbor and the other nodes on the new primary path have switched over to the new route ⏳
if the newly selected primary was loop-free before the failure, then it's safe to switch to that new primary immediately 🏃♀️ the new primary didn't depend on the failure, so its path won't have changed ✨
given that there's an alternate providing appropriate protection, and while the single failure assumption holds, it's safe to delay installing the new primaries 🛡️ this won't create forwarding loops, because the alternate's path to the destination is known not to go via S or the failed element, so the failure won't affect it 💖
an implementation SHOULD continue to use the alternate next-hops for packet forwarding even after the new routing information is available based on the new network topology 🌈 the use of the alternate next-hops for packet forwarding SHOULD terminate:
a. if the new primary next-hop was loop-free prior to the topology change, or
b. if a configured hold-down, which represents a worst-case bound on the length of the network convergence transition, has expired, or
c. if notification of an unrelated topological change in the network is received.
5. Requirements on LDP Mode 🌈
since LDP [RFC5036] traffic follows the path specified by the IGP, it's also possible for LDP traffic to follow the loop-free alternates the IGP indicates ✨ to do that, LDP needs the right labels available for the alternate, so the appropriate out-segments can be installed in the forwarding plane before the failure happens 💅
this means that a Label Switching Router (LSR) running LDP must distribute its labels for the Forwarding Equivalence Classes (FECs) it can provide to all its neighbors, whether or not they're upstream 📣 on top of that, LDP must be acting in liberal label retention mode so the labels for neighbors that aren't currently the primary neighbor get stored 💾 similarly, LDP should be in downstream unsolicited mode, so the labels for the FEC get distributed other than along the SPT 🧚
if these requirements are met, then LDP can use the loop-free alternates without needing any targeted sessions or signaling extensions for this purpose 🎉
6. Routing Aspects 👑
6.1. Multi-Homed Prefixes 🍓
okay so an SPF-like computation runs for each topology, and each topology lines up with a particular OSPF area or IS-IS level. the IGP needs to work out loop-free alternates for multi-homed routes. these show up for routes pulled in from outside the routing domain by several routers, for subnets on links where the subnet is announced from multiple ends of the link, and for routes advertised by multiple routers for resiliency 💅
Figure 6 is the vibe. the shortest path to prefix p goes through E, so p has the link to E as its primary next-hop. if p's alternate next-hop just gets inherited from the router that advertised it on the shortest path, the alternate ends up being the link to C. that gives link protection, but not the node protection you could get through A. ngl that's a missed opportunity 😭
5 +---+ 8 +---+ 5 +---+
------| S |------| A |-----| B |
| +---+ +---+ +---+
| | |
| 5 | 5 |
| | |
+---+ 5 +---+ 5 7 +---+
| C |---| E |------ p -------| F |
+---+ +---+ +---+
Figure 6: Multi-Homed Prefixto get the best protection possible, prefix p can be treated in the SPF computations as a node with unidirectional links to it from the routers that have advertised the prefix. that node never needs its links explored, since it has no out-going links. so cute, right? 🫶
if there are multiple multi-homed prefixes that share the same connectivity and the difference in metrics to those routers, then one node can represent the whole group. for example, in Figure 6, if there were another prefix X connected to E with a metric of 1 and to F with a metric of 3, then prefix X could just use the same alternate next-hop computed for prefix p 🧚
A router SHOULD compute the alternate next-hop for an IGP multi-homed prefix by considering alternate paths via all routers that have announced that prefix. the main idea is to look at every router that announced it, not just one.
In all cases, a router MAY safely simplify the multi-homed prefix (MHP) calculation by assuming that the MHP is solely attached to the router that was its pre-failure optimal point of attachment. however, this may result in a prefix not being considered repairable, when the full computation would show that a repair was possible. so it's a trade-off, bestie 🌸
6.2. IS-IS 🦋
the applicability and interactions of LFAs with multi-topology IS-IS [RFC5120] are out of scope for this specification. so this doc isn't going there, periodt.
6.3. OSPF 💜
OSPF is a little messy because the traffic path can exit an area and then re-enter that same area. this can happen whenever a router considers the same route from multiple areas. there are a few cases where this kind of thing can happen, and they all come down to another area allowing a shorter path to connect two ABRs than the one available in the area where the LFA was computed. to make it clearer, there's an example topology in Appendix A 🎀
- a. Virtual Links: these let paths leave the backbone area and traverse the transit area. the path provided via the transit area can exit via any ABR. the path taken is not the shortest path determined by running an SPF in the backbone area.
- b. Alternate ABR [RFC3509]: when an ABR is not connected to the backbone, it considers the inter-area summaries from multiple areas. ABR A may decide to use area 2, but that path could traverse another alternate ABR B that decides to use area 1. this can lead to scenarios similar to the one illustrated in Figure 7.
- c. ASBR Summaries: an ASBR may itself be an ABR and can be announced into multiple areas. this gives other ABRs a decision to make about which area to use. this is the example illustrated in Figure 7.
- d. AS External Prefixes: a prefix may be advertised by multiple ASBRs in different areas, and/or with multiple forwarding addresses that are in different areas, which are connected via at least one common ABR. this presents such ABRs with a decision about which area to use to reach the prefix.
loop-free alternates should not be used in an area where one of the above issues affects that area. so if you spot one of these, skip it, no cap 🙈
6.3.1. OSPF External Routing 🌈
when a forwarding address is set in an OSPF AS-external Link State Advertisement (LSA), all routers in the network calculate their next-hops for the external prefix by doing a lookup for the forwarding address in the routing table, rather than using the next-hops calculated for the ASBR. in this case, the alternate next-hops SHOULD be computed by selecting among the alternate paths to the forwarding link(s) instead of among alternate paths to the ASBR. that's the glow-up here ✨
6.3.2. OSPF Multi-Topology 🌸
the applicability and interactions of LFAs with multi-topology OSPF [RFC4915] [MT-OSPFv3] are out of scope for this specification. not this doc's problem, bestie.
6.4. BGP Next-Hop Synchronization 💖
typically, BGP prefixes are advertised with the AS exit router's router-id as the BGP next-hop, and the AS exit routers are reached by means of IGP routes. BGP resolves its advertised next-hop to the immediate next-hop by potential recursive lookups in the routing database. IP Fast Reroute computes the alternate next-hops to all IGP destinations, and that includes alternate next-hops to the AS exit router's router-id. BGP just inherits the alternate next-hop from the IGP, which is so easy. the BGP decision process is unaltered; BGP keeps using the IGP optimal distance to find the nearest exit router. multicast BGP (MBGP) routes don't need to copy the alternate next-hops 🫶
it is possible to provide ASBR protection if BGP selected a set of BGP next-hops and let the IGP determine the primary and alternate next-hops as if the BGP route were a multi-homed prefix. that's for future study, so stay tuned 👀
6.5. Multicast Considerations 🦋
multicast traffic is out of scope for this specification of IP Fast Reroute. the alternate next-hops SHOULD NOT be used for multicast Reverse Path Forwarding (RPF) checks. so keep those separate, okay? 💅
7. Security Considerations 🔥
the mechanism described in this document does not modify any routing protocol messages, so no new threats related to packet modifications or replay attacks are introduced. traffic to certain destinations can be temporarily routed via next-hop routers that wouldn't be used with the same topology change if this mechanism wasn't employed. however, those next-hop routers can be used anyway when a different topological change occurs, so this can't be viewed as a new security threat. it's not a new danger, but still treat it seriously 💀
in LDP, the wider distribution of FEC label information still goes to neighbors with whom a trusted LDP session has been established. this wider distribution, along with the recommendation to use liberal label retention mode, is believed to have no significant security impact. the trusted-session part is the important bit here, so please don't skip it ⭐
8. Acknowledgements 💜
the authors would like to thank Joel Halpern, Mike Shand, Stewart Bryant, and Stefano Previdi for their assistance and useful review. the real MVPs 👑
9. References 🌈
9.1. Normative References
[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2328]Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.[RFC2740]Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.[RFC5036]Andersson, L., Minei, I., and B. Thomas, "LDP Specification", RFC 5036, October 2007.
9.2. Informative References
[FRAMEWORK]Shand, M. and S. Bryant, "IP Fast Reroute Framework", Work in Progress, February 2008.[MICROLOOP]Zinin, A., "Analysis and Minimization of Microloops in Link-state Routing Protocols", Work in Progress, October 2005.[MT-OSPFv3]Mirtorabi, S. and A. Roy, "Multi-topology routing in OSPFv3 (MT-OSPFv3)", Work in Progress, July 2007.[ORDERED-FIB]Francois, P., "Loop-free convergence using oFIB", Work in Progress, February 2008.[RFC1195]Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.[RFC2966]Li, T., Przygienda, T., and H. Smit, "Domain-wide Prefix Distribution with Two-Level IS-IS", RFC 2966, October 2000.[RFC3137]Retana, A., Nguyen, L., White, R., Zinin, A., and D. McPherson, "OSPF Stub Router Advertisement", RFC 3137, June 2001.[RFC3509]Zinin, A., Lindem, A., and D. Yeung, "Alternative Implementations of OSPF Area Border Routers", RFC 3509, April 2003.[RFC4203]Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.[RFC4205]Kompella, K. and Y. Rekhter, "Intermediate System to Intermediate System (IS-IS) Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4205, October 2005.[RFC4915]Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.[RFC5029]Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link Attribute Sub-TLV", RFC 5029, September 2007.[RFC5120]Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, February 2008.[RFC5340]Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
Appendix A. OSPF Example Where LFA Based on Local Area Topology Is Insufficient ✨
okay so this appendix is basically a little story 🦋 about a case where you look at your own area's map and still can't prove a loop-free alternate (LFA) exists. ngl it's giving plot twist 💀
It's the follow-up to Section 6.3 🫶. That section flagged one problem scenario for ASBR summaries: the ASBR is reachable in two areas through intra-area routes, and there's at least one ABR, or an alternate ABR, that sits in both areas. Figure 7 is the exact setup 💅
5
[ F ]-----------[ C ]
| |
| | 5
20 | 5 | 1
| [ N ]-----[ A ]*****[ F ]
| | # *
| 40 | # 50 * 2
| | 5 # 2 *
| [ S ]-----[ B ]*****[ G ]
| | *
| 5 | * 15
| | *
| [ E ] [ H ]
| | *
| 5 | * 10**
| | *
|---[ X ]----[ ASBR ]
5
---- Link in Area 1
**** Link in Area 2
#### Link in Backbone Area 0
Figure 7: Topology with Multi-Area ASBR Causing Area TransitingOkay the vibe of this diagram: the ASBR is also an ABR 🌸 and it gets announced into both area 1 and area 2. A and B are both ABRs and both of them are plugged into the backbone too 👑
Now the drama 😭 S figures out that N can be its loop-free alternate to get to the ASBR. N's path goes through A. But A also sees an intra-area route to the ASBR through area 2, and that path costs 30. Area 1 would cost 35, and 30 is less than 35, so A picks area 2 and sends traffic over to F 🎀 From F, the area 2 path heads to B.
Then B is like "wait, I see the ASBR from both areas too" 🙈 Its area 1 path costs 20 and its area 2 path costs 25, so B goes with area 1 and uses the path that connects to S. So yeah, the packet bounces around between areas before it gets where it's going. That's the "area transiting" in the figure caption, and it's why looking only at the local area isn't enough to prove the LFA works 🧚
Authors' Addresses
Alia K. Atlas (editor) BT
EMail: alia.atlas@bt.com
Alex Zinin (editor) Alcatel-Lucent 750D Chai Chee Rd, #06-06 Technopark@ChaiChee Singapore 469004
EMail: alex.zinin@alcatel-lucent.com
Raveendra Torvi FutureWei Technologies Inc. 1700 Alma Dr. Suite 100 Plano, TX 75075 USA
EMail: traveendra@huawei.com
Gagan Choudhury AT&T 200 Laurel Avenue, Room D5-3C21 Middletown, NJ 07748 USA
Phone: +1 732 420-3721 EMail: gchoudhury@att.com
Christian Martin iPath Technologies
EMail: chris@ipath.net Brent Imhoff Juniper Networks 1194 North Mathilda Sunnyvale, CA 94089 USA
Phone: +1 314 378 2571 EMail: bimhoff@planetspork.com
Don Fedyk Nortel Networks 600 Technology Park Billerica, MA 01821 USA
Phone: +1 978 288 3041 EMail: dwfedyk@nortelnetworks.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
📦 where this page comes from
- ietf: rfc5286 2008-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms