Routing Area Working Group                                 A. Atlas, Ed.
Internet-Draft                                                 R. Kebler
Intended status: Standards Track                        Juniper Networks
Expires: August 28, 2013 January 13, 2014                                      G. Enyedi
                                                              A. Csaszar
                                                             J. Tantsura
                                                                Ericsson
                                                      M. Konstantynowicz
                                                           Cisco Systems
                                                                R. White
                                                                Verisign
                                                                M. Shand
                                                       February 24,
                                                                     VCE
                                                           July 12, 2013

An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees
                draft-ietf-rtgwg-mrt-frr-architecture-02
                draft-ietf-rtgwg-mrt-frr-architecture-03

Abstract

   As IP and LDP Fast-Reroute are increasingly deployed, the coverage
   limitations

   With increasing deployment of Loop-Free Alternates are seen as a problem (LFA) [RFC5286],
   it is clear that
   requires a straightforward and consistent complete solution for IP and LDP,
   for unicast and multicast. LDP Fast-Reroute is
   required.  This draft describes an architecture
   based on redundant backup trees where a single failure can cut specification provides that solution.  IP/LDP Fast-
   Reroute with Maximally Redundant Trees (MRT-FRR) is a
   point-of-local-repair from the destination only on one of technology that
   gives link-protection and node-protection with 100% coverage in any
   network topology that is still connected after the pair of
   redundant trees.

   One innovative algorithm failure.

   MRT removes all need to compute such topologies engineer for coverage.  MRT is maximally
   disjoint backup trees.  Each also extremely
   computationally efficient.  For any router can compute its next-hops for
   each pair of maximally disjoint trees rooted at each node in the IGP
   area with computational complexity similar to that required by
   Dijkstra.

   The additional state, address and network, the MRT
   computation requirements are
   believed to be significantly is less than the Not-Via architecture
   requires. LFA computation for a node with three or
   more neighbors.

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 28, 2013. January 13, 2014.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  4   3
     1.1.  Goals for Extending IP Fast-Reroute coverage beyond LFA  Importance of 100% Coverage . . . . . . . . . . . . . . .   4
     1.2.  Partial Deployment and Backwards Compatibility  . . . . .   5
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   6
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.   6
   4.  Maximally Redundant Trees (MRT) . . . . . . . . . . . . . . .  6
   4.   7
   5.  Maximally Redundant Trees (MRT) and Fast-Reroute  . . . . . . .  8
   5.   9
   6.  Unicast Forwarding with MRT Fast-Reroute  . . . . . . . . . . .  9
     5.1.  10
     6.1.  LDP Unicast Forwarding - Avoid Tunneling  . . . . . . . . .  10
     5.2.
     6.2.  IP Unicast Traffic  . . . . . . . . . . . . . . . . . . . . 10
   6.  11
   7.  Protocol Extensions and Considerations: OSPF and ISIS . . . .  12
   7.
   8.  Protocol Extensions and considerations: LDP . . . . . . . . .  14
   8.  Multi-homed Prefixes
   9.  Inter-Area and ABR Forwarding Behavior  . . . . . . . . . . .  15
   10. Prefixes Multiply Attached to the MRT Island  . . . . . . . .  18
     10.1.  Endpoint Selection . . 15
   9.  Inter-Area and ABR Forwarding Behavior . . . . . . . . . . . . 16
   10. Issues with Area Abstraction . . . . . . . . . . . . . . . . .  19
   11. Partial Deployment and Islands of Compatible MRT FRR
       routers  . . . . . .
     10.2.  Named Proxy-Nodes  . . . . . . . . . . . . . . . . . . .  21
       10.2.1.  Computing if an Island Neighbor (IN) is loop-free  .  22
     10.3.  MRT Alternates for Destinations Outside the MRT Island . 20
   12.  23
   11. Network Convergence and Preparing for the Next Failure  . . . . 22
     12.1.  24
     11.1.  Micro-forwarding loop prevention and MRTs  . . . . . . . . 22
     12.2.  24
     11.2.  MRT Recalculation  . . . . . . . . . . . . . . . . . . . . 23
   13.  24
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 23
   14.  25
   13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
   15.  25
   14. Security Considerations . . . . . . . . . . . . . . . . . . . 24
   16.  25
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 24
     16.1.  25
     15.1.  Normative References . . . . . . . . . . . . . . . . . . . 24
     16.2.  25
     15.2.  Informative References . . . . . . . . . . . . . . . . .  26
   Appendix A.  General Issues with Area Abstraction . . . . . 24 . . .  27
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 25  28

1.  Introduction

   There is still work required to completely provide IP

   This document gives a complete solution for IP/LDP fast-reroute
   [RFC5714].  MRT-FRR creates two alternate trees separate from the
   primary next-hop forwarding used during stable operation.  These two
   trees are maximally diverse from each other, providing link and LDP Fast-
   Reroute[RFC5714] node
   protection for unicast 100% of paths and multicast traffic. failures as long as the failure does
   not cut the network into multiple pieces.  This draft
   proposes an document defines the
   architecture to provide 100% coverage for unicast
   traffic. IP/LDP fast-reroute with MRT.  The associated multicast architecture is described
   protocol extensions are defined in
   [I-D.atlas-rtgwg-mrt-mc-arch].

   Loop-free alternates (LFAs)[RFC5286] provide a useful mechanism for
   link [I-D.atlas-ospf-mrt] and node protection but getting complete coverage
   [I-D.atlas-mpls-ldp-mrt].  The exact MRT algorithm is quite hard.
   [LFARevisited] defines sufficient conditions to determine if a
   network provides link-protecting LFAs and also proves that augmenting
   a network defined in
   [I-D.enyedi-rtgwg-mrt-frr-algorithm].

   IP/LDP Fast-Reroute with MRT (MRT-FRR) uses two maximally diverse
   forwarding topologies to provide better coverage is NP-hard.
   [I-D.ietf-rtgwg-lfa-applicability] discusses the applicability alternates.  A primary next-hop
   should be on only one of LFA the diverse forwarding topologies; thus, the
   other can be used to different topologies with a focus on common PoP architectures.

   While Not-Via [I-D.ietf-rtgwg-ipfrr-notvia-addresses] is defined as provide an architecture, in practice, it has proved too complicated and
   stateful to spark substantial interest in implementation or
   deployment.  Academic implementations [LightweightNotVia] exist and
   have found the address management complexity high (but no
   standardization alternate.  Once traffic has been done
   moved to reduce this).

   A different approach is needed and that is what is described here.
   It is based on the idea one of using disjoint backup topologies as
   realized by Maximally Redundant Trees (described in
   [LightweightNotVia]); the general architecture can also apply to
   future improved redundant tree algorithms.

1.1.  Goals for Extending IP Fast-Reroute coverage beyond LFA

   Any scheme proposed for extending IPFRR network topology coverage
   beyond LFA, apart from attaining basic IPFRR properties, should also
   aim MRTs, it is not subject to achieve the following usability goals:

   o  ensure maximum physically feasible link and node disjointness
      regardless of topology,

   o  automatically compute backup next-hops based on further repair actions.
   Thus, the topology
      information distributed by link-state IGP,

   o  do traffic will not require any signaling in the case of loop even if a worse failure and use pre-
      programmed backup next-hops for forwarding,

   o  introduce minimal amount of additional addressing and state on
      routers,

   o  enable gradual introduction of the new scheme and backward
      compatibility,

   o  and do not impose requirements (e.g. node)
   occurs when protection was only available for external computation.

2.  Terminology

   2-connected:   A graph that has no cut-vertices.  This is a graph
      that requires two nodes simpler failure (e.g.
   link).

   In addition to be removed before supporting IP and LDP unicast fast-reroute, the network is
      partitioned.

   2-connected cluster:   A maximal set
   diverse forwarding topologies and guarantee of nodes that are 2-connected.

   2-edge-connected:   A network graph where at least two links must be
      removed to partition the network.

   ADAG:   Almost Directed Acyclic Graph - a graph that, if all links
      incoming 100% coverage permit
   fast-reroute technology to the root were removed, would be a DAG.

   block:   Either a 2-connected cluster, a cut-edge, applied to multicast traffic as
   described in [I-D.atlas-rtgwg-mrt-mc-arch].

   Other existing or an isolated
      vertex. proposed solutions are partial solutions or have
   significant issues, as described below.

                 Summary Comparison of IP/LDP FRR Methods

   +-----------+---------------+---------------+-----------------------+
   |   Method  |    Coverage   |   Alternate   | Computation (in SPFs) |
   |           |               |    Looping?   |                       |
   +-----------+---------------+---------------+-----------------------+
   |  MRT-FRR  |      100%     |      None     |      less than 3      |
   |           |   Link/Node   |               |                       |
   |           |               |               |                       |
   |    LFA    |    Partial    |    Possible   |      per neighbor     |
   |           |   Link/Node   |               |                       |
   |           |               |               |                       |
   |   Remote  |    Partial    |    Possible   |  per neighbor (link)  |
   |    LFA    |   Link/Node   |               |     or neighbor's     |
   |           |               |               |    neighbor (node)    |
   |           |               |               |                       |
   |  Not-Via  |      100%     |      None     |   per link and node   |
   |           |   Link/Node   |               |                       |
   +-----------+---------------+---------------+-----------------------+

                                  Table 1

   Loop-Free Alternates (LFA):   LFAs [RFC5286] provide limited
      topology-dependent coverage for link and node protection.
      Restrictions on choice of alternates can be relaxed to improve
      coverage, but this can cause forwarding loops if a worse failure
      is experienced than protected against.  Augmenting a network to
      provide better coverage is NP-hard [LFARevisited].  [RFC6571]
      discusses the applicability of LFA to different topologies with a
      focus on common PoP architectures.

   Remote LFA:   Remote LFAs [I-D.ietf-rtgwg-remote-lfa] improve
      coverage over LFAs for link protection but still cannot guarantee
      complete coverage.  The trade-off of looping traffic to improve
      coverage is still made.  Remote LFAs can provide node-protection
      [I-D.litkowski-rtgwg-node-protect-remote-lfa] but not guaranteed
      coverage and the computation required is quite high (an SPF per
      neighbor's neighbor).  [I-D.bryant-ipfrr-tunnels] describes
      additional mechanisms to further improve coverage, at the cost of
      added complexity.

   Not-Via:   Not-Via [I-D.ietf-rtgwg-ipfrr-notvia-addresses] is the
      only other solution that provides 100% coverage for link and node
      failures and does not have potential looping.  However, the
      computation is very high (an SPF per failure point) and academic
      implementations [LightweightNotVia] have found the address
      management complexity to be high.

1.1.  Importance of 100% Coverage
   Fast-reroute is based upon the single failure assumption - that the
   time between single failures is long enough for a network to
   reconverge and start forwarding on the new shortest paths.  That does
   not imply that the network will only experience one failure or
   change.

   It is straightforward to analyze a particular network topology for
   coverage.  However, a real network does not always have the same
   topology.  For instance, maintenance events will take links or nodes
   out of use.  Simply costing out a link can have a significant effect
   on what LFAs are available.  Similarly, after a single failure has
   happened, the topology is changed and its associated coverage.
   Finally, many networks have new routers or links added and removed;
   each of those changes can have an effect on the coverage for
   topology-sensitive methods such as LFA and Remote LFA.  If fast-
   reroute is important for the network services provided, then a method
   that guarantees 100% coverage is important to accomodate natural
   network topology changes.

   Asymmetric link costs are also a common aspect of networks.  There
   are at least three common causes for them.  First, any broadcast
   interface is represented by a pseudo-node and has asymmetric link
   costs to and from that pseudo-node.  Second, when routers come up or
   a link with LDP comes up, it is recommended in [RFC5443] and
   [RFC3137] that the link metric be raised to the maximum cost; this
   may not be symmetric and for [RFC3137] is not expected to be.  Third,
   techniques such as IGP metric tuning for traffic-engineering can
   result in asymmetric link costs.  A fast-reroute solution needs to
   handle network topologies with asymmetric link costs.

   When a network needs to use a micro-loop prevention mechanism
   [RFC5715] such as Ordered FIB[I-D.ietf-rtgwg-ordered-fib] or Farside
   Tunneling[RFC5715], then the whole IGP area needs to have alternates
   available so that the micro-loop prevention mechanism, which requires
   slower network convergence, can take the necessary time without
   impacting traffic badly.  Without complete coverage, traffic to the
   unprotected destinations will be dropped for significantly longer
   than with current convergence - where routers individually converge
   as fast as possible.

1.2.  Partial Deployment and Backwards Compatibility

   MRT-FRR supports partial deployment.  As with many new features, the
   protocols (OSPF, LDP, ISIS) indicate their capability to support MRT.
   Inside the MRT-capable connected group of routers (referred to as an
   MRT Island), the MRTs are computed.  Alternates to destinations
   outside the MRT Island are computed and depend upon the existence of
   a loop-free neighbor of the MRT Island for that destination.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119]

