RFC 6571

Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks

📅 published June 2012, from ietf

RFC 6571 💖 Loop-Free Alternate (LFA) Applicability in Service Provider (SP) Networks

okay bestie, this is RFC 6571 📄✨ and it is giving informational energy. It's not a standard. It's a published analysis from a group of very smart people about where LFAs actually work in real ISP networks 🧠💅

  • Editors: C. Filsfils (Ed.) from Cisco Systems and P. Francois (Ed.) from Institute IMDEA Networks. (Ed. just means editor 🫶)
  • Other authors: M. Shand (no affiliation listed 🙈), B. Decraene from France Telecom, J. Uttaro from AT&T, and N. Leymann and M. Horneffer from Deutsche Telekom 🌈
  • Category: Informational 🧚
  • ISSN: 2070-1721
  • Date: June 2012 🍓
  • Obsoletes or updates: the title block doesn't list anything this RFC obsoletes or updates, so it's a solo act 💜

Abstract ✨

okay so the big idea is this: the doc analyzes how well the Loop-Free Alternate (LFA) method of IP fast reroute works in both the core and the access parts of Service Provider networks 🦋 It checks two kinds of failures, a broken link and a broken node, and gives guidance on which network topologies LFAs suit. The access side gets extra love 💖

Status of This Memo 📝

this document is not an Internet Standards Track specification. It's published just for information 🌸

it is a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full tea ☕

for the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6571 🔗

the copyright is held by the IETF Trust and the people listed as authors, copyright 2012, all rights reserved 💅

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the publication date. Please actually read those, because they spell out your rights and restrictions for this document 🙏

if you pull Code Components out of this document, they have to include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions. They come without warranty, as the Simplified BSD License describes 🎀

Table of Contents 📚

   1. Introduction ....................................................3
   2. Terminology .....................................................4
   3. Access Network ..................................................6
      3.1. Triangle ...................................................8
           3.1.1. E1C1 Failure ........................................8
           3.1.2. C1E1 Failure ........................................9
           3.1.3. uLoop ...............................................9
           3.1.4. Conclusion .........................................10
      3.2. Full Mesh .................................................10
           3.2.1. E1A1 Failure .......................................10
           3.2.2. A1E1 Failure .......................................11
           3.2.3. A1C1 Failure .......................................11
           3.2.4. C1A1 Failure .......................................12
           3.2.5. uLoop ..............................................12
           3.2.6. Conclusion .........................................12
      3.3. Square ....................................................13
           3.3.1. E1A1 Failure .......................................13
           3.3.2. A1E1 Failure .......................................14
           3.3.3. A1C1 Failure .......................................15
           3.3.4. C1A1 Failure .......................................15
           3.3.5. Conclusion .........................................17
           3.3.6. A Square Might Become a Full Mesh ..................17
           3.3.7. A Full Mesh Might Be More Economical Than a
                  Square .............................................17
      3.4. Extended U ................................................18
           3.4.1. E1A1 Failure .......................................19
           3.4.2. A1E1 Failure .......................................20
           3.4.3. A1C1 Failure .......................................20
           3.4.4. C1A1 Failure .......................................21
           3.4.5. Conclusion .........................................21

      3.5. Dual-Plane Core and Its Impact on the Access LFA
           Analysis ..................................................21
      3.6. Two-Tiered IGP Metric Allocation ..........................22
      3.7. uLoop Analysis ............................................22
      3.8. Summary ...................................................23
   4. Core Network ...................................................24
      4.1. Simulation Framework ......................................25
      4.2. Data Set ..................................................26
      4.3. Simulation Results ........................................26
   5. Core and Access Protection Schemes Are Independent .............27
   6. Simplicity and Other LFA Benefits ..............................27
   7. Capacity Planning with LFA in Mind .............................28
      7.1. Coverage Estimation - Default Topology ....................28
      7.2. Coverage Estimation in Relation to Traffic ................29
      7.3. Coverage Verification for a Given Set of Demands ..........29
      7.4. Modeling - What-If Scenarios - Coverage Impact ............29
      7.5. Modeling - What-If Scenarios - Load Impact ................30
      7.6. Discussion on Metric Recommendations ......................31
   8. Security Considerations ........................................32
   9. Conclusions ....................................................32
   10. Acknowledgments ...............................................32
   11. References ....................................................33
      11.1. Normative References .....................................33
      11.2. Informative References ...................................33

1. Introduction 🌸

okay so this doc analyzes LFA applicability for IP fast reroute (IPFRR) in both the core and access parts of Service Provider (SP) networks. The LFA method is defined in [RFC5714] and [RFC5286] 🫶 It looks at both link and node failures and gives guidance on which network topologies LFAs fit, with special attention to the access parts of the network 🔥

here's the roadmap, bestie 🗺️ Section 2 covers the terminology. Section 3 describes typical access network designs and analyzes them for LFA applicability. Section 4 explains a simulation framework for studying LFA applicability in SP core networks and presents results from various SP networks 📊 After that, the doc stresses that the protection schemes used in the core and at the access level are independent of each other ✨ Last but not least, it talks about the key benefits of LFA, which come from its simplicity, and then draws some conclusions 👑

2. Terminology ✨

okay so bestie, we're using IS-IS [RFC1195] [IS-IS] as our reference 🦋. We assume normal routing (aka when traffic is NOT being fast-rerouted around a failure) goes along the shortest path. The analysis works the same for OSPF [RFC2328] [RFC5340] too, so no one is left out 💖

A per-prefix LFA for a destination D at a node S is a pre-computed backup IGP next hop for that destination 🎀. This backup can be link-protecting or node-protecting. In this doc, we assume all links protected with LFAs are point-to-point 🔗

Link-protecting: a neighbor N is a link-protecting per-prefix LFA for S's route to D if equation eq1 is satisfied. This matches the definition of an LFA in [RFC5714] 💅

eq1: ND < NS + SD

where XY refers to the IGP distance from X to Y

Equation eq1

Node-protecting: a neighbor N is a node-protecting LFA for S's route to D with initial IGP next hop F if N is a link-protecting LFA for D AND equation eq2 is satisfied. This matches the definition of a Loop-Free Node-Protecting Alternate (also known as a node-protecting LFA) in [RFC5714] 👑

eq2: ND < NF + FD

Equation eq2

De facto node-protecting LFA: this is a link-protecting LFA that turns out to be node-protecting anyway 🙈 It happens in cases like these:

  • The LFA candidate that S picks actually satisfies Equation eq2, but S never checked that property. The show command the operator runs would NOT label this LFA as "node-protecting," but in practice (de facto) it totally is 💀
    • A cascading effect of multiple LFAs can also give de facto node protection. Equation eq2 is not satisfied, but when some other neighbors of the failing node F activate their LFAs together, they give (de facto) node protection. In other words, the data plane ends up in a state where packets forwarded by S eventually reach a neighbor of F that has a node-protecting LFA. Note that in this case, S cannot indicate the node-protecting behavior of the repair without running additional computations 🧠

Per-link LFA: a per-link LFA for the link SF is one pre-computed backup IGP next hop for ALL of the destinations reached through SF ✨ It's a neighbor of the repairing node that is a per-prefix LFA for all of the destinations the repairing node reaches through SF. Note that such a per-link LFA exists if S has a per-prefix LFA for destination F 🌈

                                D
                               / \
                           10 /   \ 10
                             /     \
                            G       H----------.
                            |       |          |
                          1 |     1 |          |
                            |       |          |
                            B       C          | 10
                            |       |\         |
                            |       | \        |
                            |       |  \ 6     |
                            |       |   \      |
                          7 |    10 |    E     F
                            |       |   /     /
                            |       |  / 6   / 5
                            |       | /     /
                            |       |/     /
                            A-------S-----/
                                7

                            Figure 1: Example 1

In Figure 1, when we think about protecting link SC, we can see that A, E, and F are per-prefix LFAs for destination D, because none of them use S to reach D 🦋

For destination D, A and F are node-protecting LFAs, since they do NOT reach D through node C. E is not node-protecting for S, because it reaches D through C 🙃

Here's the tea ☕ If S doesn't compute and select node-protecting LFAs, there's a chance S picks the non-node-protecting LFA E, even though A and F were node-protecting. If S enforces selecting node-protecting LFAs, then in the case of a single failure of link SC, S will first activate its LFA, deviate traffic addressed to D along S-A-B-G-D and/or S-F-H-D, and THEN converge to its post-convergence optimal path S-E-C-H-D 🏃‍♀️💨

A reaches C via S, so A is NOT a per-link LFA for link SC. E reaches C through link EC, so E IS a per-link LFA for link SC. This per-link LFA does NOT provide de facto node protection. Upon failure of node C, S would fast-reroute D-destined packets to its per-link LFA (= E). E would itself detect the failure of EC, so it would activate its own per-link LFA (= S). Traffic addressed to D would get trapped in a loop 😭 So there's no de facto node protection behavior here.

If there were a link between E and F that E would pick as its LFA for destination D, then E WOULD provide de facto node protection for S. Once E activates its LFA, S would deviate traffic addressed to D towards E. Then E deviates that traffic to F, which does NOT reach D through C 🎀

F is a per-link LFA for link SC, since F reaches C via H. This per-link LFA is de facto node-protecting for destination D, because F reaches D via F-H-D 💖

Micro-Loop (uLoop): the occurrence of a transient forwarding loop during a routing transition (as defined in [RFC5715]) 🌀

In Figure 1, the loss of link SE cannot create any uLoop, and here's why:

  1. The link is only used to reach destination E.
  2. S is the sole node changing its path to E when link SE fails.
  3. S's shortest path to E after the failure goes via C.
  4. C's best path to E (before and after link SC failure) is via CE.

On the other hand, when link AB fails, a micro-loop CAN form for traffic destined to B 😬 If A updates its Forwarding Information Base (FIB) before S does, A will reroute B-destined traffic towards S, while S is still forwarding that same traffic to A. Oops 🙈

3. Access Network 🌸

The access part of the network usually makes up the majority of the nodes and links 🏘️ It's organized into several tens or more regions, all interconnected by the core network. Very often, the core acts as an IS-IS level-2 domain (OSPF area 0), while each access region is confined to an IS-IS level-1 domain (OSPF non-0 area). Also very often, the network topology within each access region is derived from a single template shared across the whole access network 📐 Within an access region itself, the network is made of several aggregation regions, each following the same interconnection topologies.

For these reasons, in the next sections, we base the analysis of LFA applicability on a single access region, with these assumptions:

  • Two routers (C1 and C2) provide connectivity between the access region and the rest of the network. If a link connects these two routers in the region area, then it has a symmetric IGP metric c.
  • We analyze a single aggregation region within the access region. Two aggregation routers (A1 and A2) interconnect the aggregation region to the two routers C1 and C2 for the analyzed access region. If a link connects A1 to A2, then it has a symmetric IGP metric a. If a link connects a router A to a router C, then for the sake of generality we call d the metric for the directed link CA and u the metric for the directed link AC.
  • We analyze two edge routers, E1 and E2, in the access region. Each is dual-homed directly either to C1 and C2 (Section 3.1) or to A1 and A2 (Sections 3.2, 3.3, and 3.4). The directed link metric between Cx/Ax and Ey is d and u in the opposite direction.
  • We assume a multi-level IGP domain. The analyzed access region forms a level-1 (L1) domain. The core is the level-2 (L2) domain. We assume that the link between C1 and C2, if it exists, is configured as L1L2. We assume that the loopbacks of the C routers are part of the L2 topology. L1 routers learn about them as propagated routes (L2=>L1 with the Down bit set). We remind the reader that if an L1L2 router learns about X/x as an L1 path P1, an L2 path P2, and an L1L2 path P12, then it will prefer path P1. If path P1 is lost, then it will prefer path P2.
  • We assume that all of the C, A, and E routers may be connected to customers, so we analyze LFA coverage for the loopbacks of each type of node 💁‍♀️
  • We assume that no useful traffic is directed to router-to-router subnets, so we do NOT analyze LFA applicability for such subnets.
  • A prefix P models an important IGP destination that is not present in the local access region. The IGP metric from C1 to P is x, and the metric from C2 to P is x + e.
  • We analyze LFA coverage against all link and node failures within the access region.
  • WxYz refers to the link from Wx to Yz.
  • We assume that c < d + u and a < d + u (a commonly agreed-upon design rule).
  • In the square access design (Section 3.3), we assume that c < a (a commonly agreed-upon design rule).
  • We analyze the most frequent topologies found in an access region.
  • We first analyze per-prefix LFA applicability and then per-link.
  • The topologies are symmetric with respect to a vertical axis, so we only detail the logic for the link and node failures of the left half of the topology 🪞

3.1. Triangle 🔺

We describe the LFA applicability for the failures of C1E1, E1, and C1 (Figure 2) 💫

                                     P
                                    / \
                                  x/   \x+e
                                  /     \
                                 C1--c--C2
                                  |\   /|
                                  | \ / |
                               d/u|  \  |d/u
                                  | / \ |
                                  |/   \|
                                 E1     E2

                            Figure 2: Triangle

3.1.1. E1C1 Failure

3.1.1.1. Per-Prefix LFA

Three destinations are impacted by this link failure: C1, E2, and P 🎯

The LFA for destination C1 is C2, because eq1: c < d + u. Node protection for route C1 is not applicable. (If C1 goes down, traffic destined to C1 is lost anyway 🥲)

The LFA to E2 is via C2, because eq1: d < d + u + d. It is node-protecting, because eq2: d < c + d.

