Juniper Employee , Juniper Employee Juniper Employee
LFA analysis with WANDL - Part II (topology refinement)
Feb 9, 2015

LFA-attractive topologies


Essentially, #TheRoutingChurn network topology is probably one of the worst-case scenarios to enforce LFA with original metrics, because:


  • there are several single-homed routers to the backbone, without any natural backup paths
  • there are multiple Equal Cost Multi Path (ECMP) scenarios: U and square topologies!

[RFC6571] "Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks" covers very interesting topological discussions derived from the initial [RFC5286] mathematical route inequalities. In fact, [RFC6571] Sections 3.3 and 3.4 depict more convoluted Square and Extended U topological cases and outline the same mathematical rule applying to our scenario here (consider c here as distance between IS-IS L1L2 routers and a as distance between internal L1 systems):


 The commonly agreed-upon design rule (c < a) is especially beneficial
 for a deployment using per-link LFA: it provides a per-link LFA for
 the most important direction (A1C1).  Indeed, there are many more
 destinations reachable over A1C1 than over C1A1.  As the IGP
 convergence duration is proportional to the number of routes to
 update, there is a better benefit in leveraging LFA FRR for link A1C1
 than for link C1A1.

 Note as well that the consequence of this assumption is much more
 important for per-link LFA than for per-prefix LFA.

 Finally, note that c = a is the worst choice.  In this case, C1 has
 no per-prefix LFA for A1 (and vice versa); hence, there is no
 per-link LFA for C1A1 and A1C1.


Pierre Francois, one of the [RFC6571] editors, provided this "IP Fast Reroute Applicability" talk at EuroNOG 2011, where he reviews the basic LFA design and implemetation concepts and goes again through its influence in these topological options, based on the original LFA route inequalities:


  • Triangle and V-shaped topologies are most LFA applicable setups (especially in upstream cases).
  • Full mesh access scenarios can provide as well significant coverage, depending on the mesh degree at the aggregation layer.
  • Square setups can provide better coverage upon asymmetric link values (c<a, as per above), one link may not be fully covered though.
  • Rings are eligible for worst case LFA scenarios, due to inherent dependencies with direct neighbors for remote destination reachability.

In fact, Square or Extended U design cases are good for load balancing purposes upon symmetric and equal link metric values (c=a, as per above), as there are many chances to be able to build up an Equal Cost MultiPath (ECMP) next hop towards multiple destinations due to path parity:





But this load balancing benefit from equal metrics avoids an easy and straightforward calculation of a backup path due to fate sharing reasons, because the main [RFC5286] loop-free inequality criterion will not mathematically comply:


        Distance_opt(N, D) < Distance_opt(N, S) + Distance_opt(S, D)
                     Inequality 1: Loop-Free Criterion


If the topology is symmetric or fully squared, this criterion becomes an equality! In our square example above:


        Distance_opt(N, D) = Distance_opt(N, S) + Distance_opt(S, D) 

        Distance_opt(R16, R14) = Distance_opt(R16, R13) + Distance_opt(R13, R14)

        20 = 10 + 10


Changing topologies with WANDL


Trying to break the tie above, let us perform some topological changes with the WANDL IP/MPLSView tool. This is one of the major advantages from this toolkit for a network engineer: perform virtual changes in your network with accurate results and no risks! No need to go live to evaluate other scenarios or topological modifications.


Based on the above-mentioned premises, I am going to focus my changes on 2 different areas:


  • Including direct back-to-back links between IS-IS L1L2 systems in L1 Areas as well, so as to avoid Extended U cases
  • Changing inter-plane IGP metrics in the network core to introduce asymmetries (c<a, as per above), so as to avoid ECMP and fully squared setups

Back to our original topology representation, L1 Areas include now links between IS-IS L1L2 systems. These links are included both in the respective L1 Area and also remain in the L2 backbone:



Topological changes can be easily carried out with WANDL IP/MPLSView tool just by right-clicking the respective link in the Network Map and selecting the Modify Link option:




After carrying out link modifications with the previous objectives in mind, the Network Map results as follows (look at diverse inter-plane link costs):





Different metrics for inter-plane core links can be more easily discriminated by just displaying the IS-IS L2 backbone links with the available filter. As previously outlined, the underlying idea with these modifications is to undo many ECMP setups and create more c<a asymmetries in the core for clear master and backup path separation:





Paying attention now to L1 Areas, we can see how Extended U cases have turned into Squares with different asymettric link costs (Trapezoids) for LFA applicability purposes:




These scenarios are not Triangles or Full Mesh topologies, that would provide best LFA coverage (at the cost of additional physical or logical links), but result into more positive results. Running again the LFA simulation tool, now after all these metric changes





When comparing this summary with previous results, it is clear that we have obtained a quantitative improvement in terms of LFA coverage (~20-30% in all aspects). Please note that our usual #TheRoutingChurn topology includes several single-homed routers, which are included in this report and for which no backup path options are naturally possible.

Another clear indicator for a better LFA protection status is the calculated amount of explicit LFA tunnels that would need to be deployed: 34 LFA tunnels now instead of 59





Considering now all these explicit LFA tunnels for another simulation run, the LFA coverage even improves to a much better outcome. Again, 4 out of 25 routers in the topology (16%) are single-homed and also included here, so this can be accepted as close-to-best protection results:






Another refinement exercise could be carried out by inspecting now the explicit LFA tunnels calculated after these topological changes and evaluate them on a case by case.

The WANDL IP/MPLSView toolkit also provides an LFA Simulation tool, that allows to simulate concrete LFA decisions upon very specific events, such as node or link failure scenarios:






This is even more powerful to evaluate such concrete cases and reaction against diverse outages and failures, but surely subject of another post Smiley Happy



Loop Free Alternates (LFA) or IP Fast Reroute (FRR) is a very popular implementation that has been gaining much traction lately at many service providers and enterprise networks to provide simple and local fast restoration capabilities based on mathematical rules and without requiring protocol extensions or service interaction. Easy and simple to deploy and operate.


We have seen in these both posts that the WANDL IP/MPLSView toolkit provides powerful LFA simulation and evaluation features. I took here our usual #TheRoutingChurn Junosphere topology, but it provides multi-vendor and multi-layer coverage for IP and/or MPLS networks. This application does not only provide concrete LFA coverage reports, but also additional resources such as explicit LFA tunnel placement details for improved protection options and the ability to evaluate how topology changes influence global LFA enforcement. Apart from that, WANDL IP/MPLSView also includes an explicit simulation tool where specific network events can be simulated with regards to LFA.


Also, we have proved that calculations and changes tested with the WANDL IP/MPLSView toolkit are aligned with standard references and topologies, such as [RFC6571].


All this can be achieved in a virtual environment in a deterministic fashion, no need to go live!


After this initial evaluation exercise and with all these topological changes in mind, what else can we do to improve LFA coverage? How can I address, define and operate such explicit LFA tunnels with Junos OS? Stay tuned for upcoming #TheRoutingChurn posts where these topics will be covered! In the meantime, if you have any related questions, stories or learned lessons, please be our guest and add a comment below.