3.  Terminology

   network graph:   A graph that reflects the network topology where all
      links connect exactly two nodes and broadcast links have been
      transformed into the standard pseudo-node representation.

   Redundant Trees (RT):   A pair of trees where the path from any node
      X to the root R along the first tree is node-disjoint with the
      path from the same node X to the root along the second tree.
      These can be computed in 2-connected graphs.

   Maximally Redundant Trees (MRT):   A pair of trees where the path
      from any node X to the root R along the first tree and the path
      from the same node X to the root along the second tree share the
      minimum number of nodes and the minimum number of links.  Each
      such shared node is a cut-vertex.  Any shared links are cut-links.
      Any RT is an MRT but many MRTs are not RTs.

   MRT-Red:   MRT-Red is used to describe one of the two MRTs; it is
      used to described the associated forwarding topology and MT-ID.
      Specifically, MRT-Red is the decreasing MRT where links in the
      GADAG are taken in the direction from a higher topologically
      ordered node to a lower one.

   MRT-Blue:   MRT-Blue is used to describe one of the two MRTs; it is
      used to described the associated forwarding topology and MT-ID.
      Specifically, MRT-Blue is the increasing MRT where links in the
      GADAG are taken in the direction from a lower topologically
      ordered node to a higher one.

   Rainbow MRT:   It is useful to have an MT-ID that refers to the
      multiple MRT topologies and to the default topology.  This is
      referred to as the Rainbow MRT MT-ID and is used by LDP to reduce
      signaling and permit the same label to always be advertised to all
      peers for the same (MT-ID, Prefix).

   MRT Island:   From the computing router, the set of routers that
      support a particular MRT profile and are connected.

   Island Border Router (IBR):   A router in the MRT Island that is
      connected to a router not in the MRT Island and both routers are
      in a common area or level.

   Island Neighbor (IN):   A router that is not in the MRT Island but is
      adjacent to an IBR and in the same area/level as the IBR.

   cut-link:   A link whose removal partitions the network.  A cut-link
      by definition must be connected between two cut-vertices.  If
      there are multiple parallel links, then they are referred to as
      cut-links in this document if removing the set of parallel links
      would partition the network. network graph.

   cut-vertex:   A vertex whose removal partitions the network.

   DAG:   Directed Acyclic Graph - a network graph.

   2-connected:   A graph where all links are directed
      and there are that has no cycles in it.

   GADAG:   Generalized ADAG - cut-vertices.  This is a graph
      that is the combination of the
      ADAGs of all blocks.

   Maximally Redundant Trees (MRT):   A pair of trees where the path
      from any node X to the root R along the first tree and the path
      from the same node X requires two nodes to be removed before the root along the second tree share the
      minimum number network is
      partitioned.

   2-connected cluster:   A maximal set of nodes and the minimum number of links.  Each
      such shared node is a cut-vertex.  Any shared links are cut-links.
      Any RT is an MRT but many MRTs that are not RTs.

   network graph: 2-connected.

   2-edge-connected:   A network graph that reflects where at least two links must be
      removed to partition the network topology network.

   block:   Either a 2-connected cluster, a cut-edge, or an isolated
      vertex.

   DAG:   Directed Acyclic Graph - a graph where all links connect exactly two nodes are directed
      and broadcast there are no cycles in it.

   ADAG:   Almost Directed Acyclic Graph - a graph that, if all links have been
      transformed into the standard pseudo-node representation.

   Redundant Trees (RT):   A pair of trees where the path from any node
      X
      incoming to the root R along the first tree were removed, would be a DAG.

   GADAG:   Generalized ADAG - a graph that is node-disjoint with the
      path from the same node X to the root along combination of the second tree.
      These
      ADAGs of all blocks.

   named proxy-node:   A proxy-node can represent a destination prefix
      that can be computed in 2-connected graphs.

3.  Maximally Redundant Trees (MRT)

   In the last few years, there's been substantial research on how attached to
   compute and use redundant trees.  Redundant trees are directed
   spanning trees that provide disjoint paths towards their common root.
   These redundant trees only exist and provide link protection if the
   network MRT Island via at least two routers.
      It is 2-edge-connected and node protection named if the network there is
   2-connected.  Such connectiveness may not a way that traffic can be the case in real
   networks, either due to architecture or due encapsulated to a previous failure.
   The work on maximally redundant trees has added two useful pieces
      reach specifically that make them ready proxy node; this could be because there is
      an LDP FEC for use the associated prefix or because MRT-Red and MRT-
      Blue IP addresses are advertised in a real network.

   o  Computable regardless an undefined fashion for that
      proxy-node.

4.  Maximally Redundant Trees (MRT)

   A pair of network topology: The maximally redundant
      trees Maximally Redundant Trees are computed so directed spanning trees that only the cut-edges
   provide maximally disjoint paths towards their common root.  Only
   links or cut-vertices nodes whose failure would partition the network (i.e. cut-
   links and cut-vertices) are shared between the multiple trees.

   o  Computationally practical  The algorithm
   to compute MRTs is based on a common network
      topology database.  Algorithm variants given in [I-D.enyedi-rtgwg-mrt-frr-algorithm].
   This algorithm can compute be computed in O( e) or O(e + n log n), as given in [I-D.enyedi-rtgwg-mrt-frr-algorithm].

   There is, of course, significantly more in the literature related to
   redundant trees and even fast-reroute, but the formulation of the
   Maximally Redundant Trees (MRT) algorithm makes n); it very well suited
   to use in routers.

   A known disadvantage of MRT, and redundant trees in general, is that
   the trees do not necessarily provide shortest detour paths.  The use
   of the shortest-path-first algorithm in tree-building and including
   all links in the network as possibilities for one path or another
   should improve this. less than
   three SPFs.  Modeling is underway to investigate and compare
   the results comparing MRT alternates to the optimal
   [I-D.enyedi-rtgwg-mrt-frr-algorithm].  Providing shortest detour
   paths would require failure-specific detour paths to the
   destinations, but the state-reduction advantage of MRT lies in the
   detour being established per destination (root) instead of per
   destination AND per failure.

   The specific algorithms to compute MRTs as well as the logic behind
   that algorithm and alternative computational approaches
   are given in
   detail described in [I-D.enyedi-rtgwg-mrt-frr-algorithm].  Those interested are
   highly recommended to read that document.  This document
   describes how the MRTs can be used and not how to compute them.

   MRT provides destination-based trees for each destination.  Each
   router stores its normal primary next-hop(s) as well as MRT-Blue
   next-hop(s) and MRT-Red next-hop(s) toward each destination.  The
   alternate will be selected between the MRT-Blue and MRT-Red.

   The most important thing to understand about MRTs is that for each
   pair of destination-routed MRTs, there is a path from every node X to
   the destination D on the Blue MRT that is as disjoint as possible
   from the path on the Red MRT.  The two paths along the two MRTs to a
   given destination-root of a 2-connected graph are node-disjoint and
   link-disjoint, while in any non-2-connected graph, only D on the cut-
   vertices and cut-edges can be contained by both of Blue MRT that is as disjoint as possible
   from the paths. path on the Red MRT.

   For example, in Figure 1, there is a network graph that is
   2-connected in (a) and associated MRTs in (b) and (c).  One can
   consider the paths from B to R; on the Blue MRT, the paths are
   B->F->D->E->R or B->C->D->E->R.  On the Red MRT, the path is B->A->R.
   These are clearly link and node-disjoint.  These MRTs are redundant
   trees because the paths are disjoint.

   [E]---[D]---|           [E]<--[D]<--|                [E]-->[D]---|
    |     |    |            |     ^    |                       |    |
    |     |    |            V     |    |                       V    V
   [R]   [F]  [C]          [R]   [F]  [C]               [R]   [F]  [C]
    |     |    |                  ^    ^                 ^     |    |
    |     |    |                  |    |                 |     V    |
   [A]---[B]---|           [A]-->[B]---|                [A]---[B]<--|                [A]<--[B]<--|

         (a)                     (b)                         (c)
   a 2-connected graph     Blue MRT towards R          Red MRT towards R

                      Figure 1: A 2-connected Network

   By contrast, in Figure 2, the network in (a) is not 2-connected.  If
   F, G or the link F<->G failed, then the network would be partitioned.
   It is clearly impossible to have two link-disjoint or node-disjoint
   paths from G, I or J to R.  The MRTs given in (b) and (c) offer paths
   that are as disjoint as possible.  For instance, the paths from B to
   R are the same as in Figure 1 and the path from G to R on the Blue
   MRT is G->F->D->E->R and on the Red MRT is G->F->B->A->R.

                      [E]---[D]---|
                       |     |    |     |----[I]
                       |     |    |     |     |
                      [R]---[C]  [F]---[G]    |
                       |     |    |     |     |
                       |     |    |     |----[J]
                      [A]---[B]---|

                                  (a)
                        a non-2-connected graph

       [E]<--[D]<--|                        [E]-->[D]---|                        [E]-->[D]
        |     ^    |          [I]                  |    |          [I]          |----[I]
        V     |    |           ^           |                   V          V           |
       [R]<--[C]     ^
       [R]   [C]  [F]<--[G]    |            [R]---[C]            [R]<--[C]  [F]<--[G]    |
              ^    ^     |     |             ^     |    |     ^     V             ^          |           |     |--->[J]
              |     V    |     |----[J]            |          |          [J]
       [A]-->[B]---|                        [A]<--[B]<--|

                   (b)                                    (c)
            Blue MRT towards R                    Red MRT towards R

                    Figure 2: A non-2-connected network

