RFC 6981
A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses
Part 1 of 8 🎀
RFC 6981: A Framework for IP and MPLS Fast Reroute Using Not-Via Addresses 💖
Okay bestie, this one is an Informational RFC from the IETF, so it's not a standard, it's a "here's the design thinking, put it on record" kind of doc 📝. It's dated August 2013 and the ISSN is 2070-1721. The authors are S. Bryant and S. Previdi from Cisco Systems, plus M. Shand, who's listed as an Individual Contributor. There's no Obsoletes or Updates line in its header, so it doesn't replace or change any other RFC ✨.
Abstract
Okay so this doc lays out an illustrative framework for fast reroute in an IP or MPLS network. The trick is encapsulating packets and forwarding them to "not-via" addresses 🦋. The general approach uses a single level of encapsulation, and it could protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics. It's giving robust 💅.
The mechanisms here are purely illustrative of the general approach, so they are not a protocol specification 🧚. The document is a snapshot of the Routing Area Working Group's work at the time it was published, and it's published as a document of record. More work is needed before anyone implements or deploys this, so don't rush it, periodt 🫶.
Status of This Memo
This document is not an Internet Standards Track specification. It's published for informational purposes only 🌈.
It's a product of the Internet Engineering Task Force (IETF), it represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🔥. Not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that bit.
For the current status, any errata, and how to give feedback, check http://www.rfc-editor.org/info/rfc6981 🔗.
Copyright Notice
Copyright (c) 2013 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 extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they're provided without warranty as described in the Simplified BSD License ⭐.
Table of Contents
1. Introduction ....................................................4
1.1. The Purpose of This Document ...............................4
1.2. Overview ...................................................4
2. Requirements Language ...........................................5
3. Overview of Not-Via Repairs .....................................5
3.1. Use of Equal-Cost Multi-Path ...............................6
3.2. Use of LFA Repairs .........................................6
4. Not-Via Repair Path Computation .................................7
4.1. Computing Not-Via Repairs in Distance and Path
Vector Routing Protocols ...................................8
5. Operation of Repairs ............................................8
5.1. Node Failure ...............................................8
5.2. Link Failure ...............................................9
5.2.1. Loop Prevention under Node Failure ..................9
5.3. Multi-Homed Prefixes .......................................9
5.4. Installation of Repair Paths ..............................11
6. Compound Failures ..............................................12
6.1. Shared Risk Link Groups ...................................12
6.2. Local Area Networks .......................................17
6.2.1. Simple LAN Repair ..................................18
6.2.2. LAN Component Repair ...............................19
6.2.3. LAN Repair Using Diagnostics .......................19
6.3. Multiple Independent Failures .............................20
6.3.1. Looping Repairs ....................................20
6.3.2. Outline Solution ...................................21
6.3.3. Mutually Looping Repairs ...........................22
6.3.3.1. Dropping Looping Packets ..................23
6.3.3.2. Computing Non-looping Repairs of Repairs ..23
6.3.4. Mixing LFAs and Not-Via ............................25
7. Optimizing Not-Via Computations Using LFAs .....................26
8. Multicast ......................................................27
9. Fast Reroute in an MPLS LDP Network ............................27
10. Encapsulation .................................................28
11. Routing Extensions ............................................28
12. Incremental Deployment ........................................28
13. Manageability Considerations ..................................29
13.1. Pre-failure Configuration ................................29
13.2. Pre-failure Monitoring and Operational Support ...........29
13.3. Failure Action Monitoring ................................30
14. Security Considerations .......................................30
15. Acknowledgements ..............................................31
16. References ....................................................31
16.1. Normative References .....................................31
16.2. Informative References ...................................31
Appendix A. Q-Space ...............................................331. Introduction ✨
1.1. The Purpose of This Document
Okay so this doc is an illustrative framework for fast reroute around a failure in an IP or MPLS network 🌸. The idea is tunneling or encapsulating packets via an IP address that's known to avoid the failure. The general approach uses a single level of encapsulation and could protect unicast, multicast, and LDP traffic against link, router, and shared risk group failure, regardless of network topology and metrics.
At publication, there was no demand to deploy this tech 🙈. But the subtleties in designing routing protocol extensions for IP Fast Reroute (IPFRR) [RFC5714] are a lot, so the Routing Area Working Group thought it was worth publishing this doc to put the design considerations of the not-via address approach on record 📚.
The mechanisms here are purely illustrative of the general approach and are not a protocol specification. The doc is a snapshot of the working group's work at publication and is published as a document of record. Additional work is needed to specify the necessary routing protocol extensions necessary to support this IPFRR method before implementation or deployment 🫶.
1.2. Overview
When a link or a router fails, only its neighbors know it happened at first 👀. In a network running IPFRR [RFC5714], the routers that neighbor the failure are the ones that repair it 🔧. These repairing routers have to steer packets to their destinations even though most other routers in the network don't know the nature or location of the failure. Main character energy 👑.
A common limitation in most IPFRR mechanisms is that they can't indicate what the failure is and explicitly steer the repaired packet around it 💀. How much this limitation hurts repair coverage depends on the topology. The mechanism proposed here is to encapsulate the packet to an address that explicitly identifies the network component the repair must avoid. Provided the network isn't partitioned by the failure, this always achieves a repair 💖.
2. 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] 📏.
3. Overview of Not-Via Repairs
Okay this section gives a quick tour of the not-via method of IPFRR 🦋. Check out the network fragment in Figure 1. S has a packet for some destination D that it would normally send via P and B, and S suspects P has failed 😭.
A
| Bp is the address to use to get
| a packet to B not via P
|
S----------P----------B. . . . . . . . . .D
\ | Bp^
\ | |
\ | |
\ C |
\ |
X-------Y-------Z
Repair to Bp
Figure 1: Not-Via Repair of Router FailureSo in the not-via IPFRR method, S encapsulates the packet to Bp 🎀. Bp is an address on node B with the property of not being reachable from node P. In other words, the notation Bp means "an address of node B that is only reachable not via node P" 💅. We'll show later how to install the path from S to Bp so it's the shortest path from S to B not going via P ✨. If the network has a path from S to B that doesn't transit router P (so the failure of P doesn't partition the network) and the path from S to Bp has been installed, then the packet gets delivered to B 🚀. In Figure 1, that path is S-X-Y-Z-B. When the packet addressed to Bp reaches B, B removes the encapsulation and forwards the repaired packet toward its final destination 🎉.
Note that if the path from B to the final destination includes one or more nodes that are in the repair path, a packet may backtrack after the encapsulation is removed 🙃. But the decapsulating router is always closer to the packet destination than the encapsulating router, so the packet won't loop 🔁.
For complete protection, all of P's neighbors will need a not-via address that lets traffic get to them without traversing P. That's shown in Figure 2 💫. Similarly, P will need a set of not-via addresses (one for each neighbor) so traffic can get to P without traversing each of those neighbors 💜.
The not-via addresses are advertised in the routing protocol in a way that clearly marks them as not-via addresses and not as 'ordinary' addresses 🏷️.
A
|Ap
|
Sp Pa|Pb
S----------P----------B
Ps|Pc Bp
|
Cp|
C
Figure 2: The Set of Not-Via P Addresses3.1. Use of Equal-Cost Multi-Path
Okay so a router can use an Equal-Cost Multi-Path (ECMP) repair in place of a not-via repair 🌈.
A router computing a not-via repair path MAY subject the repair to ECMP 🍓.
⬇️ Part 2 is coming up next, bestie 🫶💖
3.2. Use of LFA Repairs
okay so not-via gives you complete repair coverage 💅, which means it can be the only repair mechanism you use. ngl though, pairing it with Loop-Free Alternates (LFAs) and/or downstream paths from [RFC5286] is lowkey a great move 🦋. LFAs don't need extra IP addresses assigned and managed for every node 🙈, they don't need every router in the network upgraded just to work out not-via repair paths, and they don't use encapsulation at all. no encap, no problem, periodt 🎀.
LFAs get computed per destination, so usually only some of the destinations that need repair will have a good LFA repair 🌸. so the plan is: the ones LFAs can fix get fixed by LFAs, and everything else gets the not-via encapsulation treatment ✨. the thing is, an LFA path might be a bit less optimal than the equivalent not-via path for traffic heading to nodes near the far end of the failure 😭, but for some other traffic it might actually be more optimal 🌈. this doc assumes LFAs get used wherever they're available, but how repairs get split between the two mechanisms is a local implementation choice, so each implementation gets to decide 💜.
4. Not-Via Repair Path Computation ✨
the not-via repair mechanism requires that every router on the path from S to B (Figure 1) has a route to Bp. they can figure that out by pretending node P has failed, running a Shortest Path First (SPF) algorithm, and finding the shortest route to B 🧚.
here's the tricky bit: a router has no simple way of knowing whether it's on the shortest path for any particular repair 🙈. so every router has to calculate the path it would use if any possible router failed. each router basically "fails" every router in the network, one at a time, and works out its own best route to each of that router's neighbors 💅. so with Figure 1, routers A, B, C, X, Y, Z, and P will each take a turn considering every router, assuming it's dead, and then calculating their own route to each not-via address advertised by that router's neighbors. for example, if P is presumed to have failed, ALL routers (S, A, B, C, X, Y, and Z in this case) work out their routes to Sp, Ap, Bp, and Cp, each one not via P 🫶.
to do this, a router has to calculate n-1 SPFs, where n is the number of routers in the network. that's expensive 😭. luckily, there's a smarter way: each router (X) does the following. first, X calculates the base topology with all routers working and works out its normal path to all not-via addresses. this can happen as part of the normal SPF computation 🌸. then, for each router P in the topology, X does these steps:
- Removes router
Pfrom the topology. - Performs an incremental SPF (iSPF) [ISPF] on the modified topology. the iSPF process involves detaching the sub-tree affected by the removal of router
Pand then reattaching the detached nodes. but it's not necessary to run the iSPF all the way to the end. it's enough to run it until every node advertising not-viaPaddresses has been reattached to the Shortest Path Tree (SPT), and then stop there ✨. - Reverts to the base topology.
this algorithm is way cheaper than a set of full SPFs 💖. so even though a router has to work out repair paths for n-1 failures, the computing effort is much less than n-1 full SPFs 🎀.
experiments on some real-world network topologies with between 40 and 400 nodes suggest that, using the optimizations above, the worst-case computational complexity works out to roughly the same as doing between 5 and 13 full SPFs 🔥. more optimizations are described in Section 6 👑.
4.1. Computing Not-Via Repairs in Distance and Path Vector Routing Protocols
this doc focuses on link-state routing protocols, but it's totally possible to compute not-via repairs in distance vector protocols (like RIP) or path vector protocols (like BGP) too 🌈. you can do it with very little protocol modification: advertise the not-via address the normal way, but make sure the info about a not-via address Ps doesn't get propagated through node S 🙈. for link protection, that just means the advertisement from P to S gets suppressed, so S and every other node computes a route to Ps that doesn't go through S, which is exactly what we want 💅.
for node protection, where P is the protected node and N is some neighbor, the advertisement of Np needs to be suppressed not only across the link N-P, but also across any link to P 😭. the simplest way to do that is for P itself to suppress any address of the form Xp 💜.
5. Operation of Repairs 🦋
this section explains the basic operation of the not-via repair for node and link failure 🌸.
5.1. Node Failure
when router P fails (Figure 2), S encapsulates any packet it would send to B via P to Bp, then sends the encapsulated packet along the shortest path to Bp 🎀. S does the same thing for routers A and C in Figure 2. the packet gets decapsulated at the repair target (A, B, or C) and then forwarded normally to its destination ✨. the repair target can be figured out as part of the normal SPF by recording the "next-next hop" for each destination, on top of the normal next hop. the next-next hop is the router that the next-hop router sees as its own next hop to the destination 🧚. in Figure 1, B is S's next-next hop to D 💖.
notice that with this technique, only one level of encapsulation is needed 🙌, and it's possible to repair ANY failure regardless of link metrics and any asymmetry that might be in the network 👑. the only exception is when the failure was a single point of failure that split the network in two, because then ANY repair is clearly impossible 💀.
5.2. Link Failure
the normal mode of operation would be to assume router failure 🌈. but where some destinations are only reachable through the failed router, it's desirable to try repairing to those destinations by assuming only a link failure has happened 🙈.
to do a link repair, S encapsulates to Ps (basically it tells the network to deliver the packet to P not via S) 💅. all of S's neighbors have already calculated a path to Ps in case S itself had failed, so S could hand the packet to any of its neighbors (except, of course, P) 🫶. however, S SHOULD send the encapsulated packet along the shortest available path to P ✨. that path is calculated by running an SPF with the link S-P removed. this might again be an incremental calculation, which can stop once address Ps has been reattached 🌸.
5.2.1. Loop Prevention under Node Failure
we need to think about how IPFRR solutions behave when a link repair is attempted in the presence of node failure 😭. in its simplest form, the not-via IPFRR solution prevents loops from forming due to mutual repair, by never providing a repair path for a not-via address 🔥. the repair of packets with not-via addresses is covered in more detail in Section 6.3 💜.
here's how it plays out. referring to Figure 2, say A was the neighbor of P on the link repair path from S to P, and P itself had failed. the repaired packet from S would arrive at A encapsulated to Ps. A would notice that the A-P link had failed and would normally try to repair the packet 🙈. but no repair path is provided for any not-via address, so A is forced to drop the packet, which prevents a loop from forming 💀✨.
5.3. Multi-Homed Prefixes
a Multi-Homed Prefix (MHP) is a prefix that's reachable via more than one router in the network 🌈. some of these can be repaired using LFAs as described in [RFC5286], so only the ones without such a repair need to be considered here 🎀.
when IPFRR router S (Figure 3) discovers that P has failed, it needs to send packets addressed to the MHP X, which is normally reachable through P, to an alternate router that can still reach X 🦋.
X X X
| | |
| | |
| Sp |Pb |
Z...............S----------P----------B...............Y
Ps|Pc Bp
|
Cp|
C
Figure 3: Multi-Homed PrefixesS SHOULD choose the closest router that can reach X during the failure as the alternate router 🧚. S figures out which router to use as the alternate while running the SPF with P removed. this happens through the normal process of reattaching a leaf node to the core topology (sometimes called a "partial SPF") 💖.
first, consider the case where the shortest alternate path to X goes via Z. S can reach Z without using the removed router P 🙌. but S can't just send the packet towards Z, because the other routers in the network won't know about the failure of P and might loop the packet right back to S 😭. so S encapsulates the packet to Z (using a normal address for Z). when Z receives the encapsulated packet, it removes the encapsulation and forwards the packet to X ✨.
now consider the case where the shortest alternate path to X goes via Y, which S reaches via P and B. to reach Y, S has to repair the packet to B first, using the normal not-via repair mechanism 🌸. so S encapsulates the packet for X to Bp. when B receives it, B removes the encapsulation and sees that the packet is meant for MHP X 💅. the situation now goes back to the previous case, where the shortest alternate path doesn't need to cross the failure. so B follows the algorithm above and encapsulates the packet to Y (using a normal address for Y). Y removes the encapsulation and forwards the packet to X 👑.
it might be that the cost of reaching X by local delivery from the alternate router (that is, Z or Y) is higher than the cost of reaching X via P 🙈. in that case, the alternate router would normally forward to X via P, which would make the IPFRR repair loop 💀. to stop the repair from looping, the alternate router MUST locally deliver a packet it received via a repair encapsulation 🔥. this may be specified by using a special address with the above semantics 🧚.
note that only one such address is required per node 🫶. and notice that with the not-via approach, only one level of encapsulation was needed to repair MHPs to the alternate router 🎀✨.
5.4. Installation of Repair Paths ✨
okay so this is the part where node S (Figure 3) does its prep work 🧚 It pre-calculates the repair paths and installs them in the Forwarding Information Base (FIB) before anything breaks, so they're ready to go instantly. 💅 This assumes the not-via repair paths were already calculated like we covered above.
For each neighbor P, consider all destinations that are reachable via P in the current topology:
- For all destinations with an ECMP or LFA repair (as described in [RFC5286]), install that repair. 🫶
- For each destination (
DR) that remains, figure out the next-next hop (H) in the current topology. That's the neighbor of P that P will use to send the packet toDR. You can get this during the normal SPF run by recording the extra info 📝 If S has a path to the not-via addressHp(H not via P), install a not-via repair toHpfor the destinationDR. 🎀 - Find all the leftover destinations (
M) that can still be reached when node P fails. These are multi-homed prefixes that LFA can't repair 🙈 The normal attachment node for them is P (or a router where P is a single point of failure), and they have another attachment point that's still reachable after P goes down. You can find these by running an SPF rooted at S with node P removed, or an implementation might just record the alternative attachment points during the normal SPF run. Either way, the next-best point of attachment can also be worked out for step (4) below. 🌸 - For each multi-homed prefix (
M) from step (3):
A. Identify the new attachment node (as shown in Figure 3). It could be:
Y, where the next hop towards Y is P, orZ, where the next hop towards Z is not P.
If the attachment node is Z, install the repair for M as a tunnel to Z' (where Z' is the address of Z that is used to force local forwarding). 🦋
B. For the prefixes (M) that are left (the ones with attachment point Y), install the repair path that was already installed for destination Y. ✨
For each destination (DS) that remains, install a not-via repair to Ps (P not via S). These are destinations where node P is a single point of failure, so the only way to repair them is to pretend the apparent failure of node P was really just a failure of the S-P link. 😭 If one's available, a downstream path to P MAY be used for this kind of repair. It can't cause a persistent loop when node P fails. But if one neighbor of P uses a not-via repair and another uses a downstream path, a packet sent down the downstream path could come back to the sending node inside a not-via encapsulation. Since packets headed to not-via addresses don't get repaired, that packet gets dropped after one single turn of the loop. 💀
Note that when there are multiple next-next hops that can reach DR, any or several of them can be picked from a routing correctness point of view. Unless something else needs to be considered, the closest next-next hop to the repairing router is the normal choice. 👑
6. Compound Failures ✨
okay so compound failures are when more than one component goes down at once, and it's a whole different vibe 🥺 These are the types that involve more than one component:
- Shared Risk Link Groups 🔥
- Local Area Networks 🌈
- Multiple Independent Failures 💜
The considerations for each of these situations are described in the sections that follow. 🧚
6.1. Shared Risk Link Groups 🎀
okay bestie, so a Shared Risk Link Group (SRLG) is a bundle of links that can all die together because of one single oopsie, like a conduit getting cut or a line card giving up 💀. When a link in an SRLG fails, you MUST assume every other link in that same SRLG failed too 😭. So your repair path has to dodge not just the adjacent link but every link in the same SRLG. main character avoidance behavior 💅
Check out Figure 4 🦋. The links S-P and A-B are both in SRLG "a". That means the not-via address Ps changes meaning from "P not via the link S-P" to "P not via the link S-P or any other link that shares an SRLG with S-P." In this figure, that's S-P and A-B. Everyone computing routes to Ps can work this out because SRLG membership for every link lives in the link-state database, so they just fail all the SRLG links when running the iSPF. big brain energy ✨
S doesn't need to repair to other nodes hanging off SRLG members (like B). Repairing to the far end of the adjacent link (P here) is enough 🫶
a Ps
S----------P---------D
| |
| a |
A----------B
| |
| |
C----------E
Figure 4: Shared Risk Link GroupSometimes the SRLG links sit in series on the path from S to the destination D, like in Figure 5 🌸. Then you might need multiple consecutive repairs: S repairs to Ps, then P repairs to Dp. Both get computed while avoiding all SRLG "a" members, since those links are all in "a".
a Ps a Dp
S----------P---------D
| | |
| a | |
A----------B |
| | |
| | |
C----------E---------F
Figure 5: Shared Risk Link Group Members in Series -
Decapsulation and Re-encapsulation by One NodeMultiple repairs in series add a bit of overhead, but these semantics avoid a potential combinatorial explosion of not-via addresses. worth it 💖
Only a single level of encapsulation is required, even with multiple repairs 🧚. The first repair packet gets decapsulated before it's re-encapsulated using the not-via address for the far side of the next link in the same SRLG. Sometimes the decapsulation and re-encapsulation happen at one node (at least notionally), and sometimes different nodes handle them. See Figure 6.
a Ps a Dg
S----------P---------G--------D
| | | |
| a | | |
A----------B | |
| | | |
| | | |
C----------E---------F--------H
Figure 6: Shared Risk Link Group Members in Series -
Decapsulation and Re-encapsulation by Different NodesIn Figure 6, S first encapsulates to Ps, and node P decapsulates the packet and forwards it "native" to G using its normal FIB entry for destination D. Then G repairs the packet to Dg 💅
Multiple repairs like this can never form a loop, and there's a proof for it 🤓. Each repair moves the packet closer to its destination 🔁
A single link can be a member of multiple SRLGs, and those SRLGs might not be isomorphic. Figure 7 shows this 🎀
ab Ps a Dg
S----------P---------G--------D
| | | |
| a | | |
A----------B | |
| | | |
| b | | b |
C----------E---------F--------H
| |
| |
J----------K
Figure 7: Multiple Shared Risk Link GroupsThe link S-P is a member of SRLGs "a" and "b". When S-P fails, you MUST assume BOTH SRLGs failed. So the not-via path to Ps has to be computed by failing all links in SRLG "a" or SRLG "b". The semantics of Ps are now "P not via any links that are members of any of the SRLGs that link S-P belongs to." See Figure 8.
ab Ps a Dg
S----/-----P---------G---/----D
| | | |
| a | | |
A----/-----B | |
| | | |
| b | | b |
C----/-----E---------F---/----H
| |
| |
J----------K
Figure 8: Topology Used for Repair Computation for Link S-PHere the repair path to Ps is S-A-C-J-K-E-B-P. It might look like there's no path to D, since G-D is in SRLG "a" and F-H is in SRLG "b." That's only true if BOTH "a" and "b" really failed, which would be multiple independent failures. In practice, it's likely only one SRLG failed, either "a" or "b" but not both. S can't tell those possibilities apart, though, so it has to repair assuming both are unavailable. Each link repair is still considered independently. The repair to Ps delivers the packet to P, which forwards it to G. If SRLG "a" failed, the packet gets repaired around the path G-F-H-D. See Figure 9. If SRLG "b" failed instead, link G-D is still available, so the packet goes across G-D as normal.
ab Ps a Dg
S----/-----P---------G---/----D
| | | |
| a | | |
A----/-----B | |
| | | |
| b | | b |
C----------E---------F--------H
| |
| |
J----------K
Figure 9: Topology Used for Repair Computation for Link G-DIf both SRLG "a" and SRLG "b" failed, S repairs the packet as far as P, and P forwards it to G. G encapsulates the packet to D using the not-via address Dg and forwards it to F. F sees that its next hop to Dg (H) is unreachable because link F-H (part of SRLG "b") failed, so it drops the packet 😭. Packets addressed to a not-via address aren't repaired in basic not-via IPFRR.
Repairing multiple independent failures isn't provided by the basic not-via IPFRR method described so far in this memo 🙅
Assuming the worst case for each link can often give you longer repair paths than necessary. When only a single link fails instead of the full SRLG, this strategy might occasionally miss a repair even though a viable repair path exists in the network. Suboptimal repair paths are an inevitable consequence of this compromise. Failing to identify any repair is a serious deficiency, but it's a rare occurrence in a robustly designed network. This problem can be addressed by:
- Reporting that the link in question is irreparable, so that the network designer can take appropriate action.
- Modifying the design of the network to avoid this possibility.
- Using some form of SRLG diagnostic (for example, by running Bidirectional Forwarding Detection (BFD) [RFC5880] over alternate repair paths) to determine which SRLG member(s) have actually failed, and using this information to select an appropriate pre-computed repair path. However, aside from the complexity of performing the diagnostics, this requires multiple not-via addresses per interface, which has poor scaling properties.
- Using the mechanism described in Section 6.3.
6.2. Local Area Networks 🌈
LANs are a special type of SRLG and are solved using the SRLG mechanisms outlined above. With all SRLGs, there's a trade-off between how sophisticated the fault detection is and how big the SRLG is. Protecting against link failure of the LAN link(s) is pretty straightforward, but as with all fast-reroute mechanisms, things get more complex when you also want to protect against failure of the nodes attached to the LAN, not just the LAN itself 🧠
+--------------Q------C
|
|
|
A--------S-------(N)-------------P------B
|
|
|
+--------------R------D
Figure 10: Local Area NetworksConsider the LAN shown in Figure 10. For connectivity purposes, we consider that the LAN is represented by the pseudonode (N). To provide IPFRR protection, S needs to run a connectivity check to each of its protected LAN adjacencies P, Q, and R, using, for example, BFD [RFC5880] 💖
When S discovers that it has lost connectivity to P, it's unsure whether the failure is:
- its own interface to the LAN
- the LAN itself
- the LAN interface of P
- the node P
6.2.1. Simple LAN Repair 🧚
okay so the simplest way to repair a LAN is to treat the whole LAN and every router plugged into it as one single SRLG 🫶 that means the address P not via the LAN (Pl) would need P to be reached not via any router connected to the LAN. here's the vibe:
Ql Cl
+-------------Q--------C
| Qc
|
As Sl | Pl Bl
A--------S-------(N)------------P--------B
Sa | Pb
|
| Rl Dl
+-------------R--------D
Rd
Figure 11: Local Area Networks - LAN SRLGso if S detected that P had failed, it would send traffic reached via P and B to B not via the LAN or any router attached to the LAN (i.e., to Bl) 💅 and any destination that's only reachable through P would get addressed to P not via the LAN or any router attached to the LAN (except, of course, P) 🌸
ngl it's super simple, but it assumes a big chunk of the network next to the failure has also gone down 💀 which means you end up with suboptimal repair paths and sometimes no viable repair at all 😭
6.2.2. LAN Component Repair 🎀
this approach gets way more granular 🔍 with possible failures, but it doesn't use diagnostics to figure out which exact component broke. since S can't diagnose the failure, it has to repair traffic sent through P and B to an address Bpn (B not-via P,N, i.e., B not via P and not via N) 🦋 this is the conservative move, assuming both the entire LAN and P have failed. destinations that have P as a single point of failure MUST, as usual, be sent to P using an address that avoids the interface by which P is reached from S, i.e., to P not via N. the same process also applies to routers Q and R 💜
notice that each router connected to a LAN MUST, as usual, advertise one not-via address for each neighbor. on top of that, each router on the LAN MUST advertise an extra address not via the pseudonode (P) ✨
also notice that each neighbor of a router connected to a LAN needs to advertise two not-via addresses: the usual one not via the neighbor, and an additional one not via either the neighbor or the pseudonode 🙈 the full set of LAN address assignments is shown in Figure 12 below. every router on the LAN, and each of its neighbors, ends up advertising exactly one address more than they'd otherwise advertise if this degree of connectivity had been done with point-to-point links 🌈
Qs Qp Qc Cqn
+--------------Q---------C
| Qr Qn Cq
|
Asn Sa Sp Sq | Ps Pq Pb Bpn
A--------S-------(N)-------------P---------B
As Sr Sn | Pr Pn Bp
|
| Rs Rp Pd Drn
+--------------R---------D
Rq Rn Dr
Figure 12: Local Area Networks - Component Repair6.2.3. LAN Repair Using Diagnostics 🔍
a more specific LAN repair is possible if you use diagnostics 🧠 to explicitly pin down the failed network component, S correlates the connectivity reports from P and one or more of the other routers on the LAN, in this case Q and R 👑 if it lost connectivity to P alone, it could deduce that the LAN is still functioning and the fault is with either P or the interface connecting P to the LAN. it would then repair to B not-via P (and P not-via N for destinations where P is a single point of failure) in the usual way 💖 but if S lost connectivity to more than one router on the LAN, it could conclude that the fault lies only with the LAN, and it could repair to P, Q, and R not-via N, again in the usual way 🫶
6.3. Multiple Independent Failures 💀
IPFRR repair of multiple simultaneous failures that aren't members of a known SRLG is complicated 😩 because using multiple concurrent repairs may result in looping repair paths. as described in Section 5.2.1, the simplest way to stop those loops is to make sure packets addressed to a not-via address are not repaired but dropped instead 🚫 a network can experience multiple simultaneous failures. that might be simple statistical effects, but the more likely cause is unanticipated SRLGs 👀 when multiple failures that aren't part of an anticipated group get detected, repairs are abandoned and the network goes back to normal convergence. it's safe, but honestly kind of draconian 😤 since there are plenty of situations where multiple repairs don't cause loops at all
this section describes the properties of multiple unrelated failures and proposes some methods to tackle the problem 🌸
6.3.1. Looping Repairs 🔁
let's assume the repair mechanism is based solely on not-via repairs. LFA or downstream routes MAY be incorporated, and we'll get to them later 🧚
A------//------B------------D
/ \
/ \
F G
\ /
\ /
X------//------Y
Figure 13: The General Case of Multiple Failuresthis is the essential case, as shown in Figure 13. depending on the repair case you're looking at, there may be other paths in the picture too, besides the ones shown 🦋 for example, there could be paths between A and B, and/or between X and Y. those are left out to keep the graphic clean ✨
there are three cases to consider:
- consider the general case of a pair of protected links
A-BandX-Y, as in the network fragment in Figure 13. if the repair path forA-Bdoesn't traverseX-Yand the repair path forX-Ydoesn't traverseA-B, this case is completely safe and won't cause looping or packet loss 🥰
a more common variation of this case is shown in Figure 14, which has two failures in different parts of the network, where a packet from A to D traverses two concatenated repairs 🌈
A------//------B------------X------//------Y------D
| | | |
| | | |
M--------------+ N--------------+
Figure 14: Concatenated Repairs- in Figure 13, the repair for
A-BtraversesX-Y, but the repair forX-Ydoesn't traverseA-B. this happens when the not-via path fromAtoBtraverses linkX-Y, but the not-via path fromXtoYtakes some path that isn't shown in Figure 13 🤔 without the multi-failure mechanism described in this section, the repaired packet forA-Bwould be dropped when it reachedX-Y, since repairing already-repaired packets would be forbidden. BUT if that packet were allowed to be repaired, the path toDwould be complete and no harm done, although two levels of encapsulation would be needed 🫶 - the repair for
A-BtraversesX-YAND the repair forX-YtraversesA-B. in this case, unrestricted repair would result in looping packets and increasing levels of encapsulation 💀 major nope
so the challenge with applying IPFRR to a network that's going through multiple failures is figuring out which of these cases exist in the network and reacting accordingly 🧠
6.3.2. Outline Solution 💡
when A is computing the not-via repair path for A-B (i.e., the path for packets addressed to Ba, read as "B not via A"), it knows the list of nodes that path traverses 👀 this can be recorded with a simple addition to the SPF process, and the not-via addresses associated with each forward link can be determined. if the path were A, F, X, Y, G, B (Figure 13), the list of not-via addresses would be Fa, Xf, Yx, Gy, Bg. under standard not-via operation, A would populate its FIB so that all normal addresses normally reachable via A-B get encapsulated to Ba when A-B fails, but traffic addressed to any not-via address arriving at A gets dropped. the new procedure tweaks this so any traffic for a not-via address normally reachable over A-B is also encapsulated to Ba, UNLESS the not-via address is one of those previously identified as being on the path to Ba. for example, Yx, in which case the packet is dropped 🙅♀️
this lets cases 1 and 2 get repaired while preventing the loop that would come from case 3 🎉
the cool part is that this is done by pre-computing the required FIB entries, so there's no detailed packet inspection needed ✨ you could get the same result by checking for multiple levels of encapsulation and dropping any attempt to triple encapsulate. but that means more detailed inspection of the packet, and it causes difficulties once you're contemplating more than 2 "simultaneous" failures 😵💫
so far we've let benign repairs coexist, even though it sometimes means multiple encapsulation 🧁 in lots of cases there's no performance impact, since unless both failures are on the same node, the two encapsulations or two decapsulations happen at different nodes. there is, however, the issue of the maximum transmission unit (MTU) impact of multiple encapsulations 📏
in the following sub-section we look at the strategies that might be applied to case 3, the mutual repairs that would loop 🔄
6.3.3. Mutually Looping Repairs 🌀
in case 3, the simplest approach is to just not install repairs for repair paths that might loop. in this case, the potentially looping traffic is dropped, but it isn't repaired either 😭 if we assume a hold-down is applied before reconvergence in case the link failure was just a short glitch, and a loop-free convergence mechanism delays convergence further, then the traffic will be dropped for an extended stretch ⏳ in these circumstances, it's better to apply the "Abandoning All Hope" (AAH) mechanism ([RFC6976], Appendix A) and immediately invoke normal reconvergence 🙌
it's not enough to just speed up issuing a Link State Packet (LSP) reporting the failure, because the ordered FIB (oFIB) algorithm [RFC6976] may treat that as a permitted simultaneous failure. so it's necessary to explicitly trigger an oFIB AAH 🚨
6.3.3.1. Dropping Looping Packets 💖
Okay so for case 3 there's a vibe where you just let the repair happen and find out experimentally if the repairs clash once they actually occur 🧚. In that version we allow the repair in case 3 and fire off AAH once a packet drop count on the not-via address goes up. Or, option B, which is lowkey cleaner: we wait for the LSP describing the change to get issued normally, like when X announces that X-Y has failed. Then the repairing node A, which already precomputed that X-Y failures clash with its own repairs, can issue the AAH the second it gets that LSP. The downside is it doesn't beat the hold-down delay 😭, BUT it doesn't need any "data-driven" stuff, and it still does the important job of abandoning the oFIB, which is usually the longer of the delays (though with signaled oFIB it should be sub-second ✨).
Both of these experimental approaches are feasible, periodt 💅, but they tend to induce AAH even when the repairs would've been totally fine, and that goes directly against the repair predetermination philosophy that existing IPFRR solutions are built on. Not it 🙈.
6.3.3.2. Computing Non-looping Repairs of Repairs 🦋
Instead of just dropping the looping packets, or waiting to detect the loop after it's already happened, we can use secondary SRLGs. With a link-state routing protocol, it's possible to pre-compute the incompatibility of the repairs in advance and then compute an alternative SRLG repair path. Yes, this does considerably increase the computational complexity, but it may be possible to compute repair paths that avoid the need to just drop the offending packets. Main character energy 👑.
This approach means we have to identify the mutually incompatible failures and advertise them as "secondary SRLGs". When computing the repair paths for the affected not-via addresses, these links are simultaneously removed. Note that the assumed simultaneous failure and its resulting repair path only apply to the repair path computed for the conflicting not-via addresses, and they're NOT used for normal addresses. So yes, there will be a longer repair path when there's more than one failure, but if there's a single failure the repair path length will be "normal" 🌸.
Ideally we'd only invoke secondary SRLG computation when we're sure the repair paths are mutually incompatible. Let's look at node A in Figure 13 🍓. Node A first identifies that the repair path for A-B is via F-X-Y-G-B. It then explores this path, determining the repair path for each link in it. So, for example, it does a check at X by running an SPF rooted at X with the X-Y link removed, to figure out whether A-B is actually on X's repair path for packets addressed to Yx.
Some optimizations are possible here, because this calculation at first sight looks like it's order hk (where h is the average hop length of repair paths and k is the average number of neighbors of a router). It's giving a lot of math, I know 😭. When A is computing its set of repair paths, it does so for all its k neighbors. In each case it identifies a list of node pairs traversed by each repair. These lists may often have one or more node pairs in common, so the actual number of link failures that need investigating is the union of these sets. Then it's necessary to run an SPF rooted at the first node of each pair (first node, because the pairings are ordered to represent the direction of the path), with the link to the second node removed. This SPF, while not an incremental one, can be terminated as soon as the not-via address is reached. For example, when running the SPF rooted at X with the link X-Y removed, the SPF can stop once Yx is reached. Once the path has been found, we check whether it traverses any of A's links in the direction away from A. Also, because the node pair X-Y might sit in the list for more than one of A's links (because it lies on more than one repair path), we have to identify the correct list, and hence the correct link, that has a mutually looping repair path. That link of A then gets advertised by A as a secondary SRLG paired with the link X-Y. Also, X runs this algorithm too, and it'll figure out that X-Y is paired with A-B and advertise it, which could perhaps be used as a further check 🫶.
The ordering of the pairs in the lists is important, so X-Y and Y-X get dealt with separately. If and only if the repairs are mutually incompatible, we need to advertise the pair of links as a secondary SRLG, and then ALL nodes compute repair paths around both failures using an additional not-via address with the semantics not-via A-B AND not-via X-Y ✨.
Another possibility: since we're already going to the trouble of advertising these SRLG sets, we could also advertise the new repair path and only have the nodes on that path do the necessary computation. Also, once we've reached Q-space (Appendix A) with respect to the two failures, we don't need to keep computing, so we only need to notify the nodes on the path that are NOT in Q-space. Efficient queen behavior 👑.
One cause of mutually looping repair paths is the existence of nodes with only two links, or sections of the network that are only bi-connected. In these cases repair is clearly impossible 💀, because the failure of both links partitions the network. It would be advantageous to identify these cases and inhibit the fruitless advertisement of the secondary SRLG information. This could be achieved by having the node, once it detects the requirement for a secondary SRLG, first run the not-via computation with both links removed. If that doesn't result in a path, it's clear the network would be partitioned by such a failure, so no advertisement is required 🙅♀️.
6.3.4. Mixing LFAs and Not-Via 🌈
So far in this section we've assumed that all repairs use not-via tunnels. Realistically, though, we may want to use LFAs or downstream routes where they're available. This complicates the issue, because their use results in packets that are being repaired but NOT addressed to not-via addresses. If BOTH links are using downstream routes, there's no possibility of looping, since it's impossible to have a pair of nodes that are both downstream of each other [RFC5286] 🧠.
Loops can, however, occur when LFAs are used. An obvious example is the well-known node repair problem with LFAs [RFC5286] 😬. If one link is using a downstream route while the other is using a not-via tunnel, the potential mechanism described above would work, provided it were possible to determine the nodes on the path of the downstream route. Some methods of computing downstream routes don't provide this path information. But if the path information is available, the link using a downstream route will have a discard FIB entry for the not-via address of the other link. The consequence is that potentially looping packets get discarded when they try to cross this link 🗑️.
When the mutual repairs are both using not-via repairs, the loop gets broken when the packet arrives at the second failure. However, packets are unconditionally repaired by means of downstream routes, so when the mutual pair consists of a downstream route and a not-via repair, the looping packet only gets dropped when it gets back to the first failure. In other words, it executes a single turn of the loop before being dropped 🔁.
There's a further complication with downstream routes. Although the path may be computed to the far side of the failure, the packet may "peel off" to its destination before it reaches the far side of the failure. In that case it may traverse some other link that has failed and wasn't accounted for on the computed path. If the A-B repair (Figure 13) is a downstream route and the X-Y repair is a not-via repair, we can end up in a situation where the X-Y repair packets, encapsulated to Yx, follow a path that tries to traverse A-B. If the A-B repair path for "normal" addresses is a downstream route, it can't be assumed that the repair path for packets addressed to Yx can go to the same neighbor. That's because the validity of a downstream route MUST be ascertained in the topology represented by Yx, i.e., the one with the link X-Y removed. This isn't the same topology that was used for the normal downstream calculation, so using the normal downstream route for the encapsulated packets may result in an undetected loop 😱.
If it's computationally feasible to check the downstream route in this topology (i.e., for any not-via address Qp that traverses A-B, we must perform the downstream calculation for that not-via address in the topology with the link Q-P removed), then the downstream repair for Yx can safely be used. These packets can't revisit X-Y, since by definition they avoid that link. Alternatively, the packet could always be repaired in a not-via tunnel. Even though the normal repair for traffic traversing A-B would be a downstream route, we could insist that such traffic addressed to a not-via address must use a tunnel to Ba. Such a tunnel would only be installed for an address Qp if it were established that it does not traverse Q-P (using the rules described above) 🎀.
7. Optimizing Not-Via Computations Using LFAs ✨
If repairing node S has an LFA to the repair endpoint, then no router needs to perform the incremental SPF with the link S-P removed in order to compute the route to the not-via address Ps. Why? Because the correct routes were already computed as a result of the SPF on the base topology 🧚. Node S can signal this condition to all other routers by including a bit in its LSP or Link State Advertisement (LSA) associated with each link protected by an LFA. Routers computing not-via routes can then skip running the iSPF for links with this bit set 💜.
When running the iSPF for a particular link A-B, the calculating router first checks whether the link A-B is present in the existing SPT. If the link isn't present in the SPT, no further work is required. This check is a normal part of the iSPF computation 🌸.
If the link is present in the SPT, this optimization adds one more check: is the link marked as protected by an LFA in the direction it appears in the SPT? If so, the iSPF doesn't need to be performed. For example, if the link appears in the SPT in the direction A->B and A has indicated that the link A-B is protected by an LFA, then no further action is required for this link 💅.
If receipt of this information is delayed, the correct operation of the protocol isn't compromised, as long as the need to perform a not-via computation is re-evaluated whenever new information arrives 🦋.
This optimization isn't particularly beneficial to nodes close to the repair, because (as noted above) the computation for nodes on the LFA path is trivial. But for nodes upstream of the link S-P, where S-P is in the path to P, there's a significant reduction in the computation required 🚀.
8. Multicast ✨
okay so multicast traffic can be repaired pretty much the same way unicast can 💖 the multicast forwarder can use the not-via address that the multicast packet was addressed to as a hint for which receive interface to expect 🦋 that means it can run the required Reverse Path Forwarding (RPF) check correctly 💅
in some cases every destination, including the repair endpoint, is repairable by an LFA 🎀 when that happens, all unicast traffic can be repaired without any encapsulation at all ✨ multicast traffic still needs encapsulation though 🫶 but for the nodes on the LFA repair path, computing the not-via forwarding entry isn't needed, because by definition their normal path to the repair endpoint doesn't go via the failure 😭
a more complete description of multicast operation is left for further study 🌸
9. Fast Reroute in an MPLS LDP Network 🧚
not-via addresses are IP addresses, so LDP [RFC5036] will distribute labels for them in the usual way 💜 that means the not-via repair mechanism can be used to get fast reroute in an MPLS network too 🔥 you first push the label the repair endpoint uses to forward the packet, and then push the label for the not-via address needed to make the repair happen 👑 looking at Figure 1 again, if S has a packet for D that it has to reach via P and B, S first pushes B's label for D 🍓 then S pushes the label its next hop to Bp needs in order to reach Bp 🙈
the thing to know is that in an MPLS LDP network, S needs the repair endpoint's label for the destination 💀 when S is doing a link repair, it already has that 🌈 for a node repair, though, S either needs to set up a directed LDP session with each of its neighbor's neighbors, or it needs to use a method similar to the next-next-hop label distribution mechanism proposed in [NNHL] 🦋
10. Encapsulation 🎀
any IETF-specified IP-in-IP encapsulation can be used to carry a not-via repair ✨ IP in IP [RFC2003], Generic Routing Encapsulation (GRE) [RFC1701], and the Layer 2 Tunneling Protocol (L2TPv3) [RFC3931] all have the necessary and sufficient properties 💖 the requirement is that both the encapsulating router and the router the encapsulated packet is addressed to can process the chosen encapsulation type 🫶 when an MPLS LDP network is being protected, the encapsulation would normally be an extra MPLS label 🔥 and in an MPLS-enabled IP network, an MPLS label can be used instead of IP-in-IP encapsulation in the case above 🌸
care needs to be taken so the encapsulation used for a repair tunnel doesn't make the packet go over the MTU of the links that repair traverses 😭
11. Routing Extensions 📡
IPFRR needs routing protocol extensions 💅 every IPFRR router directly connected to a protected network component MUST advertise a not-via address for that component 👑 it has to be advertised in a way that lets the other routers in the network work out the association between the protected component (link, router, or SRLG) and the not-via address 🧚
routers that can support not-via routes need to advertise in the IGP that they will calculate not-via routes 🍓
routers also need to advertise the type of encapsulation they support (MPLS, GRE, L2TPv3, etc.) 🌈 but mixing IP encapsulation types inside one network is discouraged 🙈
if the optimization proposed in Section 7 is going to be used, then the use of the LFA in place of the not-via repair MUST also be signaled in the routing protocol 🔥✨
12. Incremental Deployment 🌸
incremental deployment works by leaving out routers that aren't calculating not-via routes (as shown by their capability information flooded with their link-state information) from the base topology used to compute repair paths 🦋 that way, repairs can be steered around islands of routers that aren't IPFRR capable 💖 routers protecting a network component need to be able to encapsulate and decapsulate packets 🎀 but routers that are only on the repair path just need to be able to calculate not-via paths and put the not-via addresses in their FIB, which means these routers don't need any changes to their forwarding mechanism 💅
13. Manageability Considerations 🍓
[RFC5714] outlines the general set of manageability considerations for IPFRR in general 🫶 we're expanding on that a little and adding details that are specific to not-via 💜 there are three classes of manageability considerations 👑
- Pre-failure configuration
- Pre-failure monitoring and operational support
- Failure action monitoring
13.1. Pre-failure Configuration ⚙️
pre-failure configuration for not-via includes:
- Enabling/disabling not-via IPFRR support.
- Enabling/disabling protection on a per-link or per-node basis.
- Expressing preferences regarding the links/nodes used for repair paths.
- Configuration of failure detection mechanisms.
- Setting a preference concerning the use of LFAs.
- Configuring a not-via address (per interface) or not-via address set (per node).
- Configuring any SRLG rules or preferences.
any standard configuration method can be used 🌈 which method gets picked is outside the scope of this document 🙈
13.2. Pre-failure Monitoring and Operational Support 🔍
pre-failure monitoring and operational support for not-via includes:
- Notification of links/nodes/destinations that cannot be protected.
- Notification of pre-computed repair paths.
- Notification of repair type to be used (LFA or not-via).
- Notification of not-via address assignment.
- Notification of path or address optimizations used.
- Testing repair paths. Note that not-via addresses look identical to "ordinary" addresses as far as tools such as traceroute and ping are concerned, so it's anticipated these will be used to verify the established repair path 💀
any standard IETF method can be used for the above 💅 the selection of the method is outside the scope of this document ✨
13.3. Failure Action Monitoring 🚨
failure action monitoring for not-via includes:
- Counts of failure detections, protection invocations, and packets forwarded over repair paths.
- Logging of the events, using a sufficiently accurate and precise timestamp.
- Validation that the packet loss was within specification, using a suitable loss verification tool.
- Capture of the in-flight repair packet flows, using a tool such as IP Flow Information Export (IPFIX) [RFC5101].
⚠️ bestie, monitoring the repair in action means capturing the signatures of a short, possibly sub-second network transient 😭 this technique isn't a well-developed IETF technology yet 🫠
14. Security Considerations 🔐
okay this section is serious, so buckle up 😭🔥
the repair endpoints present a vulnerability, because they might be used to disguise the delivery of a packet to a point in the network [RFC6169] 💀 the primary method of protection SHOULD be through the use of a private address space for the not-via addresses [RFC1918] [RFC4193] 🛡️ repair endpoint addresses MUST NOT be advertised outside the routing domain where not-via is deployed, and they MUST be filtered at the network entry points 🚫 also, a mechanism might be developed that allows the use of the mild security available through a key [RFC1701] [RFC3931] 🔑 with those mechanisms deployed, the repair endpoints wouldn't increase the security risk beyond what existing IP tunnel mechanisms already carry 🫶
an attacker may try to overload a router by sending an excessive traffic load to the decapsulation endpoint 😱 typically, routers take a 50% performance penalty when decapsulating a packet 📉 the attacker couldn't be certain the router would be impacted, and the extremely high volume of traffic needed would easily be detected as an anomaly 👀 if an attacker could influence the availability of a link, they could make the network invoke the not-via repair mechanism 😤 still, a network protected by not-via IPFRR is less vulnerable to that kind of attack than a network that did a full convergence in response to a link up/down event 💪
15. Acknowledgements 💌
the authors would like to acknowledge the contributions made by Alia Atlas and John Harper 🫶🌟
16. References 📚
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.16.2. Informative References
[ISPF] McQuillan, J., Richer, I., and E. Rosen, "ARPANET
Routing Algorithm Improvements", BBN Technical
Report 3803, 1978.
[NNHL] Shen, N., Chen, E., and A. Tian, "Discovering LDP Next-
Nexthop Labels", Work in Progress, May 2005.
[REMOTE-LFA] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and
N. So, "Remote LFA FRR", Work in Progress, May 2013.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 1701,
October 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G.,
and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two
Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931,
March 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC 5101, January 2008.
[RFC5286] Atlas, A. and A. Zinin, "Basic Specification for IP
Fast Reroute: Loop-Free Alternates", RFC 5286,
September 2008.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework",
RFC 5714, January 2010.
[RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding
Detection (BFD)", RFC 5880, June 2010.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169, April 2011.
[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.Appendix A. Q-Space ✨
Okay bestie, so Q-space is basically the squad of routers that can reach a specific router without any path (equal-cost path splits included 👀) going through the protected link (or node). 💅 The full tea is over in [REMOTE-LFA], so go peek there if you want all the details 🫖.
S---Eq
/ \
A Dq
\ /
B---CqFigure 15: The Q Space of E with Respect to the Link S-E 🦋
Let's say we're repairing link S-E (see Figure 15) 🔧. The set of routers that can reach node E by normal forwarding without crossing the link S-E is called the Q-space of E with respect to the link S-E. It's giving main character energy ✨.
To find it, you compute a reverse Shortest Path Tree (rSPT) rooted at E, and you excise the sub-tree that traverses the failed link, ECMP members included 🙃. The rSPT uses the cost towards the root instead of from it, so it yields the best paths towards the root from other nodes in the network 🌸. For Figure 15, the Q-space comprises nodes E, D, and C only. Periodt 💖🎀
Authors' Addresses 🫶
Stewart Bryant Cisco Systems 10 New Square, Bedfont Lakes Feltham, Middlesex TW18 8HA UK
EMail: stbryant@cisco.com
Stefano Previdi Cisco Systems Via Del Serafico, 200 00142 Rome Italy
EMail: sprevidi@cisco.com
Mike Shand Individual Contributor
EMail: imc.shand@googlemail.com 🌈
📦 where this page comes from
- ietf: rfc6981 2013-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms