In the last episode in our world wide tour of fast reroute mechanisms, we discussed Not-Via. While an interesting concept, Not-Via does require a number of extra IP addresses, as well as a new set of special routing advertisements, to work properly. So while Not-Via is conceptually simple, it hasn’t ever really been accepted as a solution for the various challenges fast reroute poses. So this time we’ll look at an another fast reroute system called Remote LFA.
Remote LFAs, as you might guess, are another form (or extension) of “normal” LFAs (you remember LFAs, right?). We’ll use the illustration embedded here to grasp the idea of a Remote LFA.
In this small diagram, we’re trying to make certain traffic originating someplace beyond A can reach E even if the A to E link fails. We can begin be examining A’s neighbors — in this case, only B — to determine if there is an LFA available towards E. If all the link costs here are 1, we’ll find there isn’t an LFA from A towards E; B is using A as its best path, so any traffic fowarded by A towards E via B will simply be forwarded back to A itself.
How can we solve this problem? We need to begin by recognizing that we’ll have to tunnel the traffic like we do in Not-Via — but how can we figure out where to tunnel the traffic to? From the diagram, we can see the correct point to tunnel the traffic to is C, but the router can’t precisely look at a diagram of a network and figure it out. What other alternative is left? What’s needed is a to calculate, at A, the closest node in the network to which traffic towards E can be forwarded without it looping back to A itself.
We could simply remove the A->E link from the database and run SPF, but this won’t help us find anything more than the LFA — and we already know there isn’t an LFA here. What if we removed the A->E link and calculated the LFA of A’s neighbor, though? Since A has precisely the same information as its neighbor, in this case only B, A can actually calculate the best path from B’s perspective. If A were to calculate the best path to E from B’s perspective after removing the A->E link from the database, then A could discover what alternate paths B has (remember that once the A->E link is removed, B can no longer calculate the best path through A).
Using this technique, A can quickly discover that B does, in fact, have an LFA — C. Moving to C, A performs the same calculation, and finds the cost from D->E is the same or lower than the cost A->E, meaning the traffic cannot loop back through A if it is forwarded directly to C. Knowing this, A can now build a tunnel to C, and place traffic with a next hop of E onto that tunnel if the A->E link fails. This is called the remote LFA because while C is not A’s LFA, it is A’s neighbor’s LFA — hence it is an LFA that is remote from A itself.
What sort of tunnel should A use? The type of tunnel doesn’t really matter — it could be a GRE tunnel, an MPLS tunnel, an IP-in-IP tunnel, or just about any other encapsulation. All that matters is that D accepts the packets tunneled from A, removes the tunnel header, and then forwards the packets as normal. In practice, MPLS is the type of tunnel implemented by vendors, and hence used by network operators, for remote LFA.
Next time we’ll discuss a more complex mechanism for finding alternate routes, a mechanism that is similar enough to Multiple Redundant Trees (MRT) to help you get a firm grasp on the idea.
Finally, for those keeping track, I’m now a Principal Engineer at Ericsson. I’ll be at the IETF next week, if anyone who will also be there wants to meet up for a meal, a hot chocolate, or just to chat.