The LFA to P is via C2, because c < d + u. It is node-protecting if eq2: x + e < x + c, i.e., if e < c. This relationship between e and c is a big deal in the analysis, and it's discussed in detail in Sections 3.5 and 3.6 🧐

Conclusion: All important intra-PoP (Point of Presence) routes with primary interface E1C1 benefit from LFA link and node protection ✨ All important inter-PoP routes with primary interface E1C1 benefit from LFA link protection, and ALSO from node protection if e < c 👑

We have a per-prefix LFA to C1, so we have a per-link LFA for link E1C1 💕 All impacted destinations are protected against link failure. In the case of C1 node failure, the traffic to C1 is lost (by definition), the traffic to E2 is de facto protected against node failure, and the traffic to P is de facto protected when e < c.

3.1.2. C1E1 Failure

3.1.2.1. Per-Prefix LFA ✨

okay so C1 only has one primary route via C1E1, and that's the route to E1 (because c < d + u) 💅

C1's LFA to E1 is via C2, because eq1: d < c + d 🦋

node protection for E1's failure is not applicable, bc the only traffic that gets hit is sinked at E1, so it's lost anyway 🥀

Conclusion: all important routes with primary interface C1E1 benefit from LFA link protection. node protection is not applicable 🌸

we have a per-prefix LFA to E1, so we also have a per-link LFA for link C1E1. de facto node protection is not applicable 💖

3.1.3. uLoop 🌀

the IGP convergence cannot create any uLoop. see Section 3.7 🔗

3.1.4. Conclusion 👑

all important intra-PoP routes benefit from LFA link and node protection, or de facto node protection. all important inter-PoP routes benefit from LFA link protection. de facto node protection is ensured if e < c. (this is especially the case for dual-plane core or two-tiered IGP metric design, see Sections 3.5 and 3.6 🧚)

the IGP convergence does not cause any uLoop ✨

per-link LFAs and per-prefix LFAs give the same protection benefits 💜

3.2. Full Mesh 🕸️

we're looking at LFA applicability for the failures of C1A1, A1E1, E1, A1, and C1 (Figure 3) 👀

                                 P
                                / \
                              x/   \x+e
                              /     \
                             C1--c--C2
                              |\   /|
                              | \ / |
                          d/u |  \  | d/u
                              | / \ |
                              |/   \|
                             A1--a--A2
                              |\   /|
                              | \ / |
                           d/u|  \  |d/u
                              | / \ |
                              |/   \|
                             E1     E2

Figure 3: Full Mesh

3.2.1. E1A1 Failure 💥

3.2.1.1. Per-Prefix LFA

four destinations get impacted by this link failure: A1, C1, E2, and P 😭

the LFA for A1 is A2: eq1: a < d + u. node protection for route A1 is not applicable. (if A1 goes down, traffic to A1 is lost anyway 🙈) the LFA for C1 is A2: eq1: u < d + u + u. node protection for route C1 is guaranteed: eq2: u < a + u 🫶

the LFA to E2 is via A2: eq1: d < d + u + d. node protection is guaranteed: eq2: d < a + d 🔥

the LFA to P is via A2: eq1: u + x < d + u + u + x. node protection is guaranteed: eq2: u + x < a + u + x 🌈

Conclusion: all important intra-PoP and inter-PoP routes with primary interface E1A1 benefit from LFA link and node protection ✨

we have a per-prefix LFA to A1, so we have a per-link LFA for link E1A1. all impacted destinations are protected against link failure. de facto node protection is provided for all destinations (except A1, which is not applicable) 💅

3.2.2. A1E1 Failure 🌙

3.2.2.1. Per-Prefix LFA

A1 only has one primary route via A1E1, and that's the route to E1 (because a < d + u) 💫

A1's LFA to E1 is via A2: eq1: d < a + d 🦋

node protection upon E1's failure is not applicable, bc the only traffic that gets hit is sinked at E1, so it's lost anyway 🥀

Conclusion: all important routes with primary interface A1E1 benefit from LFA link protection. node protection is not applicable 🌸

we have a per-prefix LFA to E1, so we also have a per-link LFA for link C1E1. de facto node protection is not applicable 💖

3.2.3. A1C1 Failure 🌊

3.2.3.1. Per-Prefix LFA

two destinations get impacted by this link failure: C1 and P 🫠

the LFA for C1 is C2, because eq1: c < d + u. node protection for route C1 is not applicable. (if C1 goes down, traffic to C1 is lost anyway 😩)

the LFA for P is via C2, because c < d + u. it's de facto protected against node failure if eq2: x + e < x + c 🫧

Conclusion: all important intra-PoP routes with primary interface A1C1 benefit from LFA link protection. (node protection is not applicable.) all important inter-PoP routes with primary interface E1C1 benefit from LFA link protection (and from de facto node protection if e < c) 🎀

we have a per-prefix LFA to C1, so we have a per-link LFA for link A1C1. all impacted destinations are protected against link failure. if C1 node fails, the traffic to C1 is lost (by definition), and the traffic to P is de facto node protected if e < c 🌷

3.2.4. C1A1 Failure 🌪️

3.2.4.1. Per-Prefix LFA

C1 has three routes via C1A1: A1, E1, and E2. E2 behaves like E1, so it's not analyzed further 🙃

C1's LFA to A1 is via C2, because eq1: d < c + d. node protection upon A1's failure is not applicable, as the traffic to A1 is lost anyway 🫡

C1's LFA to E1 is via A2: eq1: d < u + d + d. node protection upon A1's failure is guaranteed, because eq2: d < a + d 🙌

Conclusion: all important routes with primary interface C1A1 benefit from LFA link protection. node protection is guaranteed where applicable 💜

we have a per-prefix LFA to A1, so we have a per-link LFA for link C1E1. de facto node protection is available ✨

3.2.5. uLoop 🔁

the IGP convergence cannot create any uLoop. see Section 3.7 🔗

3.2.6. Conclusion 👑

all important intra-PoP routes benefit from LFA link and node protection 💖

all important inter-PoP routes benefit from LFA link protection. they benefit from node protection upon failure of A nodes. they benefit from node protection upon failure of C nodes if e < c. (this is especially the case for dual-plane core or two-tiered IGP metric design, see Sections 3.5 and 3.6 🧚)

the IGP convergence does not cause any uLoop 🌈

per-link LFAs and per-prefix LFAs give the same protection benefits 💅

3.3. Square 🟥

we're looking at LFA applicability for the failures of C1A1, A1E1, E1, A1, and C1 (Figure 4) 👀

                                 P
                                / \
                              x/   \x+e
                              /     \
                             C1--c--C2
                              |\    | \
                              | \   |  +-------+
                          d/u |  \  |           \
                              |   +-|-----+      \
                              |     |      \      \
                             A1--a--A2     A3--a--A4
                              |\   /|       |    /
                              | \ / |       |   /
                           d/u|  \  |d/u    |  /
                              | / \ |       | /
                              |/   \|       |/
                             E1     E2      E3

Figure 4: Square

3.3.1. E1A1 Failure 💥

3.3.1.1. Per-Prefix LFA

E1 has six routes via E1A1: A1, C1, P, E2, A3, and E3 🌀

E1's LFA route to A1 is via A2, because eq1: a < d + u. node protection for traffic to A1 upon A1 node failure is not applicable 🙈

E1's LFA route to A3 is via A2, because eq1: u + c + d < d + u + u + d. this LFA is guaranteed to be node-protecting, because eq2: u + c + d < a + u + d 🫶

E1's LFA route to C1 is via A2, because eq1: u + c < d + u + u. this LFA is guaranteed to be node-protecting, because eq2: u + c < a + u 🔥

E1's primary route to E2 is via ECMP(E1A1, E1A2) (Equal-Cost Multi-Path). the LFA for the first ECMP path (via A1) is the second ECMP path (via A2). this LFA is guaranteed to be node-protecting, because eq2: d < a + d 🌸

E1's primary route to E3 is via ECMP(E1A1, E1A2). the LFA for the first ECMP path (via A1) is the second ECMP path (via A2). this LFA is guaranteed to be node-protecting, because eq2: u + d + d < a + u + d + d 🦋

if e = 0: E1's primary route to P is via ECMP(E1A1, E1A2). the LFA for the first ECMP path (via A1) is the second ECMP path (via A2). this LFA is guaranteed to be node-protecting, because eq2: u + x + 0 < a + u + x 🌷

if e <> 0: E1's primary route to P is via E1A1. its LFA is via A2, because eq1: u + c + x < d + u + u + x. this LFA is guaranteed to be node-protecting, because eq2: u + c + x < a + u + x 🧚

Conclusion: all important intra-PoP and inter-PoP routes with primary interface E1A1 benefit from LFA link protection and node protection 👑

we have a per-prefix LFA for A1, so we have a per-link LFA for link E1A1. all important intra-PoP and inter-PoP routes with primary interface E1A1 benefit from LFA per-link protection and de facto node protection 💖

3.3.2. A1E1 Failure 🌙

3.3.2.1. Per-Prefix LFA

A1 only has one primary route via A1E1, and that's the route to E1 💫

A1's LFA for route E1 is the path via A2, because eq1: d < a + d. node protection is not applicable 🥀

Conclusion: all important routes with primary interface A1E1 benefit from LFA link protection. node protection is not applicable 🌸

all important routes with primary interface A1E1 benefit from LFA link protection. de facto node protection is not applicable 💅

3.3.3. A1C1 Failure 🌊

3.3.3.1. Per-Prefix LFA

four destinations get impacted when A1C1 fails: C1, A3, E3, and P 😵‍💫

A1's LFA to C1 is via A2, because eq1: u + c < a + u. node protection is not applicable for traffic to C1 when C1 fails 🫠

A1's LFA to A3 is via A2, because eq1: u + c + d < a + u + d. it's de facto node-protecting, as a < u + c + d (as we assumed a < u + d). indeed, for destination A3, A2 forwards traffic to C2, and C2 has a node-protecting LFA (A4) for the failure of link C2C1, as a < u + c + d. so the cascading application of LFAs by A1 and C2 during the failure of C1 provides de facto node protection 🔁

A1's LFA to E3 is via A2, because eq1: u + d + d < a + u + d + d. it's node-protecting, because eq2: u + d + d < u + c + d + d 🫧

A1's primary route to P is via C1 (even if e = 0, u + x < u + c + x). the LFA is via A2, because eq1: u + c + x < a + u + x (case where c <= e) and eq1: u + x + e < a + u + x (case where c >= e). this LFA is node-protecting (from the viewpoint of A1 computing eq2) if eq2: u + x + e < u + c + x. this inequality is true if e < c 🎀

Conclusion: all important intra-PoP routes with primary interface A1C1 benefit from LFA link protection and node protection. note that A3 benefits from de facto node protection. all important inter-PoP routes with primary interface A1C1 benefit from LFA link protection. they also benefit from node protection if e < c 🌈

all important intra-PoP routes with primary interface A1C1 benefit from LFA link protection and de facto node protection. all important inter-PoP routes with primary interface A1C1 benefit from LFA link protection. they also benefit from de facto node protection if e < c 💜

3.3.4. C1A1 Failure 🌪️

3.3.4.1. Per-Prefix LFA

three destinations get impacted by C1A1 link failure: A1, E1, and E2. E2's analysis is the same as E1, so it's omitted 🙃

C1 has no LFA for A1. indeed, its neighbors (C2 and A3) have a shortest path to A1 via C1. this is due to the assumption (c < a) 😭

C1's LFA for E1 is via C2, because eq1: d + d < c + d + d. it provides node protection, because eq2: d + d < d + a + d 🙌

Conclusion: all important intra-PoP routes with primary interface A1C1, except A1, benefit from LFA link protection and node protection 👑

C1 does not have a per-prefix LFA for destination A1, so there is no per-link LFA for link C1A1 🥺

3.3.4.3. Assumptions on the Values of c and a 💅

Okay bestie, the commonly agreed-upon design rule (c < a) is especially 🔥 for a deployment using per-link LFA, because it gives you a per-link LFA for the most important direction, A1C1. There are way more destinations reachable over A1C1 than over C1A1, and IGP convergence time scales with the number of routes to update. So protecting link A1C1 with LFA FRR pays off more than protecting C1A1. 🎀

And this matters a LOT more for per-link LFA than for per-prefix LFA. Keep that in mind 👀

For per-prefix LFAs, if link C1A1 fails, we still have a per-prefix LFA for E1, E2, and any node subtended below A1 and A2. Most of the traffic crossing C1A1 is headed to those E nodes anyway, so not having a per-prefix LFA for the destination A1 is kinda insignificant. This is a great example of how per-prefix LFAs have better coverage than per-link LFAs. ✨

Now let's see what happens if we don't have c < a. 🙈

It definitely hurts per-link LFAs. With c > a, C1A1 gets a per-link LFA, but A1C1 has no per-link LFA. More destinations are impacted by an A1C1 failure than by a C1A1 failure, so the protection ends up going to the wrong direction. Oops 💀

For per-prefix LFAs, whether an LFA exists depends on the topology, so you have to check each per-prefix LFA individually. Some backbone topologies give super solid protection coverage, while others might give really poor coverage. 🌈

More specifically, when A1C1 fails, the coverage for a remote destination P depends on whether e < a. If that's true, A2 is de facto node-protecting per-prefix LFA for P. 🦋

Honestly, this kind of study probably needs a planning tool, because every remote destination P can have a different e value. The exception is all the edge devices of other aggregation pairs within the same region, since for those e = 0 by definition (for example, E3). 🧚

Finally, c = a is the worst choice of all. In that case, C1 has no per-prefix LFA for A1 (and vice versa), so there's no per-link LFA for C1A1 or A1C1 either. Big nope 🙅‍♀️