4.

5.  Maximally Redundant Trees (MRT) and Fast-Reroute

   In normal IGP routing, each router has its shortest-path-tree to all
   destinations.  From the perspective of a particular destination, D,
   this looks like a reverse SPT (rSPT).  To use maximally redundant
   trees, in addition, each destination D has two MRTs associated with
   it; by convention these will be called the blue MRT-Blue and red MRTs. MRT-Red.
   MRT-FRR is realized by using multi-topology forwarding.  There is a
   MRT-Blue forwarding topology and a MRT-Red forwarding topology.

   Any IP/LDP fast-reroute technique beyond LFA requires an additional
   dataplane procedure, such as an additional forwarding mechanism.  The
   well-known options are multi-topology forwarding (used by MRT-FRR),
   tunneling (e.g. [I-D.ietf-rtgwg-ipfrr-notvia-addresses] or
   [I-D.ietf-rtgwg-remote-lfa]), and per-interface forwarding (e.g.  Loop-
   Free
   Loop-Free Failure Insensitive Routing in [EnyediThesis]), and multi-
   topology forwarding.  MRT is realized by using multi-topology
   forwarding.  There is a Blue MRT forwarding topology and a Red MRT
   forwarding topology.

   MRTs are practical to maintain redundancy even after a single link or
   node failure.  If a pair of MRTs is computed rooted at each
   destination, all the destinations remain reachable along one of the
   MRTs in the case of a single link or node failure. [EnyediThesis]).

   When there is a link or node failure affecting affecting, but not partitioning,
   the rSPT, network, each node will still have at least one path via one of
   the MRTs to reach the destination D.  For example, in Figure 2, C
   would normally forward traffic to R across the C<->R link.  If that
   C<->R link fails, then C could use either the Blue MRT path C->D->E->R or the Red MRT path
   C->B->A->R. C->D->E->R.

   As is always the case with fast-reroute technologies, forwarding does
   not change until a local failure is detected.  Packets are forwarded
   along the shortest path.  The appropriate alternate to use is pre-
   computed.  [I-D.enyedi-rtgwg-mrt-frr-algorithm] describes exactly how
   to determine whether the Blue MRT MRT-Blue next-hops or the Red MRT MRT-Red next-hops
   should be the MRT alternate next-hops for a particular primary next-
   hop N to a particular destination D.

   MRT alternates are always available to use, unless the network has
   been partitioned. use.  It is a local decision
   whether to use an MRT alternate, a Loop-Free Alternate or some other
   type of alternate.
   When a network needs to use a micro-loop prevention mechanism
   [RFC5715] such as Ordered FIB[I-D.ietf-rtgwg-ordered-fib] or Farside
   Tunneling[RFC5715], then the whole IGP area needs to have alternates
   available so that the micro-loop prevention mechanism, which requires
   slower network convergence, can take the necessary time without
   impacting traffic badly.

   As described in [RFC5286], when a worse failure than is anticipated
   happens, using LFAs that are not downstream neighbors can cause
   micro-looping.  An  Section 1.1 of [RFC5286] gives an example is given of link-protecting link-
   protecting alternates causing a loop on node failure.  Even if a
   worse failure than anticipated happened, happens, the use of MRT alternates
   will not cause looping.  Therefore, while node-protecting LFAs may be prefered, an
   preferred, the certainty that no alternate-induced looping will occur
   is an advantage of using MRT alternates when the available node-protecting node-
   protecting LFA is not a downstream path.

5.

6.  Unicast Forwarding with MRT Fast-Reroute

   With LFA, there is no need to tunnel unicast traffic, whether IP or
   LDP.  The traffic is simply sent to an alternate.  As mentioned
   earlier in Section 4, 5, MRT needs multi-topology forwarding.
   Unfortunately, neither IP nor LDP provide provides extra bits for a packet to
   indicate its topology.

   Once the MRTs are computed, the two sets of MRTs are seen by the
   forwarding plane as essentially two additional topologies.  The same
   considerations apply for forwarding along the MRTs as for handling
   multiple topologies.

5.1.

6.1.  LDP Unicast Forwarding - Avoid Tunneling

   For LDP, it is very desirable to avoid tunneling because, for at
   least node protection, tunneling requires knowledge of remote LDP
   label mappings and thus requires targeted LDP sessions and the
   associated management complexity.  There are two different mechanisms
   that can be used. used; Option A MUST be supported.

   1.  Option A - Encode MT-ID in Labels: In addition to sending a
       single label for a FEC, a router would provide two additional
       labels with the MT-IDs associated with the Blue MRT or Red MRT
       forwarding topologies.  This is very simple for hardware support.
       It does reduce the label space for other uses.  It also increases
       the memory to store the labels and the communication required by
       LDP.

   2.  Option B - Create Topology-Identification Labels: Use the label-
       stacking ability of MPLS and specify only two additional labels -
       one for each associated MRT color - by a new FEC type.  When
       sending a packet onto an MRT, first swap the LDP label and then
       push the topology-identification label for that MRT color.  When
       receiving a packet with a topology-identification label, pop it
       and use it to guide the next-hop selection in combination with
       the next label in the stack; then swap the remaining label, if
       appropriate, and push the topology-identification label for the
       next-hop.  This has minimal usage of additional labels, memory
       and LDP communication.  It does increase the size of packets and
       the complexity of the required label operations and look-ups.
       This can use the same mechanisms as are needed for context-aware
       label spaces.

   Note that with LDP unicast forwarding, regardless of whether
   topology-identification label or encoding topology in label is used,
   no additional loopbacks per router are required.  This is because LDP
   labels are used on a hop-by-hop basis to identify MRT-blue and MRT-
   red forwading topologies.

   For greatest hardware compatibility, routers implementing MRT LDP
   fast-reroute MUST support Option A of encoding the MT-ID in the
   labels.  The extensions to indicate an MT-ID for a FEC are described
   in Section 3.2.1 of [I-D.ietf-mpls-ldp-multi-topology]

5.2. [I-D.ietf-mpls-ldp-multi-topology].

6.2.  IP Unicast Traffic

   For IP, there is no currently practical alternative except tunneling. tunneling
   to gain the bits needed to indicate the MRT-Blue or MRT-Red
   forwarding topology.  The choice of tunnel egress could MAY be flexible
   since any router closer to the destination than the next-hop can
   work.  This architecture assumes that the original destination in the area,
   area is selected (see Section 10 for handling of multi-homed
   prefixes); another possible choice is the next-next-hop towards the
   destination.  For LDP traffic, using the original destination
   simplifies MRT-FRR by avoiding the need for targeted LDP sessions to
   the
   next-next-hop, etc.. next-next-hop.  For IP, that consideration doesn't apply but
   consistency with LDP is RECOMMENDED.  If the tunnel egress is the
   original destination router, then the traffic remains on the
   redundant tree with sub-optimal routing.  If the tunnel egress is the next-next-hop,
   then protection of multi-homed prefixes and node-failure for ABRs is
   not available.  Selection of the tunnel
   egress is a router-local decision.

   There are three options available for marking IP packets with which
   MRT it should be forwarded in.  For greatest hardware compatibility
   and ease in removing the MRT-topology marking at area/level
   boundaries, routers that support MPLS and implement IP MRT fast-
   reroute MUST support Option A - using an LDP label that indicates the
   destination and MT-ID.

   1.  Tunnel IP packets via an LDP LSP.  This has the advantage that
       more installed routers can do line-rate encapsulation and
       decapsulation.  Also, no additional IP addresses would need to be
       allocated or signaled.

       A.

       a.  Option A - LDP Destination-Topology Label: Use a label that
           indicates both destination and MRT.  This method allows easy
           tunneling to the next-next-hop as well as to the IGP-area
           destination.  For a proxy-node, the destination to use is the
           non-proxy-node immediately before the proxy-node on that
           particular color MRT.

       B.

       b.  Option B - LDP Topology Label: Use a Topology-Identifier
           label on top of the IP packet.  This is very simple.  If
           tunneling to a next-next-hop is desired, then a two-deep
           label stack can be used with [ Topology-ID label, Next-Next-
           Hop Label ].

   2.  Tunnel IP packets in IP.  Each router supporting this option
       would announce two additional loopback addresses and their
       associated MRT color.  Those addresses are used as destination
       addresses for MRT-blue and MRT-red IP tunnels respectively.  They
       allow the transit nodes to identify the traffic as being
       forwarded along either MRT-blue or MRT-red tree topology to reach
       the tunnel destination.  Announcements of these two additional
       loopback addresses per router with their MRT color requires IGP
       extensions.

   For greatest hardware compatibility and ease in removing the MRT-
   topology marking at area/level boundaries, routers that support MPLS
   and implement IP MRT fast-reroute SHOULD support Option A - using an
   LDP label that indicates the destination and MT-ID.

   For proxy-nodes associated with one or more multi-homed prefixes,
   there is no router associated with the proxy-node, so its loopbacks
   can't be known or used.  Instead, the loopback addresses of the
   routers that are attached to the proxy-node can be used.  One of
   those routers will be on the Red MRT and the other on the Blue MRT.
   The MRT-red loopback of the first router would be used to reach the
   router on the Red MRT and similarly the MRT-blue loopback of the
   second router would be used.  The routers connected to the proxy-node
   are topology to reach
       the end tunnel destination.  Announcements of the area/level and can decapsulate the traffic and
   properly forward it into the next area.

