RFC 8518

Selection of Loop-Free Alternates for Multi-Homed Prefixes

📅 published March 2019, from ietf

RFC 8518: Selection of Loop-Free Alternates for Multi-Homed Prefixes 💖

Okay bestie, let's start with the vibes! 🎀 This is RFC 8518, and it's a Standards Track document from March 2019 (ISSN 2070-1721). The editors are P. Sarkar (Arrcus, Inc.) and U. Chunduri (Huawei USA), with S. Hegde (Juniper Networks, Inc.), J. Tantsura (Apstra, Inc.), and H. Gredler (RtBrick, Inc.) also on the author list ✨. It updates RFC 5286, and the header doesn't list anything it obsoletes 🦋.

Abstract ✨

So the team had been building algorithms to find Loop-Free Alternates (LFAs) for multi-homed prefixes (MHPs), and real-life deployments taught them a lot 🧠. This doc gives explicit inequalities for checking whether a neighbor is a good potential alternate for an MHP. It also gives detailed criteria for judging potential alternates for external prefixes advertised by OSPF ASBRs. And it updates Section 6 of RFC 5286 by expanding some of the routing aspects 💜.

Status of This Memo 📜

This is an Internet Standards Track document 🌈.

It's a product of the Internet Engineering Task Force (IETF), and it represents the consensus of the IETF community 🫶. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 🍓.

For info on the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc8518 🧚.

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

Heads up, this one's under BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the date of publication. Read those carefully, because they spell out your rights and restrictions 🙈. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💅.

Table of Contents 🗂️

   1. Introduction ....................................................3
      1.1. Acronyms ...................................................4
      1.2. Requirements Language ......................................4
   2. LFA Inequalities for MHPs .......................................4
   3. LFA Selection for MHPs ..........................................6
      3.1. Improved Coverage with Simplified Approach to MHPs .........7
      3.2. IS-IS ATT Bit Considerations ...............................9
   4. LFA Selection for Multi-Homed External Prefixes ................10
      4.1. IS-IS .....................................................10
      4.2. OSPF ......................................................10
           4.2.1. Rules to Select Alternate ASBRs ....................10
               4.2.1.1. Multiple ASBRs Belonging to Different Areas ..12
               4.2.1.2. Type 1 and Type 2 Costs ......................12
               4.2.1.3. RFC1583Compatibility is Set to "Enabled" .....12
               4.2.1.4. Type 7 Routes ................................13
           4.2.2. Inequalities to Be Applied for Alternate ASBR
                  Selection ..........................................13
               4.2.2.1. Forwarding Address Set to Non-zero Value .....13
               4.2.2.2. ASBRs Advertising Type 1 and Type 2 Costs ....14
   5. LFA Extended Procedures ........................................15
      5.1. Links with IGP MAX_METRIC .................................15
      5.2. MT Considerations .........................................16
   6. IANA Considerations ............................................16
   7. Security Considerations ........................................17
   8. References .....................................................17
      8.1. Normative References ......................................17
      8.2. Informative References ....................................17
   Acknowledgements ..................................................19
   Contributors ......................................................19
   Authors' Addresses ................................................20

1. Introduction 🌸

Okay, the framework for IP Fast Reroute (FRR) mechanisms is detailed in [RFC5714] 🧚. The use of LFAs for IP FRR is specified in [RFC5286]. If a prefix is advertised by more than one router, that prefix is called a "multi-homed prefix (MHP)". MHPs usually show up for prefixes obtained from outside the routing domain by multiple routers, for subnets on links where the subnet is announced from multiple ends of the link, and for prefixes advertised by multiple routers to provide resiliency 💖.

Section 6.1 of [RFC5286] describes a method to determine LFAs for MHPs. This document describes a procedure using explicit inequalities that a computing router can use to evaluate a neighbor as a potential alternate for an MHP. The results are equivalent to those from the method in Section 6.1 of [RFC5286] 👑.

Section 6.3 of [RFC5286] discusses the complications of computing LFAs for MHPs in OSPF. This document gives detailed criteria for evaluating potential alternates for external prefixes advertised by OSPF ASBRs, as well as explicit inequalities 🔥.

This doc also adds clarifications and extra considerations to [RFC5286] for a few coverage and operational observations 🙈. These are: 1) the IS-IS ATT (attach) bit in the Level 1 (L1) area, 2) links provisioned with MAX_METRIC (see Section 5.1) for traffic engineering (TE) purposes, and 3) multi-topology (MT) IGP deployments. They get elaborated in detail in Sections 3.2 and 5 ✨.

This spec uses the same terminology introduced in [RFC5714] to represent LFA, and it builds on the notation for inequalities used in [RFC5286] to compute LFAs for MHPs 🫶.

1.1. Acronyms 🔤

   AF      -  Address Family

   ATT     -  IS-IS Attach Bit

   ECMP    -  Equal-Cost Multipath

   FRR     -  Fast Reroute

   IGP     -  Interior Gateway Protocol

   IS-IS   -  Intermediate System to Intermediate System

   LFA     -  Loop-Free Alternate

   LSP     -  Link State PDU (IS-IS)

   MHP     -  Multi-Homed Prefix

   MT      -  Multi-Topology

   OSPF    -  Open Shortest Path First

   SPF     -  Shortest Path First

1.2. Requirements Language 🎀

Here's the key word situation 🧐. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

2. LFA Inequalities for MHPs 💅

This document proposes the following set of LFA inequalities for selecting the most appropriate LFAs for MHPs. D_opt(X,Y) (called "D_opt(X,Y)" in this document) is defined in [RFC5714] and is nothing but the metric sum of the shortest path from X to Y. Cost(X,Y), introduced in this document, is defined as the metric value of prefix Y from the prefix advertising node X. These LFAs can be derived from the inequalities in [RFC5286] combined with the observation that D_opt(N,P) = Min (D_opt(N,PO_i) + Cost(PO_i,P)) over all PO_i.

Link-Protecting LFAs: 🦋 A neighbor N can provide an LFA if and only if

D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) +
                              D_opt(S,PO_best) + Cost(PO_best,P)

Link-Protecting + Downstream-paths-only LFAs: 🌈 A subset of loop-free alternates are downstream paths that must meet a more restrictive condition that is applicable to more complex failure scenarios.

D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + Cost(PO_best,P)

Node-Protecting LFAs: 🧚 For an alternate next hop N to protect against node failure of a primary neighbor E for MHP P, N must be loop-free with respect to both E and MHP P. In other words, N's path to MHP P must not go through E (where N is the neighbor providing a loop-free alternate).

D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) +
                              D_opt(E,PO_best) + Cost(PO_best,P)

Here's what each letter means 💖

Where:

P           -  The MHP being evaluated for computing alternates

S           -  The computing router

N           -  The alternate router being evaluated

E           -  The primary next hop on the shortest path from S to
               prefix P

PO_i        -  The specific prefix-originating router being
               evaluated

PO_best     -  The prefix-originating router on the shortest path
               from the computing router S to prefix P

Cost(X,P)   -  The cost of reaching the prefix P from prefix
               originating node X

D_opt(X,Y)  -  The distance on the shortest path from node X to
               node Y

3. LFA Selection for MHPs 💅

Okay bestie, so here's how a computing router S picks a valid LFA for an MHP 🦋 For each alternate neighbor N, S MUST run one of the procedures below once for each remote node that originated the prefix P.

Link-Protecting LFAs: 🔗

  1. If N is an alternate neighbor AND also a prefix originator of P, then:
    • A. Select N as an LFA for prefix P (irrespective of the metric advertised by N for the prefix P). ✨
  2. Else, evaluate the link-protecting LFA inequality for P with N as the alternate neighbor.
    • A. If the LFA inequality condition is met, select N as an LFA for prefix P. 🎀
    • B. Else, N is not an LFA for prefix P. 🙈