3.3.5. Conclusion 👑

All important intra-PoP routes get LFA link and node protection, with one exception: C1 has no per-prefix LFA to A1. 💖

All important inter-PoP routes get LFA link protection. They also get node protection if e < c. 🫶

Per-link LFA gives the same protection coverage as per-prefix LFA, with two exceptions. First, C1A1 has no per-link LFA at all. Second, when per-prefix LFA gives node protection (eq2 is satisfied), per-link LFA gives effective de facto node protection. 🔥

3.3.6. A Square Might Become a Full Mesh 🕸️

If the vertical links of the square are made of parallel links (at the IP topology or below), then you should consider splitting those "vertical links" into "vertical and crossed links." That turns the topology into a "full mesh." You should also make sure the two resulting sets of links (vertical and crossed) don't share any Shared Risk Link Group (SRLG). 🎀

A typical scenario where this is prevented: the A1C1 bandwidth lives inside a building while A1C2 runs between buildings. So from a router-port viewpoint it's cost-neutral, but from a cost-of-bandwidth viewpoint it is NOT, bestie 💸

3.3.7. A Full Mesh Might Be More Economical Than a Square 🦋

In a full mesh, the vertical and crossed links are the main characters 🌟 because they carry most of the primary and backup paths. You can size the horizontal links based on the traffic headed to a single C node or a single A node, and to a single E node. Super efficient ✨

3.4. Extended U 🧚‍♀️

For the Extended U topology, here's the terminology we're using:

  • C1L1: the node "C1" as seen in topology L1.
  • C1L2: the node "C1" as seen in topology L2.
  • C1LO: the loopback of C1. This loopback is in L2.
  • C2LO: the loopback of C2. This loopback is in L2.

Just a reminder that C1 and C2 are L1L2 routers, and their loopbacks are in L2 only. 💜

                                  P
                                 / \
                               x/   \x+e
                               /     \
                              C1<...>C2
                               |\    | \
                               | \   |  +-------+
                           d/u |  \  |           \
                               |   +-|-----+      \
                               |     |      \      \
                              A1--a--A2     A3--a--A4
                               |\   /|       |    /
                               | \ / |       |   /
                            d/u|  \  |d/u    |  /
                               | / \ |       | /
                               |/   \|       |/
                              E1     E2      E3

                           Figure 5: Extended U

There's no L1 link between C1 and C2. There might be an L2 link between them, but that doesn't matter, because it's not visible from the L1 topology, which is what we're analyzing. 🤷‍♀️