6. these two additional
       loopback addresses per router with their MRT color requires IGP
       extensions.

7.  Protocol Extensions and Considerations: OSPF and ISIS

   There are two possible approaches to what additional information to
   distribute in

   For simplicity, the IGP. approach of defining a well-known profile is
   taken in [I-D.atlas-ospf-mrt].  The first purpose of communicating support
   for MRT in the IGP is to allow full flexibility in all
   information and distribute whichever values indicate thatqq the MRT-Blue and combinations MRT-Red
   forwarding topologies are
   desired.  The second is created for transit traffic.  This section
   describes the various options to simply distribute flags indicating a
   particular well-known be selected.  The default MRT
   profile is supported.  Thus described here and the signaling extensions for OSPF are
   given in [I-D.atlas-ospf-mrt].

   For any MRT profile, the MRT Island
   Creation process is trivial.  The profile approach is recommended,
   with created by starting from the added flexibility of being able
   computing router.  If the computing router supports the default MRT
   profile, add it to specify more specific
   information if necessary and supported.

   For example, the MRT Island.  Add a simple router to the MRT Island if
   the router supports the default MRT profile "metric-insensitive and is connected to the
   MRT unicast fast-
   reroute Island via LDP" could specify: bidirectional links eligible for MRT.

   If a router advertises support for multiple MRT Island Creation:   Only include other routers advertising this
      profile. profiles, then it
   MUST create the transit forwarding topologies for each of those,
   unless the profile specifies No Forwarding Mechanism (e.g. as might
   be done for a profile used only for multicast global protection).  A
   router MUST NOT advertise multiple MRT Algorithm ID: profiles that overlap in their
   MRT-Red MT-ID or MRT-Blue MT-ID.

   The MRT Profile also defines different behaviors such as how MRT
   recomputation is handled and how area/level boundaries are dealt
   with.

   MRT Algorithm:   MRT Lowpoint algorithm defined in
      [I-D.enyedi-rtgwg-mrt-frr-algorithm].

   Red MRT

   MRT-Red MT-ID:   The Red MRT MT-ID is the single well-known   experimental 3997, final value
      allocated assigned by IANA
      allocated from the OSPF, ISIS, LDP and PIM MT-ID spaces.

   Blue MRT space

   MRT-Blue MT-ID:   The Blue MRT MT-ID is the single well-known   experimental 3998, final value
      allocated assigned by IANA
      allocated from the OSPF, ISIS, LDP and PIM MT-ID spaces. space

   GADAG Root Election Selection Priority:   Pick   Among the router routers in the MRT Island
      and with the lowest highest priority advertised, an implementation MUST
      pick the router with the highest Router ID to be the GADAG root.

   Forwarding Mechanisms for IP:   Use IP-in-LDP.

   MRT Capabilities:   Computes MRTs, IP Fast-Reroute, Mechanisms:   LDP Fast-Reroute

   Recalculation:   Recalculation of MRTs SHOULD occur as described in
      Section 11.2.  This allows the MRT forwarding topologies to
      support IP/LDP fast-reroute traffic.

   Area/Level Border Behavior:   As described in Section 9, ABRs/LBRs
      SHOULD ensure that traffic leaving the area also exits the MRT-Red
      or MRT-Blue forwarding topology.

   The following captures an initial understanding of describes the aspects that
   must to be considered to fully form define a
   profile to advertise.  For some profiles, associated information may
   need to be distributed, such as GADAG Root Election Selection Priority, Red
   MRT Loopback Address, Blue MRT Loopback Address, or MRT Algorithm ID.

   MRT Island Creation ID:   This identifies the process that the router
      uses to form an MRT Island.  By advertising an ID for the process,
      it is possible to have different processes in the future.  It may
      be desirable to advertise a list ordered by preference to allow
      transitions. Address.

   MRT Algorithm ID: Algorithm:   This identifies the particular MRT algorithm used by
      the router.  By having an router for this profile.  Algorithm ID, it is possible to
      change the algorithm used or use different ones in different
      networks.  It may transitions can be desirable to advertise a list ordered managed
      by
      preference to allow transitions.

   Red advertising multiple MRT profiles.

   MRT-Red MT-ID:   This specifies the MT-ID to be associated with the
      Red MRT
      MRT-Red forwarding topology.  It is needed for use in LDP
      signaling.  All routers in the MRT Island MUST agree on a value.

   Blue MRT

   MRT-Blue MT-ID:   This specifies the MT-ID to be associated with the
      Blue MRT
      MRT-Blue forwarding topology.  It is needed for use in LDP
      signaling.  All routers in the MRT Island MUST agree on a value.

   GADAG Root Election Selection Priority:   This specifies the priority of the
      router for being used as the GADAG root of its island.   A MRT profile might specify this to
      provide the network operator with a knob to force a particular
      GADAG root is elected from selection.  If not specified in the set of routers with MRT profile, the
      highest priority;
      ties are broken based upon highest Router ID.  The sensitivity of ID in the profile's MRT Island will be elected the
      GADAG Root.  If a GADAG Root Selection Priority is specified, then
      the MRT Algorithms to GADAG root selection is still being
      evaluated.  This provides profile must also specify how the network operator with a knob to
      force particular GADAG root selection. Root is elected.

   Forwarding Mechanism for IP: Mechanism:   This specifies which forwarding mechanisms
      the router supports for IP transit traffic.  An MRT island must
      support a common set of forwarding mechanisms, which may be less
      than
      program appropriate next-hops into the full set advertised.  Multiple forwarding mechanisms may plane.  The
      known options are IPv4, IPv6, LDP, and None.  If IPv4 is
      supported, then both MRT-Red and MRT-Blue IPv4 Loopback Addresses
      SHOULD be specified, such as IP-in-IPv4, IP-in-IPv6 or IP-in-LDP Label.
      None specified.  If IPv6 is also an option.

   Red MRT supported, both MRT-Red and MRT-
      Blue IPv6 Loopback Addresses SHOULD be specified.  If LDP is
      supported, then LDP support and signaling extensions MUST be
      supported.

   MRT-Red Loopback Address:   This provides the router's loopback
      address to reach the router via the Red MRT MRT-Red forwarding topology.
      It can, of course, be specified for both IPv4 and IPv6.

   Blue MRT

   MRT-Blue Loopback Address:   This provides the router's loopback
      address to reach the router via the Blue MRT MRT-Blue forwarding topology.
      It can, of course, be specified for both IPv4 and IPv6.

   MRT Capabilities Available:   This is the set of capabilities that
      the router is configured to support.

   MRT Capabilities Required:   This is the set

   Recalculation:   As part of capabilities that
      other routers must have available to be added into the MRT island.

   MRT Capability: Computes MRTs:   The router can compute MRTs.

   MRT Capability: IP Fast-Reroute:   The router can use the computed
      MRTs for IP fast-reroute.

   MRT Capability: LDP Fast-Reroute:   The router can use the computed
      MRTs for LDP fast-reroute.

   MRT Capability: PIM Fast-Reroute:   The router can use the computed
      MRTs for PIM fast-reroute.

   MRT Capability: mLDP Fast-Reroute:   The router can use the computed
      MRTs for mLDP fast-reroute.

   MRT Capability: PIM Global Protection:   The router can use what process and timing should the
      computed new
      MRTs for PIM Global Protection 1+1.

   MRT Capability: mLDP Global Protection:   The router can use the be computed MRTs for mLDP Global Protection 1+1.

   The assumption is that on a router will form an MRT island, compute MRTs
   within that island, and then use those MRTs for the purposes
   specified in the profile.  If multiple profiles are supported with
   different purposes (e.g. mLDP Global Protection), then modified topology?  Section 11.2 describes
      the router may
   use a different profile and associated MRT island minimum behavior required to support fast-reroute.

   Area/Level Border Behavior:   Should inter-area traffic on the MRT-
      Blue or MRT-Red be used for put back onto the
   purposes shortest path tree?  Should
      it be swapped from MRT-Blue or MRT-Red in that different profile.  If a router wanted one area/level to form
   multiple MRT islands MRT-
      Red or MRT-Blue in the next area/level to avoid the potential
      failure of an ABR?  (See [I-D.atlas-rtgwg-mrt-mc-arch] for different application purposes, that could use-
      case details.

   Other Profile-Specific Behavior:   Depending upon the use-case for
      the profile, there may be done by specifying different Red MRT MT-ID and Blue MRT MT-IDs. additional profile-specific behavior.

   As with LFA, it is expected that OSPF Virtual Links will not be
   supported.

7.

8.  Protocol Extensions and considerations: LDP

   Capability negotiation in
   The protocol extensions for LDP is needed to are defined in
   [I-D.atlas-mpls-ldp-mrt].  A router must indicate that it has the
   ability to support for MRT; having this explicit allows the use of MRT-specific signaling
   extensions. MRT-
   specific processing, such as special handling of FECs sent with the
   Rainbow MRT MT-ID.

   A router also FEC sent with the Rainbow MRT MT-ID indicates that the FEC applies
   to all the MRT-Blue and MRT-Red MT-IDs in supported MRT profiles as
   well as to the default shortest-path based MT-ID 0.  The Rainbow MRT
   MT-ID is defined to provide an easy way to handle the special
   signaling that is needed at ABRs or LBRs.  It avoids the problem of
   needing to signal different MPLS labels for the same FEC.  Because
   the Rainbow MRT MT-ID is used only by ABRs/LBRs or the LDP egress, it
   is not MRT profile specific.  The proposed experimental value is 3999
   and the final value will be assigned by IANA and allocated from the
   LDP MT-ID space.  The authoritative values are given in
   [I-D.atlas-mpls-ldp-mrt].

9.  Inter-Area and ABR Forwarding Behavior

   An ABR/LBR has two forwarding roles.  First, it forwards traffic
   inside its area.  Second, it forwards traffic from one area into
   another.  These same two roles apply for MRT transit traffic.
   Traffic on MRT-Red or MRT-Blue destined inside the area needs to indicate, via FEC advertisement,
   whether it supports LDP Destination-Topology Labels, LDP Topology
   Labels, stay
   on MRT-Red or MRT-Blue in that area.  However, it is desirable for
   traffic leaving the area to also exit MRT-Red or both.  Since MRT-Blue back to the label or labels are swapped
   shortest-path forwarding.

   For unicast MRT-FRR, the need to stay on an MRT forwarding topology
   terminates at each LSR,
   consistency across the network ABR/LBR whose best route is not required.

   If both mechanisms are supported, then if via a Destination-Topology
   label different area/
   level.  It is provided for a FEC, that should be used so that highly desirable to go back to the default forwarding
   topology when leaving an ABR/LBR
   can indicate area/level.  There are three basic reasons
   for this.  First, the appropriate labels, as discussed in Section
   Section 9.

8.  Multi-homed Prefixes

   One advantage of LFAs that is necessary to preserve is default topology uses shortest paths; the ability
   packet will thus take the shortest possible route to
   protect multi-homed prefixes against ABR failure.  For instance, if a
   prefix from the backbone is available via both ABR A destination.
   Second, this allows failures that might appear in multiple areas
   (e.g. ABR/LBR failures) to be separately identified and ABR B, if A
   fails, then repaired
   around.  Third, the traffic should be redirected to B. This packet can also be
   done for backups via MRT.

   This generalizes fast-rerouted again, if necessary,
   due to any multi-homed prefix.  A multi-homed prefix
   could be:

   o  An out-of-area prefix announced by more than one ABR,

   o a failure in a different area.

   An AS-External ABR/LBR that receives a packet on MRT-Red or MRT-Blue towards a
   destination in another area/level should forward the packet in the
   area/level with the best route announced by 2 along MRT-Red or MRT-Blue.  If the
   packet came from that area/level, this correctly avoids the failure.
   However, if the traffic came from a different area/level, the packet
   should be removed from MRT-Red or more ASBRs,

   o  A prefix with iBGP multipath MRT-Blue and forwarded on the
   shortest-path default forwarding topology.

   To avoid per-interface forwarding state for MRT-Red and MRT-Blue, the
   ABR/LBR needs to arrange that packets destined to a different ASBRs,

   o  etc. area
   arrive at the ABR/LBR already not marked as MRT-Red or MRT-Blue.

   For each prefix, LDP forwarding where the attached ABRs are selected and a proxy-node MPLS label specifies (MT-ID, FEC), the
   ABR/LBR is
   created connected to those ABRs.  If there exist multiple multi-homed
   prefixes that share responsible for advertising the same connectivity and costs proper label to each of those
   ABRs, then
   neighbor.  Assume that an ABR/LBR has allocated three labels for a single proxy-node can be used to represent the set.  An
   example of this is shown in Figure 3.

                    2    2                     2     2
                  A----B----C                A----B----C
                2 |         | 2            2 |         | 2
                  |         |                |         |
                [ABR1]    [ABR2]           [ABR1]    [ABR2]
                  |         |                |         |
                 p,10      p,15           10 |---[P]---| 15

                (a) Initial topology         (b)with proxy-node

                A<---B<---C                 A--->B--->C
                |         ^                 ^         |
                V         |                 |         V
              [ABR1]    [ABR2]            [ABR1]    [ABR2]
                |                                     |
                |-->[P]                         [P]<--|

                (c) Blue MRT                (d) Red MRT

              Figure 3: Prefixes Advertised by Multiple ABRs

   The proxy-nodes and associated links
   particular destination; those labels are added L_primary, L_blue, and
   L_red.  When the ABR/LBR advertises label bindings to routers in the network
   topology after all real links have been assigned
   area with the best route to a direction the destination, the ABR/LBR provides
   L_primary for the default topology, L_blue for the MRT-Blue MT-ID and
   before
   L_red for the actual MRTs are computed.  Proxy-nodes cannot be transited MRT-Red MT-ID, exactly as expected.  However, when computing the MRTs.  In addition to computing the pair of MRTs
   associated with each router destination D
   ABR/LBR advertises label bindings to routers in other areas, the area, a pair of MRTs
   can be computed ABR/
   LBR advertises L_primary for each such proxy-node to fully protect against ABR
   failure.

   Each ABR or attaching router must remove the Rainbow MRT marking[see
   Section 5] and MT-ID, which is then forward
   used for the traffic outside of default topology, for the area (or
   island of MRT-fast-reroute-supporting routers).

   If ASBR protection is desired, this has additonal complexities if MRT-Blue MT-ID and for the
   ASBRs are in different areas.  Similarly, protecting labeled BGP
   traffic in
   MRT-Red MT-ID.

   The ABR/LBR installs all next-hops from the event of an ASBR failure has additional complexities
   due best area: primary next-
   hops for L_primary, MRT-Blue next-hops for L_blue, and MRT-Red next-
   hops for L_red.  Because the ABR/LBR advertised (Rainbow MRT MT-ID,
   FEC) with L_primary to neighbors not in the per-ASBR label spaces involved.

9.  Inter-Area and ABR Forwarding Behavior

   In regular forwarding, best area, packets destined outside the area from
   those neighbors will arrive at the ABR ABR/LBR with a label L_primary and the ABR forwards them
   will be forwarded into the other best area because along the
   next-hops from default topology.  By
   controlling what labels are advertised, the area with ABR/LBR can thus enforce
   that packets exiting the best route (according to tie-
   breaking rules) are used by area do so on the ABR.  The question shortest-path default
   topology.

   If IP forwarding is used, then what to do
   with packets marked with an MRT that are received by the ABR.

   For unicast fast-reroute, ABR/LBR behavior is dependent upon
   the need to stay on outermost IP address.  If the outermost IP address is an MRT forwarding
   topology terminates at
   loopback address of the ABR/LBR whose best route is via a
   different area/level.  It ABR/LBR, then the packet is highly desirable to decapsulated and
   forwarded based upon the inner IP address, which should go back to on the
   default forwarding topology when leaving SPT topology.  If the outermost IP address is not an area/level.  There are
   three basic reasons for this.  First, MRT
   loopback address of the default topology uses
   shortest paths; ABR/LBR, then the packet is simply forwarded
   along the associated forwarding topology.  A PLR sending traffic to a
   destination outside its local area/level will thus take pick the shortest possible route MRT and use
   the associated MRT loopback address of the selected ABR/LBR connected
   to the external destination.  Second, this allows failures that might appear

   Thus, regardless of which of these two forwarding mechanisms are
   used, there is no need for additional computation or per-area
   forwarding state.

       +----[C]----     --[D]--[E]                --[D]--[E]
       |           \   /         \               /         \
   p--[A] Area 10 [ABR1]  Area 0 [H]--p   +-[ABR1]  Area 0 [H]-+
       |           /   \         /        |      \         /   |
       +----[B]----     --[F]--[G]        |       --[F]--[G]   |
                                          |                    |
                                          | other              |
                                          +----------[p]-------+
                                            area

         (a) Example topology        (b) Proxy node view in multiple areas (e.g.  ABR/LBR failures) to be separately
   identified Area 0 nodes

                   +----[C]<---       [D]->[E]
                   V           \             \
                +-[A] Area 10 [ABR1]  Area 0 [H]-+
                |  ^           /             /   |
                |  +----[B]<---       [F]->[G]   V
                |                                |
                +------------->[p]<--------------+

                  (c) rSPT towards destination p

             ->[D]->[E]                         -<[D]<-[E]
            /          \                       /         \
       [ABR1]  Area 0 [H]-+             +-[ABR1]         [H]
                      /   |             |      \
               [F]->[G]   V             V       -<[F]<-[G]
                          |             |
                          |             |
                [p]<------+             +--------->[p]

     (d) Blue MRT in Area 0           (e) Red MRT in Area 0

                Figure 3: ABR Forwarding Behavior and repaired around.  Third, the packet can be fast-
   rerouted again, if necessary, due to a failure MRTs

   The other forwarding mechanism described in a different area.

   An ABR/LBR Section 6 is using
   Topology-Identification Labels.  This mechanism would require that receives a packet marked with
   any router whose MRT-Red or MRT-Blue next-hop is an MRT towards a
   destination in another area/level should ABR/LBR would
   need to determine whether the ABR/LBR would forward the MRT marked packet in the area/level with out of
   the best route along its associated
   MRT. area/level.  If the packet came from that area/level, this correctly avoids
   the failure.

   How does an ABR/LBR ensure so, then that MRT-marked packets do not arrive at
   the ABR/LBR?  There are two different mechanisms depending upon the
   forwarding mechanism being used.

   If router should pop off the LDP topology-
   identification label encodes the MT-ID as well as before forwarding the destination, then packet to the ABR/LBR is responsible for advertising a particular label ABR/LBR.

   For example, in Figure 3, if node H fails, node E has to each
   neighbor.  Additionally, an LDP label put traffic
   towards prefix p onto MRT-Red.  But since node D knows that ABR1 will
   use a best from another area, it is associated with an MT-ID due safe for D to pop the MT FEC that was used Topology-
   Identification Label and not due just forward the packet to any intrisic particular
   value for ABR1 along the label.  Assume that an ABR/LBR has allocated three
   labels for a particular destination; those labels are L_primary,
   L_blue, and L_red.  When
   MRT-Red next-hop.  ABR1 will use the ABR/LBR advertises label bindings to
   routers shortest path in Area 10.

   In all cases for ISIS and most cases for OSPF, the area with penultimate router
   can determine what decision the best route adjacent ABR will make.  The one case
   where it can't be determined is when two ASBRs are in different non-
   backbone areas attached to the destination, same ABR, then the ABR/
   LBR provides L_primary ASBR's Area ID may
   be needed for tie-breaking (prefer the default topology, L_blue for route with the Blue
   MRT MT-ID largest OPSF
   area ID) and L_red for the Red MRT MT-ID, exactly Area ID isn't announced as expected.
   However, when part of the ABR/LBR advertises label bindings to routers in
   other areas, ASBR link-
   state advertisement (LSA).  In this one case, suboptimal forwarding
   along the ABR/LBR advertises L_primary for MRT in the default
   topology, for other area would happen.  If that becomes a
   realistic deployment scenario, OSPF extensions could be considered.
   This is not covered in [I-D.atlas-ospf-mrt].

10.  Prefixes Multiply Attached to the Blue MRT MT-ID, and Island

   How a computing router S determines its local MRT Island for the Red each
   supported MRT MT-ID. profile is already discussed in Section 7.

   There are two types of prefixes or FECs that may be multiply attached
   to an MRT Island.  The
   ABR/LBR installs next-hops from first type are multi-homed prefixes that
   usually connect at a domain or protocol boundary.  The second type
   represent routers that do not support the best area profile for L_primary based on the default topology, for L_blue based on MRT Island.
   The key difference is whether the traffic, once out of the Blue MRT forwarding
   topology,
   Island, remains in the same area/level and for L_red based on might reenter the Red MRT forwarding topology.
   Therefore, packets from the non-best area will arrive at
   Island if a loop-free exit point is not selected.

   One property of LFAs that is necessary to preserve is the ABR/LBR
   with ability to
   protect multi-homed prefixes against ABR failure.  For instance, if a label L_primary
   prefix from the backbone is available via both ABR A and will ABR B, if A
   fails, then the traffic should be redirected to B. This can also be forwarded into the best area along
   done for backups via MRT.

   If ASBR protection is desired, this has additonal complexities if the default topology.  By controlling what labels
   ASBRs are advertised, the
   ABR/LBR can thus enforce that packets exiting in different areas.  Similarly, protecting labeled BGP
   traffic in the area do so on event of an ASBR failure has additional complexities
   due to the
   shortest-path default topology.

   If IP-in-IP forwarding per-ASBR label spaces involved.

   As discussed in [RFC5286], a multi-homed prefix could be:

   o  An out-of-area prefix announced by more than one ABR,

   o  An AS-External route announced by 2 or more ASBRs,

   o  A prefix with iBGP multipath to different ASBRs,

   o  etc.

   There are also two different approaches to protection.  The first is used, then the ABR/LBR behavior
   to do endpoint selection to pick a router to tunnel to where that
   router is
   dependent upon loop-free with respect to the outermost IP address.  If failure-point.  Conceptually,
   the outermost IP address
   is set of candidate routers to provide LFAs expands to all routers,
   with an MRT loopback address of the ABR/LBR, then alternate, attached to the packet prefix.

   The second is
   decapsulated to use a proxy-node, that can be named via MPLS label
   or IP address, and forwarded based upon pick the inner appropriate label or IP address, which
   should go address to reach
   it on either MRT-Blue or MRT-Red as appropriate to avoid the default SPT topology.  If failure
   point.  A proxy-node can represent a destination prefix that can be
   attached to the outermost IP address MRT Island via at least two routers.  It is termed a
   named proxy-node if there is a way that traffic can be encapsulated
   to reach specifically that proxy-node; this could be because there is not
   an MRT loopback address of LDP FEC for the ABR/LBR, then associated prefix or because MRT-Red and MRT-Blue
   IP addresses are advertised in an as-yet undefined fashion for that
   proxy-node.  Traffic to a named proxy-node may take a different path
   than traffic to the packet attaching router; traffic is
   simply also explicitly
   forwarded along from the associated forwarding topology.  A PLR
   sending traffic to attaching router along a destination outside its local area/level will
   pick predetermined interface
   towards the MRT and relevant prefixes.

   For IP traffic, multi-homed prefixes can use the associated MRT loopback address of the ABR/
   LBR immediately before the proxy-node on endpoint selection.  For
   IP traffic that MRT.

   Thus, regardless of which of these two forwarding mechanisms are
   used, there is no need for additional computation or per-area
   forwarding state.

       +----[C]----     --[D]--[E]                --[D]--[E]
       |           \   /         \               /         \
   p--[A] Area 10 [ABR1]  Area 0 [H]--p   +-[ABR1]  Area 0 [H]-+
       |           /   \         /        |      \         /   |
       +----[B]----     --[F]--[G]        |       --[F]--[G]   |
                                          |                    |
                                          | other              |
                                          +----------[p]-------+
                                            area

         (a) Example topology        (b) Proxy node view in Area 0 nodes

                   +----[C]<---       [D]->[E]
                   V           \             \
                +-[A] Area 10 [ABR1]  Area 0 [H]-+
                |  ^           /             /   |
                |  +----[B]<---       [F]->[G]   V
                |                                |
                +------------->[p]<--------------+

                  (c) rSPT towards destination p

             ->[D]->[E]                         -<[D]<-[E]
            /          \                       /         \
       [ABR1]  Area 0 [H]-+             +-[ABR1]         [H]
                      /   |             |      \
               [F]->[G]   V             V       -<[F]<-[G]
                          |             |
                          |             |
                [p]<------+             +--------->[p]

     (d) Blue MRT in Area 0           (e) Red MRT in Area 0

                Figure 4: ABR Forwarding Behavior and MRTs

   The other potential forwarding mechanisms require additional
   computation by destined to a router outside the penultimate MRT Island, if
   that router along is the egress for a FEC advertised into the in-local-area MRT
   immediately before Island,
   then the ABR/LBR named proxy-node approach can be used.

   For LDP traffic, there is reached. always a FEC advertised into the MRT
   Island.  The penultimate named proxy-node approach should be used, unless the
   computing router
   can determine that S knows the ABR/LBR will forward label for the packet out of area/
   level and, FEC at the selected
   endpoint.

   If a FEC is advertised from outside the MRT Island into the MRT
   Island and the forwarding mechanism specified in the profile includes
   LDP, then the routers learning that case, FEC MUST also advertise labels
   for (MRT-Red, FEC) and (MRT-Blue, FEC) to neighbors inside the penultimate MRT
   Island.  If the forwarding mechanism includes LDP, any router can remove
   receiving a FEC corresponding to a router outside the MRT
   marking but still forward Island or
   to a multi-homed prefix MUST compute and install the packet along transit MRT-Blue
   and MRT-Red next-hops for that FEC; the associated FECs ( (MT-ID 0,
   FEC), (MRT-Red, FEC), and (MRT-Blue, FEC)) MUST also be provided via
   LDP to neighbors inside the MRT Island.

10.1.  Endpoint Selection

   Endpoint Selection is a local matter for a router in the MRT Island
   since it pertains to selecting and using an alternate and does not
   affect the transit MRT-Red and MRT-Blue forwarding topologies.

   Let the computing router be S and the next-hop F be the node whose
   failure is to be avoided.  Let the destination be prefix p.  Have A
   be the router to which the prefix p is attached for S's shortest path
   to p.

   The candidates for endpoint selection are those to which the
   destination prefix is attached in the area/level.  For a particular
   candidate B, it is necessary to determine if B is loop-free to reach
   p with respect to S and F for node-protection or at least with
   respect to reach S and the ABR.  For instance, in Figure 4, if node H fails, node E has link (S, F) for link-protection.  If B will
   always prefer to
   put send traffic towards prefix to p onto the red MRT.  But since node D
   knows that ABR1 will use via a best different area/level, then
   this is definitional.  Otherwise, distance-based computations are
   necessary and an SPF from another area, it B's perspective may be necessary.  The
   following equations give the checks needed; the rationale is safe similar
   to that given in [RFC5286].

   Loop-Free for D S: D_opt(B, p) < D_opt(B, S) + D_opt(S, p)

   Loop-Free for F: D_opt(B, p) < D_opt(B, F) + D_opt(F, p)

   The latter is equivalent to remove the MRT marking and just send following, which avoids the packet need to ABR1 still on
   the red MRT but unmarked.  ABR1 will use
   compute the shortest path in Area
   10.

   In all cases from F to p.

   Loop-Free for ISIS and most cases F: D_opt(B, p) < D_opt(B, F) + D_opt(S, p) - D_opt(S,
   F)

   Finally, the rules for OSPF, Endpoint selection are given below.  The basic
   idea is to repair to the penultimate prefix-advertising router
   can determine what decision selected for the adjacent ABR will make.  The one case
   where it can't be determined is when two ASBRs are in
   shortest-path and only to select and tunnel to a different non-
   backbone areas attached endpoint
   if necessary (e.g. A=F or F is a cut-vertex or the link (S,F) is a
   cut-link).

   1.  Does S have a node-protecting alternate to A?  If so, select
       that.  Tunnel the same ABR, packet to A along that alternate.  For example,
       if LDP is the forwarding mechanism, then push the ASBR's Area ID may
   be needed for tie-breaking (prefer label (MRT-Red,
       A) or (MRT-Blue, A) onto the route packet.

   2.  If not, then is there a router B that is loop-free to reach p
       while avoiding both F and S?  If so, select B as the end-point.
       Determine the MRT alternate to reach B while avoiding F.  Tunnel
       the packet to B along that alternate.  For example, with LDP,
       push the label (MRT-Red, B) or (MRT-Blue, B) onto the largest OPSF
   area ID) packet.

   3.  If not, then does S have a link-protecting alternate to A?  If
       so, select that.

   4.  If not, then is there a router B that is loop-free to reach p
       while avoiding S and the Area ID isn't announced link from S to F?  If so, select B as part of
       the ASBR link-
   state advertisement (LSA).  In this one case, suboptimal forwarding
   along endpoint and the MRT in alternate that for reaching B from S
       avoiding the other area would happen.  If this is a realistic
   deployment scenario, OSPF extensions could be considered.

10.  Issues with Area Abstraction

   MRT fast-reroute provides complete coverage in link (S,F).

   The endpoint selected will receive a area packet destined to itself and,
   being the egress, will pop that MPLS label (or have signaled Implicit
   Null) and forward based on what is
   2-connected.  Where a failure would partition underneath.  This suffices for IP
   traffic where the network, of course,
   no alternate can protect against that failure.  Similarly, there MPLS labels understood by the endpoint router are
   ways of connecting multi-homed prefixes
   not needed.

10.2.  Named Proxy-Nodes

   A clear advantage to using a named proxy-node is that make it impractical to
   protect them without excessive complexity.

           50
         |----[ASBR Y]---[B]---[ABR 2]---[C]      Backbone Area 0:
         |                                |           ABR 1, ABR 2, C, D
         |                                |
         |                                |       Area 20:  A, ASBR X
         |                                |
         p ---[ASBR X]---[A]---[ABR 1]---[D]      Area 10: B, ASBR Y
            5                                  p is possible
   to explicitly forward from the MRT Island along an interface to a Type 1 AS-external

             Figure 5: AS external prefixes in different areas

   Consider
   loop-free island neighbor (LFIN) when that interface may not be a
   primary next-hop.  For LDP traffic where the network in Figure 5 label indicates both the
   topology and assume there the FEC, it is necessary to either use a richer
   connective topology named proxy-
   node or deal with learning remote MPLS labels.

   A named proxy-node represents one or more destinations and, for LDP
   forwarding, has a FEC associated with it that isn't shown, where the same prefix is
   announced by ASBR X and ASBR Y which are in different non-backbone
   areas.  If signaled into the link from A
   MRT Island.  Therefore, it is possible to ASBR X fails, then an explicitly label packets to
   go to (MRT-Red, FEC) or (MRT-Blue, FEC); at the border of the MRT alternate
   could forward
   Island, the packet label will swap to ABR 1 and ABR 1 could forward it meaning (MT-ID 0, FEC).  It would be
   possible to D, have named proxy-nodes for IP forwarding, but then D this would find the shortest route is back via ABR 1
   require extensions to Area
   20.  The only real way signal two IP addresses to get it from be associated with
   MRT-Red and MRT-Blue for the proxy-node.  A named proxy-node can be
   uniquely represented by the two routers in the MRT Island to ASBR Y which it
   is connected.  The extensions to explicitly
   tunnel it signal such IP addresses are not
   defined in [I-D.atlas-ospf-mrt].  The details of what label-bindings
   must be originated are described in [I-D.atlas-mpls-ldp-mrt].

   Computing the MRT next-hops to ASBR Y.

   Tunnelling a named proxy-node and the MRT
   alternate for the computing router S to avoid a particular failure
   node F is extremely straightforward.  The details of the backup ASBR simple
   constant-time functions, Select_Proxy_Node_NHs() and
   Select_Alternates_Proxy_Node(), are given in
   [I-D.enyedi-rtgwg-mrt-frr-algorithm].  A key point is that computing
   these MRT next-hops and alternates can be done as new named proxy-
   nodes are added or removed without requiring a new MRT computation or
   impacting other existing MRT paths.  This maps very well to, for future consideration.  The
   previously proposed PHP approach needs to have an exception if BGP
   policies (e.g.  BGP local preference) determines which ASBR
   example, how OSPFv2 [[RFC2328] Section 16.5] does incremental updates
   for new summary-LSAs.

   The key question is how to use.
   Consider the case in Figure 6.  If the link between A and ASBR X (the
   preferred border router) fails, A can put attach the packets named proxy-node to p onto an
   MRT alternate, even tunnel it towards ASBR Y. Node B, however, must
   not remove the MRT marking
   Island; all the routers in the MRT Island MUST do this case, as nodes consistently.
   No more than 2 routers in Area 0,
   including ASBR Y itself would not know the MRT Island can be selected; one should
   only be selected if there are no others that their preferred ASBR is
   down.

                      Area 20                    BB Area 0
          p ---[ASBR X]-X-[A]---[B]---[ABR 1]---[D]---[ASBR Y]--- p

                      BGP prefers ASBR X for prefix p

          Figure 6: Failure of path towards ASBR preferred by BGP meet the necessary
   criteria.  The fine details of how to solve multi-area external prefix cases, or
   identifying certain cases as too unlikely and too complex to protect named proxy-node is for further consideration.

11.  Partial Deployment and Islands logically part of Compatible the area/level.

   There are two sources for candidate routers in the MRT FRR Island to
   connect to the named proxy-node.  The first set are those routers

   A natural concern with new functionality is how
   that are advertising the prefix; the cost assigned to have it be useful
   when it each such
   router is not deployed across an entire IGP area.  In the case of announced cost to the prefix.  The second set are those
   routers in the MRT FRR, where it provides alternates when appropriate LFAs aren't
   available, there Island that are also deployment scenarios where it may make
   sense connected to only enable some routers not in an area with the
   MRT FRR.  A simple
   example of Island but in the same area/level; such a scenario would be a ring of 6 or more routers that
   is connected via two will be defined
   as Island Border Routers (IBRs).  The routers connected to the rest of IBRs
   that are not in the area.

   First, a computing router S must determine its local island of
   compatible MRT fast-reroute routers.  A router that has a common
   profile flag Island and is connected either are in the same area/level are
   Island Neighbors (INs).

   Since packets sent to S the named proxy-node along MRT-Red or to another MRT-Blue
   may come from any router
   already determined to be in S's local island can be added to S's
   local island.

   Destinations inside the local island can obviously use MRT
   alternates.  Destinations outside Island, it is necessary that
   whatever router to which an IBR forwards the local island can packet be treated
   like a multi-homed prefix loop-free with caveats
   regard to avoid looping.  For LDP
   labels including both destination and topology, the routers at the
   borders of the local island need to originate labels whole MRT Island for the original
   FEC and the associated MRT-specific labels.  Packets sent to destination.  Thus, an LDP
   label marked as blue or red MRT to IBR is
   a destination outside the local
   island will have the last candidate router in only if it possesses at least one IN whose path to
   the local island swap prefix does not enter the label MRT Island.  The cost assigned to one for the destination and forward each
   (IBR, IN) pair is the packet along D_opt(IN, prefix) plus Cost(IBR, IN).

   From the outgoing
   interface on set of prefix-advertising routers and the MRT towards a router outside IBRs, the local island that
   was represented by two
   lowest cost routers are selected and ties are broken based upon the proxy-node.
   lowest Router ID.  For IP in IP encapsulations, remote destinations' loopback addresses
   for ease of discussion, such selected routers are
   proxy-node attachment routers and the MRTs cannot two selected will be used, even if they were available.  Instead,
   the MRT loopback address of named A
   and B.

   A proxy-node attachment router has a special forwarding role.  When a
   packet is received destined to (MRT-Red, prefix) or (MRT-Blue,
   prefix), if the proxy-node attachment router attached is an IBR, it MUST swap
   to a proxy-node,
   which represents destinations outside the local island, can be used.
   Packets sent default topology (e.g. swap to the router's MRT loopback address will have their label for (MT-ID 0, prefix)
   or remove the outer IP header removed encapsulation) and will need forward the packet to be explicitly forwarded
   along the outgoing interface on
   IN whose cost was used in the MRT towards a selection.  If the proxy-node
   attachment router outside is not an IBR, then the
   local island that was represented by packet MUST be removed from
   the proxy-node.  This behavior
   requires essentially remembering MRT forwarding topology and sent along the MT-ID indicated by interface that caused
   the outer IP
   address.  An alternate option would be router to advertise different
   loopback addresses the prefix; this interface might be out of
   the area/level/AS.

10.2.1.  Computing if an Island Neighbor (IN) is loop-free

   As discussed, the Island Neighbor needs to be associated loop-free with regard
   to the proxy-node; whole MRT Island for the outer IP
   address would still destination.  Conceptually, the cost
   of transiting the MRT Island should be removed but it would indicate regarded as 0.  This can be
   done by collapsing the outgoing
   interface MRT Island into a single node, as seen in
   Figure 4, and then computing SPFs from each Island Neighbor and from
   the MRT Island itself.

         [G]---[E]---(V)---(U)---(T)
          | \   |     |           |
          |  \  |     |           |
          |   \ |     |           |
         [H]---[F]---(R)---(S)----|

      (1) Network Graph with Partial Deployment

        [E],[F],[G],[H] :  No support for MRT
        (R),(S),(T),(U),(V):  MRT Island - supports MRT

    [G]---[E]----|                     |---(V)---(U)---(T)
     | \   |     |                     |    |           |
     |  \  |  ( MRT Island )      [ proxy ] |           |
     |   \ |     |                     |    |           |
    [H]---[F]----|                     |---(R)---(S)----|

     (2) Graph for determining    (3) Graph for MRT computation
         loop-free neighbors

   Figure 4: Computing alternates to use and no lookup would be necessary on the internal IP
   address while maintaining MT-ID context.

   A key question is which routers destinations outside the MRT island can packets be
   forwarded Island

   The simple way to so that they are not forwarded back into do this without manipulating the MRT island.
   An example of topology is to
   compute the necessary network graph transformations are given SPFs from each IN and a node in Figure 7.  There are two parts to the computation.  First, MRT Island (e.g. the
   GADAG root), but use a link metric of 0 for all links between routers
   in the MRT
   island Island.  The distances computed via SPF this way will be
   refered to as Dist_mrt0.

   An IN is collapsed into loop-free with respect to a single node; this assumes that destination D if: Dist_mrt0(IN,
   D) < Dist_mrt0(IN, MRT Island Router) + Dist_mrt0(MRT Island Router,
   D).  Any router in the MRT Island can be used since the cost of
   transiting the between MRT island Island routers is nothing and 0.  The GADAG Root is pessimistic but allows
   recommended for simpler computation.  Then, consistency.

10.3.  MRT Alternates for each destination (other than Destinations Outside the MRT island), the routers adjacent Island

   A natural concern with new functionality is how to have it be useful
   when it is not deployed across an entire IGP area.  In the case of
   MRT island FRR, where it provides alternates when appropriate LFAs aren't
   available, there are checked also deployment scenarios where it may make
   sense to
   see if they are loop-free only enable some routers in an area with respect to the MRT island and the
   destination.  The loop-free neighbors FRR.  A simple
   example of the MRT island that are
   closest to the destination are selected.  Then, such a graph scenario would be a ring of just the
   MRT island is augmented with proxy-nodes 6 or more routers that are attached
   is connected via the
   outgoing interfaces two routers to the selected loop-free neighbors.  Finally, rest of the area.

   Destinations inside the MRTs rooted at each proxy-node are computed on that augmented MRT local island graph.  Essentially, the can obviously use MRT
   alternates.  Destinations outside the local island must have can be treated
   like a loop-free
   neighbor to multi-homed prefix and either Endpoint Selection or Named
   Proxy-Nodes can be able to have an alternate.

              [G]---[E]---(B)---(C)---(D)
               | \   |     |           |
               |  \  |     |           |
               |   \ |     |           |
              [H]---[F]---(A)---(S)----|

           (1) Network Graph with Partial Deployment

             [E],[F],[G],[H] :  No support for MRT-FRR
             (A),(B),(C),(D),(S):  MRT Island - supports MRT-FRR

         [G]---[E]----|                     |---(B)---(C)---(D)
          | \   |     |                     |    |           |
          |  \  |  ( MRT Island )      [ proxy ] |           |
          |   \ |     |                     |    |           |
         [H]---[F]----|                     |---(A)---(S)----|

          (2) Graph for determining    (3) Graph used.  Named Proxy-Nodes MUST be supported when
   LDP forwarding is supported and a label-binding for MRT computation
              loop-free neighbors

   Figure 7: Computing alternates to destinations outside the MRT Island destination
   is sent to an IBR.

   Naturally, there are more complicated options to improve coverage,
   such as connecting multiple MRT islands across tunnels, but it is not
   clear that the need
   for the additional complexity is necessary.

12. has not been justified.

11.  Network Convergence and Preparing for the Next Failure

   After a failure, MRT detours ensure that packets reach their intended
   destination while the IGP has not reconverged onto the new topology.
   As link-state updates reach the routers, the IGP process calculates
   the new shortest paths.  Two things need attention: micro-loop
   prevention and MRT re-calculation.

12.1.

11.1.  Micro-forwarding loop prevention and MRTs

   As is well known[RFC5715], micro-loops can occur during IGP
   convergence; such loops can be local to the failure or remote from
   the failure.  Managing micro-loops is an orthogonal issue to having
   alternates for local repair, such as MRT fast-reroute provides.

   There are two possible micro-loop prevention mechanism mechanisms discussed in
   [RFC5715].  The first is Ordered FIB [I-D.ietf-rtgwg-ordered-fib].
   The second is Farside Tunneling which requires tunnels or an
   alternate topology to reach routers on the farside of the failure.

   Since MRTs provide an alternate topology through which traffic can be
   sent and which can be manipulated separately from the SPT, it is
   possible that MRTs could be used to support Farside Tunneling.
   Details of how to do so are outside the scope of this document.

12.2.

   Micro-loop mitigation mechanisms can also work when combined with
   MRT.

11.2.  MRT Recalculation

   When a failure event happens, traffic is put by the PLRs onto the MRT
   topologies.  After that, each router recomputes its shortest path
   tree (SPT) and moves traffic over to that.  Only after all the PLRs
   have switched to using their SPTs and traffic has drained from the
   MRT topologies should each router install the recomputed MRTs into
   the FIBs.

   At each router, therefore, the sequence is as follows:

   1.  Receive failure notification

   2.  Recompute SPT

   3.  Install new SPT

   4.  Recompute MRTs

   5.  Wait  If the network was stable before the failure occured, wait a
       configured (or advertised) period for all routers to be using
       their SPTs and traffic to drain from the MRTs.

   5.  Recompute MRTs

   6.  Install new MRTs.

   While the recomputed MRTs are not installed in the FIB, protection
   coverage is lowered.  Therefore, it is important to recalculate the
   MRTs and install them quickly.

13.

12.  Acknowledgements

   The authors would like to thank Mike Shand for his valuable review
   and contributions.

   The authors would like to thank Joel Halpern, Hannes Gredler, Jeff Tantsura, Ted
   Qian, Kishore Tiruveedhula, Shraddha Hegde, Santosh Esale, Nitin
   Bahadur, Harish
   Sitaraman and Sitaraman, Raveendra Torvi and Chris Bowers for their
   suggestions and review.

14.

13.  IANA Considerations

   This doument includes no request to IANA.

15.

14.  Security Considerations

   This architecture is not currently believed to introduce new security
   concerns.

16.

15.  References

16.1.

15.1.  Normative References

   [I-D.enyedi-rtgwg-mrt-frr-algorithm]
              Atlas, A., Envedi, G., Csaszar, A., and A. Gopalan, A., and C.
              Bowers, "Algorithms for computing Maximally Redundant
              Trees for IP/LDP Fast- Reroute",
              draft-enyedi-rtgwg-mrt-frr-algorithm-02 draft-enyedi-rtgwg-mrt-
              frr-algorithm-03 (work in progress), October 2012. July 2013.

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

   [RFC5714]  Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
              5714, January 2010.

16.2.

15.2.  Informative References

   [EnyediThesis]
              Enyedi, G., "Novel Algorithms for IP Fast Reroute",
              Department of Telecommunications and Media Informatics,
              Budapest University of Technology and Economics Ph.D.
              Thesis, February 2011,
              <http://timon.tmit.bme.hu/theses/thesis_book.pdf>.

   [I-D.atlas-mpls-ldp-mrt]
              Atlas, A., Tiruveedhula, K., Tantsura, J., and IJ.
              Wijnands, "LDP Extensions to Support Maximally Redundant
              Trees", draft-atlas-mpls-ldp-mrt-00 (work in progress),
              July 2013.

   [I-D.atlas-ospf-mrt]
              Atlas, A., Hegde, S., Chris, C., and J. Tantsura, "OSPF
              Extensions to Support Maximally Redundant Trees", draft-
              atlas-ospf-mrt-00 (work in progress), July 2013.

   [I-D.atlas-rtgwg-mrt-mc-arch]
              Atlas, A., Kebler, R., Wijnands, I., Csaszar, A., and G.
              Envedi, "An Architecture for Multicast Protection Using
              Maximally Redundant Trees",
              draft-atlas-rtgwg-mrt-mc-arch-00 draft-atlas-rtgwg-mrt-mc-
              arch-02 (work in progress),
              March 2012. July 2013.

   [I-D.bryant-ipfrr-tunnels]
              Bryant, S., Filsfils, C., Previdi, S., and M. Shand, "IP
              Fast Reroute using tunnels", draft-bryant-ipfrr-tunnels-03
              (work in progress), November 2007.

   [I-D.ietf-mpls-ldp-multi-topology]
              Zhao, Q., Fang, L., Zhou, C., Li, L., and K. Raza, "LDP
              Extensions for Multi Topology Routing",
              draft-ietf-mpls-ldp-multi-topology-06 draft-ietf-mpls-
              ldp-multi-topology-08 (work in progress),
              December 2012. May 2013.

   [I-D.ietf-rtgwg-ipfrr-notvia-addresses]
              Bryant, S., Previdi, S., and M. Shand, "A Framework for IP
              and MPLS Fast Reroute Using Not-via Addresses",
              draft-ietf-rtgwg-ipfrr-notvia-addresses-10 draft-
              ietf-rtgwg-ipfrr-notvia-addresses-11 (work in progress), December 2012.

   [I-D.ietf-rtgwg-lfa-applicability]
              May 2013.

   [I-D.ietf-rtgwg-ordered-fib]
              Shand, M., Bryant, S., Previdi, S., Filsfils, C. C.,
              Francois, P., and O. Bonaventure, "Framework for Loop-free
              convergence using oFIB", draft-ietf-rtgwg-ordered-fib-12
              (work in progress), May 2013.

   [I-D.ietf-rtgwg-remote-lfa]
              Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
              Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-02
              (work in progress), May 2013.

   [I-D.litkowski-rtgwg-node-protect-remote-lfa]
              Litkowski, S., "Node protecting remote LFA", draft-
              litkowski-rtgwg-node-protect-remote-lfa-00 (work in
              progress), April 2013.

   [LFARevisited]
              Retvari, G., Tapolcai, J., Enyedi, G., and A. Csaszar, "IP
              Fast ReRoute: Loop Free Alternates Revisited", Proceedings
              of IEEE INFOCOM , 2011, <http://opti.tmit.bme.hu/~tapolcai
              /papers/retvari2011lfa_infocom.pdf>.

   [LightweightNotVia]
              Enyedi, G., Retvari, G., Szilagyi, P., and A. Csaszar, "IP
              Fast ReRoute: Lightweight Not-Via without Additional
              Addresses", Proceedings of IEEE INFOCOM , 2009,
              <http://mycite.omikk.bme.hu/doc/71691.pdf>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC3137]  Retana, A., Nguyen, L., White, R., Zinin, A., and D.
              McPherson, "OSPF Stub Router Advertisement", RFC 3137,
              June 2001.

   [RFC5443]  Jork, M., Atlas, A., and L. Fang, "LDP IGP
              Synchronization", RFC 5443, March 2009.

   [RFC5715]  Shand, M. and S. Bryant, "A Framework for Loop-Free
              Convergence", RFC 5715, January 2010.

   [RFC6571]  Filsfils, C., Francois, P., Shand, M., Decraene, B.,
              Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
              Alternate (LFA) Applicability in Service Provider (SP)
              Networks", RFC 6571, June 2012.

Appendix A.  General Issues with Area Abstraction

   When a multi-homed prefix is connected in two different areas, it may
   be impractical to protect them without adding the complexity of
   explicit tunneling.  This is also a problem for LFA and Remote-LFA.

          50
        |----[ASBR Y]---[B]---[ABR 2]---[C]      Backbone Area 0:
        |                                |           ABR 1, ABR 2, C, D
        |                                |
        |                                |       Area 20:  A, ASBR X
        |                                |
        p ---[ASBR X]---[A]---[ABR 1]---[D]      Area 10: B, ASBR Y
           5                                  p is a Type 1 AS-external

             Figure 5: AS external prefixes in different areas

   Consider the network in Figure 5 and assume there is a richer
   connective topology that isn't shown, where the same prefix is
   announced by ASBR X and P. Francois, "LFA applicability in SP
              networks", draft-ietf-rtgwg-lfa-applicability-06 (work ASBR Y which are in
              progress), January 2012.

   [I-D.ietf-rtgwg-ordered-fib]
              Shand, M., Bryant, S., Previdi, S., Filsfils, C.,
              Francois, P., different non-backbone
   areas.  If the link from A to ASBR X fails, then an MRT alternate
   could forward the packet to ABR 1 and O. Bonaventure, "Framework for Loop-free
              convergence using oFIB", draft-ietf-rtgwg-ordered-fib-09
              (work ABR 1 could forward it to D,
   but then D would find the shortest route is back via ABR 1 to Area
   20.  This problem occurs because the routers, including the ABR, in progress), January 2013.

   [I-D.ietf-rtgwg-remote-lfa]
              Bryant, S., Filsfils, C., Previdi, S., Shand, M., and S.
              Ning, "Remote LFA FRR", draft-ietf-rtgwg-remote-lfa-01
              (work
   one area are not yet aware of the failure in progress), December 2012.

   [LFARevisited]
              Retvari, G., Tapolcai, J., Enyedi, G., and A. Csaszar, "IP
              Fast ReRoute: Loop Free Alternates Revisited", Proceedings a different area.

   The only way to get it from A to ASBR Y is to explicitly tunnel it to
   ASBR Y.  If the traffic is unlabeled or the appropriate MPLS labels
   are known, then explicit tunneling MAY be used as long as the
   shortest-path of IEEE INFOCOM , 2011, <http://opti.tmit.bme.hu/
              ~tapolcai/papers/retvari2011lfa_infocom.pdf>.

   [LightweightNotVia]
              Enyedi, G., Retvari, G., Szilagyi, P., and A. Csaszar, "IP
              Fast ReRoute: Lightweight Not-Via without Additional
              Addresses", Proceedings the tunnel avoids the failure point.  In that case,
   A must determine that it should use an explicit tunnel instead of IEEE INFOCOM , 2009,
              <http://mycite.omikk.bme.hu/doc/71691.pdf>.

   [RFC5715]  Shand, M. and S. Bryant, "A Framework for Loop-Free
              Convergence", RFC 5715, January 2010. an
   MRT alternate.

Authors' Addresses

   Alia Atlas (editor)
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Email: akatlas@juniper.net

   Robert Kebler
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Email: rkebler@juniper.net
   Gabor Sandor Enyedi
   Ericsson
   Konyves Kalman krt 11.
   Budapest  1097
   Hungary

   Email: Gabor.Sandor.Enyedi@ericsson.com

   Andras Csaszar
   Ericsson
   Konyves Kalman krt 11
   Budapest  1097
   Hungary

   Email: Andras.Csaszar@ericsson.com

   Jeff Tantsura
   Ericsson
   300 Holger Way
   San Jose, CA  95134
   USA

   Email: jeff.tantsura@ericsson.com

   Maciek Konstantynowicz
   Cisco Systems

   Email: maciek@bgp.nu

   Russ White
   Verisign
   12061 Bluemont Way
   Reston, VA  20190
   USA

   Email: riwhite@verisign.com

   Mike Shand
   VCE

   Email: mike@mshand.org.uk russw@riw.us