Link-Protecting + Downstream-paths-only LFAs: 🌸

  1. Evaluate the link-protecting + downstream-paths-only LFA inequality for P with N as the alternate neighbor.
    • A. If the LFA inequality condition is met, select N as an LFA for prefix P. 💖
    • B. Else, N is not an LFA for prefix P. 🙈

Node-Protecting LFAs: 🧚

  1. If N is an alternate neighbor AND also a prefix originator of P, then:
    • A. Select N as an LFA for prefix P (irrespective of the metric advertised by N for the prefix P). ✨
  2. Else, evaluate the appropriate node-protecting LFA inequality for P with N as the alternate neighbor.
    • A. If the LFA inequality condition is met, select N as an LFA for prefix P. 👑
    • B. Else, N is not an LFA for prefix P. 🙈

Now the big twist 🤯 If an alternate neighbor N is also one of the prefix originators of prefix P, it's guaranteed that N will not loop back packets destined for prefix P to computing router S. So N MUST be chosen as a valid LFA for prefix P without evaluating any of the inequalities in Section 2, as long as a downstream-paths-only LFA is not desired. To make sure such a neighbor N also provides a downstream-paths-only LFA, router S MUST also evaluate the downstream-paths-only LFA inequality specified in Section 2 for neighbor N and make sure router N satisfies the inequality. 🫶

However, if N is not a prefix originator of P, the computing router MUST evaluate one of the corresponding LFA inequalities defined in Section 2 once for each remote node that originated the prefix. If the inequality is satisfied by the neighbor N, router S MUST choose neighbor N as one of the valid LFAs for the prefix P. 💅

For more specific rules, please refer to Section 4. 📖

3.1. Improved Coverage with Simplified Approach to MHPs 🌈

Okay so Section 6.1 of the LFA base specification [RFC5286] recommends that a router computes the alternate next hop for an IGP MHP by considering alternate paths via all routers that have announced that prefix. The previous section elaborated on this with the appropriate inequalities. BUT 😭 Section 6.1 of [RFC5286] also lets the router simplify the MHP calculation by assuming that the MHP is solely attached to the router that was its pre-failure optimal point of attachment, at the expense of potentially lower coverage. If an implementation goes with that simplification, the procedure in this memo can potentially improve coverage for ECMP MHPs without adding extra computational cost. It's giving efficiency 🧠✨

This document improves the above approach to provide loop-free alternatives without any additional cost for ECMP MHPs, as shown in the example network in Figure 1. The approach here may also be applicable for handling default routes, as explained in Section 3.2. 🦋

                         5   +---+  8   +---+  5  +---+
                       +-----| S |------| A |-----| B |
                       |     +---+      +---+     +---+
                       |       |                    |
                       |     5 |                  5 |
                       |       |                    |
                     +---+ 5 +---+   4 +---+  1    +---+
                     | C |---| E |-----| M |-------| F |
                     +---+   +---+     +---+       +---+
                               |   10           5    |
                               +-----------P---------+

                   Figure 1: MHP with Same ECMP Next Hop

In Figure 1, a prefix P is advertised from both node E and node F. With the simplified approach from Section 6.1 of [RFC5286], prefix P only gets a link-protecting LFA through neighbor C, even though a node-protection path is available through neighbor A. Here, E and F are both pre-failure optimal points of attachment and share the same primary next hop. So an implementation MAY compare the kind of protection A gives to F (link and node protection) with the kind of protection C gives to E (link protection), and inherit the better alternative for prefix P. In this case, the better alternative is A. 🏆

Now in the example network in Figure 2, prefix P has an ECMP through both node E and node F with cost 20. Even though it has two pre-failure optimal points of attachment, the primary next hop to each one is different. So prefix P MUST inherit the corresponding LFAs of each primary next hop calculated for the router advertising the same. In Figure 2, that means the LFA for node E and node F, i.e., node N1 and node N2, respectively. 🤝

                                           4      +----+
                               +------------------| N2 |
                               |                  +----+
                               |                    | 4
                        10   +---+         3      +---+
                      +------| S |----------------| B |
                      |      +---+                +---+
                      |        |                    |
                      |     10 |                  1 |
                      |        |                    |
                   +----+ 5  +---+        16       +---+
                   | N1 |----| E |-----------------| F |
                   +----+    +---+                 +---+
                               |   10          16    |
                               +-----------P---------+

                Figure 2: MHP with Different ECMP Next Hops