It's guaranteed that there's a path from C1LO to C2LO within the L2 topology (unless the L2 topology partitions, which is very unlikely and so isn't analyzed here). We call its path cost "c." Once again, we assume c < a. 🔥

We use this property to create a tunnel T between C1LO and C2LO. Since the source and destination addresses are the loopbacks of C1 and C2, and those loopbacks are in L2 only, it's guaranteed that the tunnel does NOT transit the L1 domain. Safe 🙌

IS-IS does not run over the tunnel, so the tunnel isn't used for any primary paths within the L1 or L2 topology. 🎀

Within level-1, we configure C1 (C2) with a level-1 LFA extended neighbor "C2 via tunnel T" ("C1 via tunnel T").

A router that supports this extension learns that it has one additional potential neighbor in topology level-1 when it checks for LFAs. ✨

The L1 topology learns about C1LO as an L2=>L1 route with the Down bit set, propagated by C1L1 and C2L1. The metric advertised by C2L1 is bigger than the metric advertised by C1L1 by "c." 💅

The L1 topology learns about P as an L2=>L1 route with the Down bit set, propagated by C1L1 and C2L1. The metric advertised by C2L1 is bigger than the metric advertised by C1L1 by "e." This implies that e <= c. 🧠

3.4.1. E1A1 Failure 💥

3.4.1.1. Per-Prefix LFA

Five destinations are impacted by an E1A1 link failure: A1, C1LO, E2, E3, and P. 😭

The LFA for A1 is via A2, because eq1: a < d + u. Node protection for traffic to A1 upon A1 node failure doesn't apply here. 🙈

The LFA for E2 is via A2, because eq1: d < d + u + d. Node protection is guaranteed, because eq2: d < a + d. 🫶

The LFA for E3 is via A2, because eq1: u + d + d < d + u + d + d. Node protection is guaranteed, because eq2: u + d + d < a + u + d + d. ✨

The LFA for C1LO is via A2, because eq1: u + c < d + u + u. Node protection is guaranteed, because eq2: u + c < a + u. 👑

If e = 0: E1's primary route to P is via ECMP(E1A1, E1A2). The LFA for the first ECMP path (via A1) is the second ECMP path (via A2). Node protection is possible, because eq2: u + x < a + u + x. 🦋

If e <> 0: E1's primary route to P is via E1A1. Its LFA is via A2, because eq1: a + c + x < d + u + u + x. Node protection is guaranteed, because eq2: u + x + e < a + u + x <=> e < a. This is true, because e <= c and c < a. 🌸

Conclusion: same as the square topology. ✅

Same as the square topology. 💖

3.4.2. A1E1 Failure

3.4.2.1. Per-Prefix LFA

Same as the square topology. 💅

Same as the square topology. 🎀

3.4.3. A1C1 Failure 🫣

3.4.3.1. Per-Prefix LFA

Three destinations are impacted when A1C1 fails: C1, E3, and P. 😭

A1's LFA to C1LO is via A2, because eq1: u + c < a + u. Node protection isn't applicable for traffic to C1 when C1 fails. 🙈

A1's LFA to E3 is via A2, because eq1: u + d + d < d + u + u + d + d. Node protection is guaranteed, because eq2: u + d + d < a + u + d + d. 🔥

A1's primary route to P is via C1 (even if e = 0, u + x < a + u + x). The LFA is via A2, because eq1: u + x + e < a + u + x <=> e < a (which is true; see above). Node protection is guaranteed, because eq2: u + x + e < a + u + x. 🧚

Conclusion: same as the square topology. ✅

Same as the square topology. 💜

3.4.4. C1A1 Failure 🌧️

3.4.4.1. Per-Prefix LFA

Three destinations are impacted by a C1A1 link failure: A1, E1, and E2. E2's analysis is the same as E1's, so we're skipping it. 🙃

C1L1 has an LFA for A1 via the extended neighbor C2L1, reachable via tunnel T. Indeed, eq1 is true: d + a < d + a + u + d. From C1L1's viewpoint, C2L1's path to C1L1 is C2L1-A2-A1-C1L1. Remember that IS-IS doesn't see the tunnel when computing primary paths! 🚨 Node protection isn't applicable for traffic to A1 when A1 fails.

C1L1's LFA for E1 is via extended neighbor C2L1 (over tunnel T), because eq1: d + d < d + a + u + d + d. Node protection is guaranteed, because eq2: d + d < d + a + d. 🫶

C1 has a per-prefix LFA for destination A1, so there's a per-link LFA for the link C1A1. Node resistance is applicable for traffic to E1 (and E2). 🎀

3.4.5. Conclusion 👑

The Extended U topology is just as good as the square topology. ✨

It doesn't require any crossed links between the A and C nodes within an aggregation region. It also doesn't need an L1 link between the C routers in an access region. Note that a link between the C routers might exist in the L2 topology. 💅

3.5. Dual-Plane Core and Its Impact on the Access LFA Analysis 🛤️

A dual-plane core is defined like this:

  • Each access region k is connected to the core by two C routers (C(1,k) and C(2,k)).
  • C(1,k) is part of plane-1 of the dual-plane core.
  • C(2,k) is part of plane-2 of the dual-plane core.
  • C(1,k) has a link to C(2, l) iff k = l.
  • {C(1,k) has a link to C(1, l)} iff {C(2,k) has a link to C(2, l)}.

In a dual-plane core design, e = 0, so the LFA node-protection coverage gets better in all of the analyzed topologies. 🌈

3.6. Two-Tiered IGP Metric Allocation 🍓

A two-tiered IGP metric allocation scheme is defined like this:

  • All of the link metrics used in the L2 domain are part of range R1.
  • All of the link metrics used in an L1 domain are part of range R2.
  • Range R1 << range R2, such that the difference e = C2P - C1P is smaller than any link metric within an access region.

Assuming this IGP metric allocation, the following properties are guaranteed: c < a, e < c, and e < a. 🌸✨

3.7. uLoop Analysis 🔍

Okay bestie, this section is about uLoops 🌀, which are transient forwarding loops that can pop up during the routing transition after a link fails. The vibe is: one destination might have a uLoop problem, and every other case is totally fine. Let's go! 💖

In the square design, when link C1A1 fails, traffic addressed to A1 can undergo a transient forwarding loop 😭. Here's the drama: C1 reroutes that traffic to C2, which initially reaches A1 through C1, as c < a. The loop actually happens when C1 updates its FIB for destination A1 before C2 does. Oops 🙈.

It can be shown that all of the other routing transitions following a link failure in the analyzed topologies do not have uLoop potential ✨. The reason is so satisfying: for every affected destination, the rerouting nodes send their traffic straight to adjacent nodes whose paths to those destinations don't change. Since nobody bounces traffic back into a loop, none of these transitions can undergo transient forwarding loops. Iconic 👑.

For example, in the square topology, the failure of directed link A1C1 doesn't lead to any uLoop 🦋. The destinations reached over that directed link are C1 and P. After convergence, A1's and E1's shortest paths to these destinations go via A2. And A2's path to C1 and P isn't using A1C1 before the failure, so no uLoop can occur. Main character energy from A2 💅.

3.8. Summary 🎀

Let's recap everything from the previous sections, because this is the cheat sheet you'll want to screenshot 📸. For link protection, "Full" means the LFAs cover each destination reached via any link of the topology. For node protection, "Yes" means node protection is achieved for that node 🌸.

  1. Intra-Area Destinations
    • Link Protection
      • Triangle: Full
      • Full Mesh: Full
      • Square: Full, except C1 has no LFA for dest A1
      • Extended U: Full
    • Node Protection
      • Triangle: Yes
      • Full Mesh: Yes
      • Square: Yes
      • Extended U: Yes
  2. Inter-Area Destinations
    • Link Protection
      • Triangle: Full
      • Full Mesh: Full
      • Square: Full
      • Extended U: Full
    • Node Protection
      • Triangle: Yes, if e < c
      • Full Mesh: Yes for A failure, if e < c for C failure
      • Square: Yes for A failure, if e < c for C failure
      • Extended U: Yes, if e <= c and c < a
  3. uLoops
    • Triangle: None
    • Full Mesh: None
    • Square: None, except traffic to A1 when C1A1 fails
    • Extended U: None, if a > e
  4. Per-Link LFA vs. Per-Prefix LFA
    • Triangle: Same
    • Full Mesh: Same
    • Square: Same, except C1A1 has no per-link LFA. In practice, this means that per-prefix LFAs will be used. (Hence, C1 has no LFA for dest = E1 and dest = A1.)
    • Extended U: Same

4. Core Network 🌍

Now we switch to the backbone 🛰️, and honestly? Optimizing a network design for the maximum LFA protection is way less straightforward here than in the access/aggregation network.

The main optimization objectives for backbone topology design are cost, latency, and bandwidth, and they're constrained by the availability of fiber 🧵. Optimizing for local IP restoration is more likely to be a non-primary objective. For example, the way the fiber is laid out, and how expensive it is to change it, leads to ring topologies in some backbone networks 💍.

Capacity planning is also already a lot in the backbone 😵‍💫. The process has to make sure the traffic matrix (demand) is supported by the underlying network (capacity) under all possible variations of that network, which means every what-if scenario related to one-SRLG failure. Classically, "supported" means no congestion is experienced and the demands are routed along the appropriate latency paths. If you chose the LFA method as a deterministic FRR solution for the backbone, capacity planning would need a third constraint added: each variation of the underlying network should lead to sufficient LFA coverage. (We detail this aspect in Section 7 🔗.)

On the other hand, the access network is built from many replications of a small number of well-known, well-engineered topologies 🧁. The LFA coverage is deterministic and doesn't change when you add a new edge device, a new aggregation sub-region, or a new access region. Predictable and stable, so cute 🥰.

In practice, we believe there are three profiles for the backbone applicability of the LFA method 🌈:

  • In the first profile, the designer plans all of the network resilience on IGP convergence. In such a case, the LFA method is a free bonus ✨. If an LFA is available, the loss of connectivity is likely reduced by a factor of 10 (50 msec vs. 500 msec). Otherwise, the loss of connectivity depends on IGP convergence, which is the initial target anyway. The LFA method should be very successful here, since it provides a significant improvement without any additional cost 💸.
  • In the second profile, the designer seeks a very high and deterministic FRR coverage, and they either don't want or can't engineer the topology 🙅‍♀️. The LFA method should not be considered in this case. MPLS Traffic Engineering (TE) FRR would perform much better in this environment, because explicit routing ensures that a backup path exists, whatever the underlying topology 🔒.
  • In the third profile, the designer seeks a very high and deterministic FRR coverage, and they do engineer the topology 🛠️. The LFA method is appealing in this scenario, since it can provide a very simple way to obtain protection 💜. Furthermore, in practice, the requirement for FRR coverage might be limited to a certain part of the network (e.g., a given sub-topology) and/or is likely limited to a subset of the demands within the traffic matrix. In such a case, if the relevant part of the network natively provides a high degree of LFA protection for demands of interest, it might actually be straightforward to improve the topology and achieve the level of protection required for the sub-topology and the demands that matter. Once again, the practical problem needs to be considered (which sub-topology, and which real demands need 50 msec), as it is often simpler than the theoretical generic one 🧠.
For the reasons explained previously, the backbone applicability should be analyzed on a case-by-case basis, and it is difficult to derive generic rules. Not one-size-fits-all, babe 🫶.

In order to help the reader assess the LFA applicability in their own case, we provide some simulation results based on 11 real backbone topologies in the next section 📊.

4.1. Simulation Framework 🧪

In order to analyze LFA applicability in the core, we usually receive the complete IS-IS/OSPF linkstate database taken on a core router 📥. We parse it to obtain the topology. During this process, we eliminate all nodes connected to the topology with a single link, and all prefixes except a single "node address" per router. We compute the availability of per-prefix LFAs to all of these node addresses, which we hereafter call "destinations". We treat each link in each direction ➡️⬅️.

For each (directed) link, we compute whether we have a per-prefix LFA to the next hop. If so, we have a per-link LFA for the link.

The per-link-LFA coverage for a topology T is the fraction of the number of links with a per-link LFA divided by the total number of links.

For each link, we compute the number of destinations whose primary path involves the analyzed link. For each such destination, we compute whether a per-prefix LFA exists.

The per-prefix LFA coverage for a topology T is the following fraction:

(the sum across all links of the number of destinations with a
primary path over the link and a per-prefix LFA)

divided by

(the sum across all links of the number of destinations with a
primary path over the link)

4.2. Data Set 🗺️

Our data set is based on 11 SP core topologies with different geographical scopes: worldwide, national, and regional 🌎. The number of nodes ranges from 600 to 16. The average link-to-node ratio is 2.3, with a minimum of 1.2 and a maximum of 6.

4.3. Simulation Results 📈

           +----------+--------------+----------------+
           | Topology | Per-Link LFA | Per-Prefix LFA |
           +----------+--------------+----------------+
           |    T1    |      45%     |       76%      |
           |    T2    |      49%     |       98%      |
           |    T3    |      88%     |       99%      |
           |    T4    |      68%     |       84%      |
           |    T5    |      75%     |       94%      |
           |    T6    |      87%     |       98%      |
           |    T7    |      16%     |       67%      |
           |    T8    |      87%     |       99%      |
           |    T9    |      67%     |       79%      |
           |    T10   |      98%     |       99%      |
           |    T11   |      59%     |       77%      |
           |  Average |      67%     |       89%      |
           |  Median  |      68%     |       94%      |
           +----------+--------------+----------------+

Table 1: Core LFA Coverages

In Table 1 we see a wild variation in LFA coverage across topologies 🎢: from 67% to 99% for the per-prefix LFA coverage, and from 16% to 98% for the per-link LFA coverage. Several topologies have been optimized for LFAs (T3, 6, 8, and 10), which shows why case-by-case analysis is needed when considering LFAs for core networks 🔍.

It should be noted that, contrary to the access/aggregation topologies, per-prefix LFA outperforms per-link LFA in the backbone 💅.

5. Core and Access Protection Schemes Are Independent ✨

Specifically, a design might use LFA FRR in the access and MPLS TE FRR in the core 🧩.

The LFA method provides great benefits for the access network, thanks to its excellent access coverage and its simplicity 🫧.

MPLS TE FRR's topology independence might prove beneficial in the core when the LFA FRR coverage is judged too small, and/or the designer feels unable to optimize the topology to improve the LFA coverage 🌸.

6. Simplicity and Other LFA Benefits 💖

okay so the big reason LFAs are sooo good is honestly the simplicity 🫶 it's giving "set it and forget it" energy.

LFA behaviour is automated, so fast restoration just becomes part of the IGP itself. There's no extra configuration burden in the IGP or any other protocol, which is iconic.

And because of that integration, using multiple areas in the IGP doesn't make fast restoration harder to get than in a single-area IGP design. ✨

There's no need for a network-wide upgrade either, because LFAs don't need any protocol change. You can roll them out router by router 🌸

With LFAs, the backup paths get pre-computed and installed in the data plane before anything fails 🔥 As long as the FIB update time is fast enough compared to the total number of (important) destinations, a <50-msec repair requirement becomes achievable. Also, with a prefix-independent implementation, the repair time is fixed. It depends on the failure detection time and on how long it takes to activate the LFA behaviour, and that doesn't scale with how many destinations need fast reroute. Literally so stable 💅

Link and node protection come together with no operational differences. (For comparison, MPLS TE FRR needs different kinds of backup tunnels for link and node protection, and that's way more operational complexity 😭)

Another simplicity win over MPLS TE FRR: LFAs don't need yet another virtual layer of topology. Keeping a virtual topology of explicit MPLS TE tunnels makes the network way more complicated. Those tunnels would have to be represented in a network management system so they can be monitored and managed. In big networks, that can seriously pump up the number of network entities the NMS polls and the operational staff has to watch 🙈 An LFA, on the other hand, only needs its operational status monitored once per router, and it needs to be considered in the network-planning process. If that planning is already done with offline simulations of failure cases, then the extra cost of supporting LFAs for a defined set of demands may be relatively low 🦋

The per-prefix mode of LFAs also makes capacity planning simpler and more efficient 🎀 Each destination's backup path is optimised individually, so the load that needs fast reroute can be spread across a set of shortest repair paths, instead of piling onto one single backup tunnel. That leads to a simpler, more efficient capacity-planning process that takes congestion during protection into account. Main character energy 👑

7. Capacity Planning with LFA in Mind 💅

okay this part is about the functionality you should expect from a capacity-planning tool that supports LFAs, plus the capacity-planning process around it 🧚 Here we go!

7.1. Coverage Estimation - Default Topology

For Per-Link LFA Coverage Estimation, the tool would colour each unidirectional link in, depending on whether or not per-link LFAs are available 🌈

For Per-Prefix LFA Coverage Estimation, the tool would colour each unidirectional link with a colour gradient, based on the percentage of destinations that have a per-prefix LFA 💜

Besides the visual GUI reporting, the tool should also provide detailed tables that list, per interface, the percentage of LFAs, the number of prefixes with LFAs, the number of prefixes without LFAs, and a list of those prefixes without LFAs. Detailed tables are the real MVP 📊

The tool should also list, and give percentages for, the traffic matrix demands with less than 100% source-to-destination LFA coverage. It should also report average coverage for every demand, using a threshold: number of links on which a demand has an LFA divided by the number of links traversed by that demand 🍓

The user should be able to change the colour scheme, so they can see whether these LFAs are guaranteed node-protecting, de facto node-protecting, or only link-protecting. Very customisable, very iconic ✨

All of this functionality gives the same level of information as we described in Sections 4.1 to 4.3. 🫶

7.2. Coverage Estimation in Relation to Traffic

Instead of reporting coverage as a ratio of destinations that have a backup, you might prefer a ratio of the traffic on a link that benefits from protection 💖

And honestly this is probably way more relevant 😭 because not all destinations are equal. It matters a LOT more to have an LFA for a destination that attracts loads of traffic than for an unpopular one. Priorities, bestie 💅

7.3. Coverage Verification for a Given Set of Demands

Depending on what the network needs, it might matter more to verify the complete LFA coverage of a given sub-topology, or of a given set of demands, than to calculate the relative coverage of the overall traffic 🔥 This is most likely true for the third engineering profile described in Section 4.

So in that case, the tool should be able to report the LFA coverage on a given set of demands separately, and highlight each part of the network that doesn't support 100% coverage for any of those demands 🎀

7.4. Modeling - What-If Scenarios - Coverage Impact

The tool should be able to compute coverage for all of the possible topologies that result from a set of expected failures (i.e., one-SRLG failure) 🦋

Filtering the key information out of the huge amount of generated data should be a key property of the tool. Nobody wants to scroll through a mountain of output 💀

For example, the user could set a threshold, like at least 80% per-prefix LFA coverage in all one-SRLG what-if scenarios. Then the tool would only report the cases where that condition isn't met, and hopefully give some help on how to fix it, via IGP metric optimisation 🧚

As an application example: a designer who can't ensure that c < a could use a tool like this to check the per-prefix LFA coverage for square aggregation topologies grafted onto the backbone of their network 🌸 The tool would analyse per-prefix LFA availability for each remote destination, and help optimise the backbone topology to boost LFA protection coverage for failures within those square aggregation topologies. Glow-up arc unlocked 🌈

7.5. Modeling - What-If Scenarios - Load Impact

The tool should be able to compute the link load for all routing states that result from a set of expected failures (i.e., one-SRLG failure) 💜

The routing states it should support are:

  1. the network-wide converged state before the failure,
  2. the state in which all of the LFAs protecting the failure are active, and
  3. the network-wide converged state after the failure.

Again, filtering the key info out of the huge amount of generated data should be a key property of the tool 🍓

For example, the user could set a threshold, like at most 100% link load in all one-SRLG what-if scenarios. Then the tool would only report the cases where that's violated, hopefully with some help on how to fix it, via IGP metric optimisation 🫶

The tool should be able to do this for aggregate load, and for each class of service too 👑

Note: In cases where the traffic matrix is unknown, an intermediate solution is to identify the destinations that would attract traffic (i.e., Provider Edge (PE) routers), and those that wouldn't (i.e., Provider (P) routers). One could do this by creating a traffic matrix with equal demands between the sources/destinations that would attract traffic (PE to PE). That will be more relevant than considering all demands between all prefixes (e.g., when there is no customer traffic from P to P). 🧚

7.6. Discussion on Metric Recommendations

Okay, so LFA FRR has loads of benefits (Section 6) 💖 but its applicability depends on the topology 😬

The purpose of this document is to show how to introduce a level of control over that topology parameter 🦋

On one hand, we wanted to show that by adopting a small set of IGP metric constraints, and repeating well-behaved patterns, the designer could deterministically guarantee maximum link and node protection for the vast majority of the network (the access/aggregation). Doing that gives an extremely simple resiliency solution 💅

On the other hand, we also wanted to show that it might not be so bad to not apply (all of) these constraints 🌈

Indeed, we explained in Section 3.3.4.3 that the per-prefix LFA coverage in a square where c >= a might still be very good, depending on the backbone topology 🎀

We showed in Section 4.3 that the median per-prefix LFA coverage for 11 SP backbone topologies still provides 94% coverage. (Most of these topologies were built without any idea of LFA! 😭)

Furthermore, we showed that any topology may be analysed with an LFA-aware capacity-planning tool. That would readily assess per-prefix LFA coverage and help the designer fine-tune it to get the level of protection they're after ✨

While this document highlights LFA applicability and benefits for SP networks, it also notes that LFAs are not meant to replace MPLS TE FRR 💀

With a very LFA-unfriendly topology, a designer who wants guaranteed <50-msec protection might be better off using the explicit-routed backup capability of MPLS TE FRR. That gives 100% protection, while making sure there's no congestion along the backup paths during protection 🔥

But when LFAs give 100% link and node protection without any uLoop, then the LFA method is clearly something to consider to drastically simplify the operation of a large-scale network 👑

8. Security Considerations 🔐

The security considerations that apply to LFAs are described in [RFC5286]. This document doesn't introduce any new security considerations 🫶

9. Conclusions 🌸

The LFA method is an important protection alternative for IP/MPLS networks 💖

Its simplicity benefit is significant: it's automated, it integrates with the default IGP behaviour, and it doesn't need any network-wide upgrade. The technology doesn't need any protocol change either, so it can be deployed router by router 🦋

At first sight, those big simplicity benefits get cancelled out by how much its applicability depends on the topology 😭

The purpose of this document is to highlight that very frequent access and aggregation topologies benefit from excellent link and node LFA coverage 🎀

A second objective is to describe the three different profiles of LFA applicability for IP/MPLS core networks, and to illustrate them with simulation results based on real SP core topologies 🧚

10. Acknowledgments 🫶

We'd like to thank Alvaro Retana and especially Stewart Bryant for their valuable comments on this work 💜

11. References 📚

11.1. Normative References

  • [RFC5286] Atlas, A., Ed., and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, September 2008. 💅

11.2. Informative References ✨

okay so these are the informative refs, aka the "nice to know" crew 🎀 they're not required reading to implement, but they give you the backstory. bestie, read them if you're curious 🧚

  • [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, January 2010. 💖
  • [RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free Convergence", RFC 5715, January 2010. 🦋
  • [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990. 🌸
  • [IS-IS] ISO/IEC 10589:2002, Second Edition, "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", 2002. 💅
  • [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. 🔥
  • [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. 🌈

Authors' Addresses ✨

meet the squad 🫶 these are the people who wrote it, with their contact details

Clarence Filsfils (editor)
Cisco Systems
Brussels  1000
BE

EMail: cf@cisco.com


Pierre Francois (editor)
Institute IMDEA Networks
Avda. del Mar Mediterraneo, 22
Leganese  28918
ES

EMail: pierre.francois@imdea.org


Mike Shand

EMail: imc.shand@googlemail.com


Bruno Decraene
France Telecom
38-40 rue du General Leclerc
92794 Issy Moulineaux cedex 9
FR

EMail: bruno.decraene@orange.com


James Uttaro
AT&T
200 S. Laurel Avenue
Middletown, NJ  07748
US

EMail: uttaro@att.com
Nicolai Leymann
Deutsche Telekom
Winterfeldtstrasse 21
10781, Berlin
DE

EMail: N.Leymann@telekom.de


Martin Horneffer
Deutsche Telekom
Hammer Str. 216-226
48153, Muenster
DE

EMail: Martin.Horneffer@telekom.de
📦 where this page comes from