tl;dr 💖 If an MHP has multiple pre-failure points of attachment, and its primary next hop is the same as the primary next hop of the router that was the pre-failure optimal point of attachment, an implementation MAY give the MHP better protection without any additional computation cost. 🎀

3.2. IS-IS ATT Bit Considerations 🍓

Per [RFC1195], a default route needs to be added in the Level 1 (L1) router to the closest reachable Level 1 / Level 2 (L1/L2) router in the network that advertises the ATT (attach) bit in its LSP-0 fragment. All L1 routers in the area do this during the decision process, with the next hop of the default route set to the adjacent router through which the closest L1/L2 router is reachable. The LFA base specification [RFC5286] doesn't specify any procedure for computing LFA for a default route in the IS-IS L1 area, so this is where things get interesting 👀 This document specifies that a node can treat a default route as being advertised from the border L1/L2 router where the ATT bit is set, and can do LFA computation for that default route. But when multiple ECMP L1/L2 routers are reachable in an L1 area, the corresponding best LFAs SHOULD be computed for each primary next hop associated with the default route, since this is similar to the ECMP MHP example described in Section 3.1. The considerations in Sections 3 and 3.1 apply to default routes if the default route is considered an ECMP MHP. Note that this document doesn't alter any ECMP handling rules or computation of LFAs for ECMP in general, as laid out in [RFC5286]. No drama there 💅✨

4. LFA Selection for Multi-Homed External Prefixes 🌍

Okay so redistributing external routes into an IGP is required 1) when two different networks get merged into one, or 2) during protocol migrations. 🔀

During LFA calculation, alternate LFA next hops to reach the best ASBR could be used as LFAs for the routes redistributed via that ASBR. When there's no LFA available to the best ASBR, it may be desirable to consider the other ASBRs (referred to as "alternate ASBRs" hereafter) that redistribute the external routes for LFA selection, as defined in [RFC5286]. This way you get to leverage the advantage of having multiple redistributing nodes in the network 🙌

4.1. IS-IS 🦋

LFA evaluation for multi-homed external prefixes in IS-IS is the same as for multi-homed internal prefixes. The inequalities described in Section 2 also apply to multi-homed external prefixes. Easy peasy 🫶

4.2. OSPF 🌸

The LFA base specification [RFC5286] describes mechanisms for applying inequalities to find the loop-free alternate neighbor. Extra rules have to be applied when selecting the alternate ASBR for LFA consideration, because of the external route calculation rules imposed by [RFC2328]. Lowkey tricky 😭

This document defines inequalities specifically for alternate loop-free ASBR evaluation. These inequalities are based on those in [RFC5286]. 💜

4.2.1. Rules to Select Alternate ASBRs 🧩

The process for selecting an alternate ASBR is best explained with the rules below. It's applied when a primary ASBR for the prefix in question has been chosen and there is an alternate ASBR originating the same prefix. 🎀

  1. If RFC1583Compatibility is disabled:
    • A. If the primary ASBR and alternate ASBR belong to intra-area non-backbone, go to step 2.
    • B. If the primary ASBR and alternate ASBR belong to intra-area backbone and/or inter-area path, go to step 2.
    • C. For other paths, skip this alternate ASBR and consider the next ASBR. 🙅‍♀️
  2. Compare the cost types (type 1 / type 2) advertised by the alternate ASBR and the primary ASBR:
    • A. If they're not the same type, skip the alternate ASBR and consider the next ASBR.
    • B. If they're the same, proceed to step 3. 💖
  3. If the cost types are type 1, compare the costs advertised by the alternate ASBR and the primary ASBR:
    • A. If the costs are the same, then program ECMP FRR and return. 🔥
    • B. Else, go to step 5.
  4. If the cost types are type 2, compare the costs advertised by the alternate ASBR and the primary ASBR:
    • A. If the costs are different, skip the alternate ASBR and consider the next ASBR.
    • B. If the costs are the same, proceed to step 4C to compare the costs to reach the ASBR/forwarding address.
    • C. If the costs to reach the ASBR/forwarding address are also the same, program ECMP FRR and return. ✨
    • D. If the costs to reach the ASBR/forwarding address are different, go to step 5.
  5. Compare the route types (type 5 and type 7) for the alternate ASBR and the primary ASBR:
    • A. If the route types are the same, check whether the p-bit and forwarding address field for the routes from both ASBRs match. If the p-bit and forwarding address match, proceed to step 6. If not, skip this alternate ASBR and consider the next ASBR.
    • B. If the route types are not the same, skip this alternate ASBR and consider the next alternate ASBR. 🙃
  6. Apply the inequality on the alternate ASBR. 👑

4.2.1.1. Multiple ASBRs Belonging to Different Areas

okay so when RFC1583Compatibility is set to "disabled" 💅, OSPF [RFC2328] has its own preference rules for picking ASBRs. When you're choosing an alternate ASBR to check for loops in LFA, those rules should be applied so the alternate neighbor can't cause looping 🔁

when there are multiple ASBRs in different areas advertising the same prefix, the pruning rules from Section 16.4 of [RFC2328] kick in. any alternate ASBRs pruned by those rules are not considered for LFA evaluation. bye bye 👋

4.2.1.2. Type 1 and Type 2 Costs

next up, if there are still multiple ASBRs that survived the pruning in Section 4.2.1.1, we compare the cost type each one advertises 🧐 ASBRs advertising type 1 costs are the queen 👑 so they get preferred, and type 2 costs get pruned. if two ASBRs advertise the same type 2 cost, the alternate ASBRs get checked along with their cost to reach the ASBR/forwarding address. if the two ASBRs have the same type 2 cost AND the same cost to reach the ASBR, ECMP FRR is programmed ✨

when multiple ASBRs advertise the same type 2 cost for the prefix, the primary AS external route calculation in Section 16.4.1 of [RFC2328] picks the route with the lowest type 2 cost. ASBRs advertising a different type 2 cost (a higher one) aren't considered for LFA evaluation 🙅‍♀️ alternate ASBRs that advertise a type 2 cost for the prefix but weren't picked as primary because of a higher cost to reach the ASBR are considered for LFA evaluation, though. the inequalities for alternate ASBRs with type 1 and type 2 costs are the same, since the mismatched type 2 ASBRs were already pruned and evaluation only runs on ASBRs with equal type 2 costs 🎀

4.2.1.3. RFC1583Compatibility is Set to "Enabled"

when RFC1583Compatibility is set to "enabled", ASBRs in different areas advertising the same prefix get chosen based on cost, so they're totally valid alternate ASBRs for LFA evaluation 🦋 the inequalities in Section 4.2.2 apply based on the forwarding address and the cost type advertised in the external Link State Advertisement (LSA).

4.2.1.4. Type 7 Routes

type 5 routes always beat type 7 routes, no contest 🏆 and the alternate ASBRs chosen for LFA calculation should belong to the same type. among type 7 routes, the ones with the p-bit and forwarding address set win over the ones without these attributes. alternate ASBRs selected for LFA comparison should have the same p-bit and forwarding address attributes 🌸

4.2.2. Inequalities to Be Applied for Alternate ASBR Selection

once we've picked alternate ASBRs using the mechanism from Section 4.2.1, we check them for loop-free criteria with the inequalities below 🧮

4.2.2.1. Forwarding Address Set to Non-zero Value

these are basically the Section 2 inequalities, but for when the forwarding address is a non-zero value 💖

Link-Protecting LFAs:

F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) +
                              F_opt(S,PO_best) + Cost(PO_best,P)

Link-Protecting + Downstream-paths-only LFAs:

F_opt(N,PO_i)+ Cost(PO_i,P) < F_opt(S,PO_best) + Cost(PO_best,P)

Node-Protecting LFAs:

F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) +
                              F_opt(E,PO_best) + Cost(PO_best,P)

Where:

P           -  The MHP being evaluated for computing alternates

S           -  The computing router

N           -  The alternate router being evaluated

E           -  The primary next hop on the shortest path from S to
               prefix P

PO_i        -  The specific prefix-originating router being
               evaluated

PO_best     -  The prefix-originating router on the shortest path
               from the computing router S to prefix P

Cost(X,Y)   -  The external cost for Y as advertised by X

F_opt(X,Y)  -  The distance on the shortest path from node X to
               the forwarding address specified by ASBR Y

D_opt(X,Y)  -  The distance on the shortest path from node X to
               node Y

4.2.2.2. ASBRs Advertising Type 1 and Type 2 Costs

same energy as Section 2 again, but this time for type 1 and type 2 costs 🌈

Link-Protecting LFAs:

D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) +
                              D_opt(S,PO_best) + Cost(PO_best,P)

Link-Protecting + Downstream-paths-only LFAs:

D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + Cost(PO_best,P)

Node-Protecting LFAs:

D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) +
                              D_opt(E,PO_best) + Cost(PO_best,P)

Where:

P           -  The MHP being evaluated for computing alternates

S           -  The computing router

N           -  The alternate router being evaluated

E           -  The primary next hop on the shortest path from S to
               prefix P

PO_i        -  The specific prefix-originating router being
               evaluated

PO_best     -  The prefix-originating router on the shortest path
               from the computing router S to prefix P

Cost(X,Y)   -  The external cost for Y as advertised by X

D_opt(X,Y)  -  The distance on the shortest path from node X to
               node Y

5. LFA Extended Procedures ✨

this section adds extra considerations on top of the LFA base specification in [RFC5286] 🎀

okay so Sections 3.5 and 3.6 of [RFC5286] describe how to exclude nodes and links from alternate paths based on the maximum link metric 🙈 if you follow those procedures strictly, there are situations (described below) where the only potential alternate that satisfies the basic loop-free condition never gets considered. this document calls the maximum link metric in IGPs the MAX_METRIC. it's called "maximum link metric" when defined for IS-IS in [RFC5305] and "MaxLinkMetric" when defined for OSPF in [RFC6987] 🧚

                         +---+  10  +---+  10 +---+
                         | S |------|N1 |-----|D1 |
                         +---+      +---+     +---+
                           |                    |
                        10 |                 10 |
                           |MAX_METRIC(N2 to S) |
                           |                    |
                           |       +---+        |
                           +-------|N2 |--------+
                                   +---+
                                 10  |
                                   +---+
                                   |D2 |
                                   +---+

Figure 3: Link with IGP MAX_METRIC

in the simple example network in Figure 3, all the links have a cost of 10 in both directions, except for the link between S and N2 🍓 the S-N2 link has a cost of 10 in the forward direction (S to N2) and a cost of MAX_METRIC (0xffffff /2^24 - 1 for IS-IS and 0xffff for OSPF) in the reverse direction (N2 to S), for a specific end-to-end TE requirement of the operator. at node S, D1 is reachable through N1 with a cost of 20, and D2 is reachable through N2 with a cost of 20. even though neighbor N2 satisfies the basic loop-free condition (inequality 1 of [RFC5286]) for D1, S's neighbor N2 could still get excluded as a potential alternative because of the current exclusions in Sections 3.5 and 3.6 of [RFC5286]. but the primary traffic destined to D2 keeps using the link, so no matter what the reverse metric is, the same link MAY be used as a potential LFA for D1 💅

alternatively, the reverse metric of the link MAY be configured with MAX_METRIC-1, so the link can be used as an alternative while still meeting the operator's TE requirements, without having to update the router to fix this particular issue 🦋

5.2. MT Considerations

Sections 6.2 and 6.3.2 of [RFC5286] say that multi-topology OSPF and IS-IS are out of scope for that specification. this memo clarifies and describes the applicability 🌸

in multi-topology IGP deployments, a separate shortest path tree (SPT) gets built for each MT-ID with topology-specific adjacencies, so the LFA principles laid out in [RFC5286] are actually applicable for MT IS-IS [RFC5120] LFA SPF 🔥 the main difference is figuring out the eligible set of neighbors for each LFA computation, and that's done per MT-ID. the eligible set for each MT-ID is determined by whether there's an IGP adjacency from the source to the neighboring node on that MT-ID, apart from the administrative restrictions and other checks laid out in [RFC5286]. the same also applies to MT-OSPF [RFC4915] or to different AFs in multi-instance OSPFv3 [RFC5838] 🫶

however, for MT IS-IS, if a "standard unicast topology" is used with MT-ID #0 [RFC5120] and both IPv4 [RFC5305] and IPv6 routes/AFs [RFC5308] are present, then the condition of network congruency applies to LFA computation as well 👑 network congruency here means having the same address families provisioned on all the links and all the nodes of the network with MT-ID #0. with a single-decision process, both IPv4 and IPv6 next hops get computed for all the prefixes in the network. similarly, with one LFA computation from all eligible neighbors per [RFC5286], all potential alternatives can be computed ✨

6. IANA Considerations

nothing for IANA here! This document has no IANA actions. 🧸

7. Security Considerations 🔐

the existing OSPF security considerations continue to apply, and so do the recommended manual key management mechanisms specified in [RFC7474] 🛡️ the existing security considerations for IS-IS also continue to apply, as specified in [RFC5304] and [RFC5310] and extended by [RFC7645] for Keying and Authentication for Routing Protocols (KARP). this document does not change any of the discussed protocol specifications (i.e., [RFC1195], [RFC5120], [RFC2328], and [RFC5838]), so the security considerations of the LFA base specification [RFC5286] continue to apply. this part is serious, bestie, so keep those security considerations in mind 💀

8. References

8.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC5286]  Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
           IP Fast Reroute: Loop-Free Alternates", RFC 5286,
           DOI 10.17487/RFC5286, September 2008,
           <https://www.rfc-editor.org/info/rfc5286>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2. Informative References 📚✨

okay so these are the "if you want the backstory" reads 🤓 you don't strictly need them to get the spec, but they're the BFFs this doc keeps referencing 💖

Acknowledgements 🙏💖

The authors give a huge shoutout to Alia Atlas and Salih K.A. for their super useful feedback and input 🫶 Massive thanks to Stewart Bryant for being Document Shepherd and dropping detailed review comments 🔥 Thanks to Elwyn Davies for reviewing and giving feedback as part of the Gen-ART review 🌸 And thanks to Alvaro Retana, Adam Roach, Ben Campbell, Benjamin Kaduk, and sponsoring Routing Area Director Martin Vigoureux for the detailed feedback and suggestions 👑

Contributors 🫶🎀

These people contributed substantially to the content of this document and should be considered coauthors ✨

Chris Bowers
Juniper Networks, Inc.
1194 N. Mathilda Ave.
Sunnyvale, CA  94089
United States of America

Email: cbowers@juniper.net
Bruno Decraene
Orange
France

Email: bruno.decraene@orange.com

Authors' Addresses 💌🦋

Meet the squad 💜

Pushpasis Sarkar (editor)
Arrcus, Inc.

Email: pushpasis.ietf@gmail.com
Uma Chunduri (editor)
Huawei USA
2330 Central Expressway
Santa Clara, CA  95050
United States of America

Email: uma.chunduri@huawei.com
Shraddha Hegde
Juniper Networks, Inc.
Electra, Exora Business Park
Bangalore, KA  560103
India

Email: shraddha@juniper.net
Jeff Tantsura
Apstra, Inc.

Email: jefftant.ietf@gmail.com
Hannes Gredler
RtBrick, Inc.

Email: hannes@rtbrick.com
📦 where this page comes from