Routing Area Working Group                                      A. Atlas
Internet-Draft                                                 C. Bowers
Intended status: Standards Track                        Juniper Networks
Expires: June 23, July 13, 2016                                         G. Enyedi
                                                                Ericsson
                                                       December 21, 2015
                                                        January 10, 2016

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

Abstract

   This document defines the architecture for IP/LDP Fast-Reroute using
   Maximally Redundant Trees (MRT-FRR).  MRT-FRR is a technology that
   gives link-protection and node-protection with 100% coverage in any
   network topology that is still connected after the failure.

   MRT removes the need to engineer for coverage.  MRT is also extremely
   computationally efficient.  For any router in the network, the MRT
   computation is less than the LFA computation for a node with three or
   more neighbors.

Status of 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 June 23, July 13, 2016.

Copyright Notice

   Copyright (c) 2015 2016 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Importance of 100% Coverage . . . . . . . . . . . . . . .   5   8
     1.2.  Partial Deployment and Backwards Compatibility  . . . . .   6   9
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   6   9
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   7   9
   4.  Maximally Redundant Trees (MRT) . . . . . . . . . . . . . . .   8  11
   5.  Maximally Redundant Trees (MRT) and Fast-Reroute  . . . . . .  10  12
   6.  Unicast Forwarding with MRT Fast-Reroute  . . . . . . . . . .  11  13
     6.1.  MRT Forwarding Mechanisms . . . . . . . . . . . . . . . .  11  14
       6.1.1.  MRT LDP labels  . . . . . . . . . . . . . . . . . . .  12  14
         6.1.1.1.  Topology-scoped FEC encoded using a single label
                   (Option 1A) . . . . . . . . . . . . . . . . . . .  12  14
         6.1.1.2.  Topology and FEC encoded using a two label stack
                   (Option 1B) . . . . . . . . . . . . . . . . . . .  13  15
         6.1.1.3.  Compatibility of Option 1A and 1B . . . . . . . .  13  15
         6.1.1.4.  Mandatory support for MRT LDP Label option 1A . .  13  15
       6.1.2.  MRT IP tunnels (Options 2A and 2B)  . . . . . . . . .  13  16
     6.2.  Forwarding LDP Unicast Traffic over MRT Paths . . . . . .  14  16
       6.2.1.  Forwarding LDP traffic using MRT LDP Labels (Option
               1A) . . . . . . . . . . . . . . . . . . . . . . . . .  14  17
       6.2.2.  Forwarding LDP traffic using MRT LDP Labels (Option
               1B) . . . . . . . . . . . . . . . . . . . . . . . . .  15  17
       6.2.3.  Other considerations for forwarding LDP traffic using
               MRT LDP Labels  . . . . . . . . . . . . . . . . . . .  15  17
     6.3.  Forwarding IP Unicast Traffic over MRT Paths  . . . . . .  15  18
       6.3.1.  Tunneling IP traffic using MRT LDP Labels . . . . . .  16  18
         6.3.1.1.  Tunneling IP traffic using MRT LDP Labels (Option
                   1A) . . . . . . . . . . . . . . . . . . . . . . .  16  18
         6.3.1.2.  Tunneling IP traffic using MRT LDP Labels (Option
                   1B) . . . . . . . . . . . . . . . . . . . . . . .  16  19
       6.3.2.  Tunneling IP traffic using MRT IP Tunnels . . . . . .  17  19
       6.3.3.  Required support  . . . . . . . . . . . . . . . . . .  17  19
   7.  MRT Island Formation  . . . . . . . . . . . . . . . . . . . .  17  19
     7.1.  IGP Area or Level . . . . . . . . . . . . . . . . . . . .  18  20
     7.2.  Support for a specific MRT profile  . . . . . . . . . . .  18  20
     7.3.  Excluding additional routers and interfaces from the MRT
           Island  . . . . . . . . . . . . . . . . . . . . . . . . .  18  21
       7.3.1.  Existing IGP exclusion mechanisms . . . . . . . . . .  18  21
       7.3.2.  MRT-specific exclusion mechanism  . . . . . . . . . .  19  22
     7.4.  Connectivity  . . . . . . . . . . . . . . . . . . . . . .  19  22
     7.5.  Example algorithm . . . . . . . . . . .  Algorithm for MRT Island Identification . . . . . . . . .  19  22
   8.  MRT Profile . . . . . . . . . . . . . . . . . . . . . . . . .  19  22
     8.1.  MRT Profile Options . . . . . . . . . . . . . . . . . . .  20  22
     8.2.  Router-specific MRT paramaters  . . . . . . . . . . . . .  21  24
     8.3.  Default MRT profile . . . . . . . . . . . . . . . . . . .  21  24
   9.  LDP signaling extensions and considerations . . . . . . . . .  22  25
   10. Inter-area Forwarding Behavior  . . . . . . . . . . . . . . .  23  25
     10.1.  ABR Forwarding Behavior with MRT LDP Label Option 1A . .  23  26
       10.1.1.  Motivation for Creating the Rainbow-FEC  . . . . . .  24  27
     10.2.  ABR Forwarding Behavior with IP Tunneling (option 2) . .  24  27
     10.3.  ABR Forwarding Behavior with LDP Label option 1B . . . .  25  28
   11. Prefixes Multiply Attached to the MRT Island  . . . . . . . .  26  29
     11.1.  Protecting Multi-Homed Prefixes using Tunnel Endpoint
            Selection  . . . . . . . . . . . . . . . . . . . . . . .  28  31
     11.2.  Protecting Multi-Homed Prefixes using Named Proxy-Nodes   29   32
     11.3.  MRT Alternates for Destinations Outside the MRT Island .  31  34
   12. Network Convergence and Preparing for the Next Failure  . . .  31  34
     12.1.  Micro-forwarding loop  Micro-loop prevention and MRTs . . . . . . .  32 . . . . . .  35
     12.2.  MRT Recalculation for the Default MRT Profile  . . . . .  32  36
   13. Implementation Status . . . . . . . . . . . . . . . . . . . .  33  37
   14. Operations and Management Operational Considerations  . . . . . . . . . .  34
   15. Applying Policy to Select from Multiple Possible Alternates
       for FRR . . . . . . .  38
     14.1.  Verifying Forwarding on MRT Paths  . . . . . . . . . . .  38
     14.2.  Traffic Capacity on Backup Paths . . . . . . . . .  35
   16. . . .  39
     14.3.  MRT IP Tunnel Loopback Address Management  . . . . . . .  40
     14.4.  MRT-FRR in a Network with Degraded Connectivity  . . . .  41
     14.5.  Partial Deployment of MRT-FRR in a Network . . . . . . .  41
   15. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  35
   17.  41
   16. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  35
   18.  42
   17. Security Considerations . . . . . . . . . . . . . . . . . . .  36
   19.  42
   18. Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  36
   20.  42
   19. References  . . . . . . . . . . . . . . . . . . . . . . . . .  36
     20.1.  43
     19.1.  Normative References . . . . . . . . . . . . . . . . . .  36
     20.2.  43
     19.2.  Informative References . . . . . . . . . . . . . . . . .  37  44
   Appendix A.  General Issues with Area Abstraction . . . . . . . .  40  46
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  40  47

1.  Introduction

   This document describes a 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 node protection
   for 100% of paths and failures as long as the failure does not cut
   the network into multiple pieces.  This document defines the
   architecture for IP/LDP fast-reroute with MRT.  The associated
   protocol extensions are defined in [I-D.ietf-ospf-mrt] and
   [I-D.ietf-mpls-ldp-mrt].  The exact

   [I-D.ietf-rtgwg-mrt-frr-algorithm] describes how to compute maximally
   redundant trees using a specific algorithm, the MRT Lowpoint
   algorithm.  The MRT Lowpoint algorithm is defined used by a router that
   supports the Default MRT Profile, as specified in
   [I-D.ietf-rtgwg-mrt-frr-algorithm]. this document.

   IP/LDP Fast-Reroute with MRT (MRT-FRR) uses two maximally diverse
   forwarding topologies to provide alternates.  A primary next-hop
   should be on only one of the diverse forwarding topologies; thus, the
   other can be used to provide an alternate.  Once traffic has been
   moved to one of MRTs, it the MRTs by one point of local repair (PLR), that
   traffic is not subject to further repair actions.
   Thus, actions by another PLR, even
   in the event of multiple simultaneous failures.  Therefore, traffic
   repaired by MRT-FRR will not loop even if a worse failure (e.g. node)
   occurs when between different PLRs responding
   to different simultaneous failures.

   While MRT provides 100% protection was only available for a single link or node failure,
   it may not protect traffic in the event of multiple simultaneous
   failures, nor does take into account Shared Risk Link Groups (SRLGs).
   Also, while the MRT Lowpoint algorithm is computationally efficient,
   it is also new.  In order for MRT-FRR to function properly, all of
   the other nodes in the network that support MRT must correctly
   compute next-hops based on the same algorithm, and install the
   corresponding forwarding state.  This is in contrast to other FRR
   methods where the calculation of backup paths generally involves
   repeated application of the simpler failure (e.g.
   link). and widely-deployed SPF
   algorithm, and backup paths themselves re-use the forwarding state
   used for shortest path forwarding of normal traffic.  Section 14
   provides operational guidance related to verification of MRT
   forwarding paths.

   In addition to supporting IP and LDP unicast fast-reroute, the
   diverse forwarding topologies and guarantee of 100% coverage permit
   fast-reroute technology to be applied to multicast traffic as
   described in [I-D.atlas-rtgwg-mrt-mc-arch].

   Other existing or proposed solutions  However, the current
   document does not address the multicast applications of MRTs.

   Figure 1 compares different methods of providing FRR for IP and LDP
   traffic, illustrating some of the trade-offs between the different
   approaches.  For several methods, the methods are partial solutions separated into
   link-protecting (LP) and node-protecting (NP) variants.  The first
   column indicates whether the method provides 100% protection coverage
   (when topologically feasible).  The second column indicates whether
   or have
   significant issues, as described below.

                 Summary Comparison not traffic traversing alternate path can loop when multiple
   failures occur.

   The third column gives an estimate of IP/LDP the amount of computation
   required at each node to support the FRR Methods

   +---------+-------------+-------------+-----------------------------+
   |  Method |   Coverage method, in addition to the
   usual SPF computation rooted at the computing node itself.  This
   metric of comparison is important for implementations that seek to
   quickly recompute repair paths following their initial use after a
   topology change, without reliance on an external system, in order to
   minimize the risk of a new failure occurring before the new repair
   paths are in place.

   The fourth column indicates the maximum number of additional labels
   that need to be applied to packets to support the FRR method, while
   the fifth column gives the size of the MPLS label table needed to
   support the FRR method.  These two metrics may be useful for
   evaluating requirements placed on hardware to support the different
   FRR methods.

   The last column indicates the additional requirements placed on the
   control plane by the FRR method, beyond what is required for IGP
   shortest path forwarding with LDP.

 +---------+-----+------+-------------+-------+-------------+----------+
 |  Alternate Method  |100% | Alt. | Additional  | Max.  | Label table | Control  |
 |         |prot.| can  | computation | addit.|    size     | plane    |
 |         |cov. | loop?| at each     | labels|(relative to | reqs.    |    Computation (in SPFs)
 |         |     |      |   Looping? node        |       | SPF labels) |          |
   +---------+-------------+-------------+-----------------------------+
 +---------+-----+------+-------------+-------+-------------+----------+
 | MRT-FRR |     100% Yes | No   | equivalent  | 0(LDP)|     3x      | MRT-     |
 | LP and  |     None     |      | of less     | 1(IP) |             | specific |
 | NP      |     |      | than 3        |       |             |  Link/Node protocol |
 |         |     |      | 3 SPFs      |       |             | extens.  |
 +---------+-----+------+-------------+-------+-------------+----------+
 | LFA LP  |   Partial No  |   Possible Yes  |  SPF per neighbor    |   0   |     1x      | None     |  Link/Node
 | and NP  |     |      |  neighbor   |       |             |          |
 +---------+-----+------+-------------+-------+-------------+----------+
 | Remote  |   Partial No  |   Possible Yes  |  SPF per neighbor (link) or    |   1   |     1x      | T-LDP    |
 | LFA LP  |  Link/Node     |      |  neighbor's  neighbor (node)   |       |             | session  |
 |         |     | Not-Via      |     100%             |     None       |      per link and node             | for each |
 |  Link/Node         |     |      |             |       |             | selected |
 |         |  TI-LFA     |     100%      |   Possible             |    per neighbor (link) or       |             | PQ node  |  Link/Node
 +---------+-----+------+-------------+-------+-------------+----------+
 | Remote  |  neighbor's neighbor (node) No  | Yes  | SPF per nbr |
   +---------+-------------+-------------+-----------------------------+

                                  Table   1

   Loop-Free Alternates (LFA):   LFAs [RFC5286] provide limited
      topology-dependent coverage for link   |     1x      | T-LDP    |
 | LFA NP  |     |      | and SPF per |       |             | session  |
 |         |     |      | per PQ 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 [RFC7490] 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.ietf-rtgwg-rlfa-node-protection] but not guaranteed coverage
      and the computation required is quite high (an SPF |       |             | for each PQ- |
 |         |     |      | evaluated   |       |             | selected |
 |         |     |      |             |       |             | PQ node evaluated).  [I-D.bryant-ipfrr-tunnels] describes additional
      mechanisms to further improve coverage, at the cost of added
      complexity.

   Not-Via:  |
 +---------+-----+------+-------------+-------+-------------+----------+
 | Not-Via [RFC6981] 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 | Yes | No   | SPF per failure point)     |   1   |  (average   | T-LDP    |
 | LP and academic implementations
      [LightweightNotVia] have found the address management complexity
      to be high.

   TI-LFA:   Topology Independent Loop-free Alternate Fast Re-route (TI-
      LFA) [I-D.francois-rtgwg-segment-routing-ti-lfa] aims to provide  |     |      | link and node protection    |       |  number of  | session  |
 | NP      |     |      | per node and adjacency segments within the
      Segment Routing (SR) framework.  It guarantees complete coverage.
      The TI-LFA computation for link-protection is fairly
      straightforward, while the computation    |       |  neighbors) | for node-protection is more
      complex.  For link-protection with symmetric link costs, each |
 |         |     |      | in topology |       |      x      | nbr's nbr|
 +---------+-----+------+-------------+-------+-------------+----------+
 | TI-LFA
      can provide complete coverage by pushing up to two additional
      labels.  For node protection on arbitrary topologies, the  | Yes | Yes  | SPF per     |   2   |     1x      | uses     |
 | LP with |     |      | neighbor    |       |             | SPRING   |
 | symm.   |     |      |             |       |             | for      |
 | metrics |     |      |             |       |             | label
      stack size can grow significantly based on repair path.  Note that    |
 |         |     |      |             |       |             | dist.    |
 +---------+-----+------+-------------+-------+-------------+----------+
 | TI-LFA requires shortest path forwarding based  | Yes | Yes  | # of SPFs   |depth  |     1x      | uses     |
 | NP or   |     |      | dependent   |depend-|             | SPRING   |
 | LP with |     |      | on SR Node-SIDs, as
      opposed to LDP labels, in order to construct topology |ent on |             | for      |
 | asymm.  |     |      |             |topo.  |             | label stacks    |
 | metrics |     |      |             |       |             | dist.    |
 +---------+-----+------+-------------+-------+-------------+----------+

                Figure 1: Comparison of IP/LDP FRR Methods

   MRT:   MRT provides 100% coverage for
      backups link and node protection, and
      traffic on the alternate paths without relying will not loop.  The computation
      required on a large number of targeted LDP
      sessions each node is equivalent to learn remote FEC-label bindings.  It also less than 3 additional SPFs
      in terms of computational complexity.  For IP traffic, MRT
      requires one additional label, while for LDP traffic, no
      additional labels are needed.  However, the
      use of Adj-SIDs to achieve 100% coverage.

1.1.  Importance size of 100% Coverage

   Fast-reroute is based upon the single failure assumption - that the
   time between single failures MPLS label
      table is long enough three times what would normally be required for a network shortest
      path LDP forwarding, due 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 presence of additional red and
      blue labels for each FEC.  MRT requires protocol extensions in
      order to analyze allow a particular network topology node to advertise support for
   coverage.  However, MRT as well as a real network does not always have
      value for the same
   topology.  For instance, maintenance events will take links or nodes
   out of use.  Simply costing out a GADAG Root Selection Priority.  It also requires
      support for multi-topology LDP extensions.

   Loop-Free Alternates (LFA):   LFAs [RFC5286] provide limited
      topology-dependent coverage for link can have a significant effect and node protection.
      Restrictions on what LFAs are available.  Similarly, after choice of alternates can be relaxed to improve
      coverage, but this can cause forwarding loops if a single worse 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 experienced than protected against.  [RFC6571] discusses the coverage for
   topology-sensitive methods such as
      applicability of 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 different topologies with a focus on
      common aspect of networks.  There
   are at least three common causes for them.  First, any broadcast
   interface PoP architectures.  The computation required is represented by a pseudo-node one SPF per
      neighbor.  LFA imposes no additional labels imposed, has no impact
      on the label table size, and has asymmetric no additional control plane
      requirements.

   Remote LFA:   Remote LFA [RFC7490] improves coverage over LFA for
      both link
   costs to and from that pseudo-node.  Second, when routers come up or
   a link with LDP comes up, node protection, but it is recommended in [RFC5443] and
   [RFC6987] that the link metric be raised to the maximum cost; this
   may does not be symmetric and guarantee 100%
      coverage.  The alternates can also loop with worse than expected
      failures.  Computation for [RFC6987] link protection is not expected to be.  Third,
   techniques such as IGP metric tuning one SPF per
      neighbor, while computation for traffic-engineering node protection requires an
      additional SPF per PQ node [I-D.ietf-rtgwg-rlfa-node-protection].
      Remote LFA 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[RFC6976] or Farside Tunneling[RFC5715],
   then the whole IGP area needs impose up to have alternates available so that one additional label on the micro-loop prevention mechanism, which requires slower network
   convergence, can take packet,
      but does not increase the necessary time without adversely impacting
   traffic.  Without complete coverage, traffic to size of the unprotected
   destinations will be dropped label table.  It requires a
      T-LDP session for significantly longer than with
   current convergence - where routers individually converge as fast as
   possible.

1.2.  Partial Deployment each selected PQ node.

   Not-Via:   Not-Via [RFC6981] provides 100% coverage for link and Backwards Compatibility

   MRT-FRR supports partial deployment.  As node
      failures and does not have potential looping among alternates.
      The computation is high with many new features, an SPF per potential failure point
      (all links and nodes in the
   protocols (OSPF, topology).  When implemented with LDP, ISIS) indicate their capability
      Not-Via adds one additional label to support MRT.
   Inside a tunnelled packet.  It
      significantly increases the MRT-capable connected group size of routers (referred to as an
   MRT Island), the MRTs are computed.  Alternates to destinations
   outside the MRT Island are computed and depend upon label table, multiplying
      it by roughly the existence of
   a loop-free neighbor average number 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 neighbors.  Not-Via also
      requires targeted LDP sessions 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 each neighbor's neighbor.

   TI-LFA:   Topology Independent Loop-free Alternate Fast Re-route (TI-
      LFA) [I-D.francois-rtgwg-segment-routing-ti-lfa] aims to provide
      link and broadcast links have been
      transformed into the standard pseudo-node representation.

   Redundant Trees (RT):   A pair node protection of trees where the path from any node
      X to and adjacency segments within the root R along
      Segment Routing (SR) framework.  It guarantees complete coverage.
      The TI-LFA computation for link-protection is fairly
      straightforward, while the first tree computation for node-protection is node-disjoint more
      complex.  For link-protection with the
      path from the same node X symmetric link costs, TI-LFA
      can provide complete coverage by pushing up to two additional
      labels.  For node protection on arbitrary topologies, the root along the second tree.
      These label
      stack size can be computed in 2-connected graphs.

   Maximally Redundant Trees (MRT):   A pair of trees where the grow significantly based on repair path.  Note that
      TI-LFA requires shortest path
      from any node X forwarding based on SR Node-SIDs, as
      opposed to the root R along the first tree and the path
      from the same node X LDP labels, in order to the root along the second tree share the
      minimum construct label stacks for
      backups paths without relying on a large number of nodes and targeted LDP
      sessions to learn remote FEC-label bindings.  It also requires the minimum number
      use 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 Adj-SIDs to describe one achieve 100% coverage.

1.1.  Importance of 100% Coverage

   Fast-reroute is based upon the two MRTs; it single failure assumption - that the
   time between single failures is
      used long enough for a network to described the associated forwarding topology
   reconverge and MPLS MT-
      ID.  Specifically, MRT-Red is the decreasing MRT where links in start forwarding on the GADAG are taken in new shortest paths.  That does
   not imply that the direction from a higher topologically
      ordered node to a lower one.

   MRT-Blue:   MRT-Blue is used to describe network will only experience one of the two MRTs; it failure or
   change.

   It is
      used straightforward to described the associated forwarding analyze a particular network topology and MPLS MT-
      ID.  Specifically, MRT-Blue is for
   coverage.  However, a real network does not always have the increasing MRT where same
   topology.  For instance, maintenance events will take links in
      the GADAG are taken in the direction from or nodes
   out of use.  Simply costing out a lower topologically
      ordered node to link can have a higher one.

   Rainbow MRT:   It significant effect
   on what LFAs are available.  Similarly, after a single failure has
   happened, the topology is useful to changed and its associated coverage.
   Finally, many networks have an MPLS MT-ID that refers to the
      multiple MRT topologies new routers or links added and to removed;
   each of those changes can have an effect on the default topology.  This is
      referred to coverage for
   topology-sensitive methods such as the Rainbow MRT MPLS MT-ID LFA and Remote LFA.  If fast-
   reroute is used by LDP to
      reduce signaling and permit the same label to always be advertised
      to all peers important for the same (MT-ID, Prefix).

   MRT Island:   The set of routers that support network services provided, then a particular MRT
      profile and the links connecting them that support MRT.

   Island Border Router (IBR):   A router in the MRT Island method
   that guarantees 100% coverage is
      connected important to a router not in the MRT Island and both routers accomodate natural
   network topology changes.

   Asymmetric link costs are
      in also a common area or level.

   Island Neighbor (IN):   A router that is not in the MRT Island but aspect of networks.  There
   are at least three common causes for them.  First, any broadcast
   interface is
      adjacent represented by a pseudo-node and has asymmetric link
   costs to an IBR and from that pseudo-node.  Second, when routers come up or
   a link with LDP comes up, it is recommended in [RFC5443] and
   [RFC6987] that the same area/level as the IBR.

   cut-link:   A link whose removal partitions metric be raised to the network.  A cut-link
      by definition must maximum cost; this
   may not be connected between two cut-vertices.  If
      there are multiple parallel links, then they are referred symmetric and for [RFC6987] is not expected to be.  Third,
   techniques such as
      cut-links IGP metric tuning for traffic-engineering can
   result in this document if removing the set of parallel links
      would partition the network graph.

   cut-vertex: asymmetric link costs.  A vertex whose removal partitions the fast-reroute solution needs to
   handle network graph.

   2-connected:   A graph that has no cut-vertices.  This is topologies with asymmetric link costs.

   When a graph
      that requires two nodes network needs to be removed before use a micro-loop prevention mechanism
   [RFC5715] such as Ordered FIB[RFC6976] or Nearside
   Tunneling[RFC5715], then the network is
      partitioned.

   2-connected cluster:   A maximal set of nodes whole IGP area needs to have alternates
   available so that are 2-connected.

   2-edge-connected:   A the micro-loop prevention mechanism, which requires
   slower network graph where at least two links must be
      removed convergence, can take the necessary time without
   adversely impacting traffic.  Without complete coverage, traffic to partition
   the network.

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

   DAG:   Directed Acyclic Graph unprotected destinations will be dropped for significantly longer
   than with current convergence - a graph where all links are directed routers individually converge
   as fast as possible.  See Section 12.1 for more discussion of micro-
   loop prevention and there are no cycles in it.

   ADAG:   Almost Directed Acyclic Graph - a graph that, if all links
      incoming MRTs.

1.2.  Partial Deployment and Backwards Compatibility

   MRT-FRR supports partial deployment.  Routers advertise their ability
   to support MRT.  Inside the root were removed, would be a DAG.

   GADAG:   Generalized ADAG - a graph that is the combination MRT-capable connected group of routers
   (referred to as an MRT Island), the
      ADAGs of all blocks.

   named proxy-node:   A proxy-node can represent a destination prefix
      that can be attached MRTs are computed.  Alternates to
   destinations outside the MRT Island via at least two routers.
      It is named if there is are computed and depend upon the
   existence of a way that traffic can be encapsulated to
      reach specifically loop-free neighbor of the MRT Island for that proxy node; this could be because there
   destination.  MRT Islands are discussed in detail in Section 7, and
   partial deployment is
      an LDP FEC for the associated prefix or because MRT-Red discussed in more detail in Section 14.5.

2.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and MRT-
      Blue IP addresses "OPTIONAL" in this
   document are advertised to be interpreted as described in an undefined fashion for that
      proxy-node.

4.  Maximally Redundant Trees (MRT) [RFC2119].

3.  Terminology

   network graph:   A pair of Maximally Redundant Trees is a pair of directed spanning
   trees graph that provides maximally disjoint paths towards their common
   root.  Only reflects the network topology where all
      links or connect exactly two nodes and broadcast links have been
      transformed into the standard pseudo-node representation.

   cut-link:   A link whose failure 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
   (i.e. cut-links and cut-vertices) are shared between graph.

   cut-vertex:   A vertex whose removal partitions the trees.  The
   algorithm to compute MRTs is given in
   [I-D.ietf-rtgwg-mrt-frr-algorithm]. network graph.

   2-connected:   A graph that has no cut-vertices.  This algorithm can be computed
   in O(e + n log n); it is less than three SPFs.  Modeling results
   comparing the alternate path lengths obtained with MRT a graph
      that requires two nodes to other
   approaches are described in [I-D.ietf-rtgwg-mrt-frr-algorithm].  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 removed before the MRT-Blue and MRT-Red.

   The most important thing to understand about MRTs network is
      partitioned.

   2-connected cluster:   A maximal set of nodes that for each are 2-connected.

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

   Redundant Trees (RT):   A pair of destination-routed MRTs, there is a trees where the path from every any node
      X to the destination D on root R along the Blue MRT that first tree is as disjoint as possible
   from node-disjoint with the
      path on from the Red MRT.

   For example, same node X to the root along the second tree.
      Redundant trees can always be computed in Figure 1, there is a network graph that is 2-connected in (a) and associated MRTs in (b) 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 (c).  One can
   consider the paths path
      from B the same node X to R; on the Blue MRT, root along the paths are
   B->F->D->E->R or B->C->D->E->R.  On second tree share the Red MRT,
      minimum number of nodes and the path minimum number of links.  Each
      such shared node is B->A->R.
   These a cut-vertex.  Any shared links are clearly link and node-disjoint.  These cut-links.
      In graphs that are not 2-connected, it is not possible to compute
      RTs.  However, it is possible to compute MRTs.  MRTs are maximally
      redundant
   trees because in the paths sense that they 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)                         (c) as redundant as possible
      given the constraints of the network graph.

   DAG:   Directed Acyclic Graph - a 2-connected graph     Blue MRT towards R          Red MRT towards R

                      Figure 1: A 2-connected Network

   By contrast, where all links are directed
      and there are no cycles in Figure 2, it.

   ADAG:   Almost Directed Acyclic Graph - a graph that, if all links
      incoming to the network in (a) root were removed, would be a DAG.

   GADAG:   Generalized ADAG - a graph that is not 2-connected.  If
   F, G or the link F<->G failed, then combination of the network would be partitioned.
   It
      ADAGs of all blocks.

   MRT-Red:   MRT-Red is clearly impossible used to have describe one of the two link-disjoint or node-disjoint
   paths from G, I or J MRTs; it is
      used to R.  The MRTs given in (b) describe the associated forwarding topology and (c) offer paths
   that are as disjoint as possible.  For instance, MPLS
      multi-topology identifier (MT-ID).  Specifically, MRT-Red is the paths from B to
   R are
      decreasing MRT where links in the same as GADAG are taken in Figure 1 and the path direction
      from G a higher topologically ordered node to R on the Blue
   MRT a lower one.

   MRT-Blue:   MRT-Blue is G->F->D->E->R and on used to describe one of the Red MRT two MRTs; it is G->F->B->A->R.

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

                                  (a)
      used to described the associated forwarding topology and MPLS MT-
      ID.  Specifically, MRT-Blue is the increasing MRT where links in
      the GADAG are taken in the direction from a non-2-connected graph

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

                   (b)                                    (c)
            Blue lower topologically
      ordered node to a higher one.

   Rainbow MRT:   It is useful to have an MPLS MT-ID that refers to the
      multiple MRT towards R                    Red forwarding topologies and to the default forwarding
      topology.  This is referred to as the Rainbow MRT towards R

                    Figure 2: A non-2-connected network

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

   In normal IGP routing, each router has its shortest-path-tree
      is used by LDP to reduce signaling and permit the same label to
      always be advertised to all
   destinations.  From peers for the perspective same (MT-ID, Prefix).

   MRT Island:   The set of routers that support a particular destination, D,
   this looks like a reverse SPT (rSPT).  To use maximally redundant
   trees, MRT
      profile and the links connecting them that support MRT.

   Island Border Router (IBR):   A router in addition, each destination D has two MRTs associated with
   it; by convention these will be called the MRT-Blue and MRT-Red.
   MRT-FRR is realized by using multi-topology forwarding.  There MRT Island that is
      connected to a
   MRT-Blue forwarding topology router not in the MRT Island 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 both routers are multi-topology forwarding (used by MRT-FRR),
   tunneling (e.g.  [RFC6981] or [RFC7490]), and per-interface
   forwarding (e.g.  Loop-Free Failure Insensitive Routing
      in
   [EnyediThesis]).

   When there is a link common area or node failure affecting, but level.

   Island Neighbor (IN):   A router that is not partitioning,
   the network, each node will still have at least one path via one of in the MRTs MRT Island but is
      adjacent to reach the destination D.  For example, an IBR and in Figure 2, C
   would normally forward traffic to R across the C<->R link.  If same area/level as the IBR.

   named proxy-node:   A proxy-node can represent a destination prefix
      that
   C<->R link fails, then C could use can be attached to the Blue MRT path C->D->E->R.

   As Island via at least two routers.
      It is always the case with fast-reroute technologies, forwarding does
   not change until a local failure named if there is detected.  Packets are forwarded
   along the shortest path.  The appropriate alternate a way that traffic can be encapsulated to use
      reach specifically that proxy node; this could be because there is pre-
   computed.  [I-D.ietf-rtgwg-mrt-frr-algorithm] describes exactly how
   to determine whether
      an LDP FEC for the MRT-Blue next-hops associated prefix or the because MRT-Red next-hops
   should be the MRT alternate next-hops for a particular primary next-
   hop to a particular destination.

   MRT alternates and MRT-
      Blue IP addresses are always available to use.  It advertised in an undefined fashion for that
      proxy-node.

4.  Maximally Redundant Trees (MRT)

   A pair of Maximally Redundant Trees is a local decision
   whether to use an MRT alternate, a Loop-Free Alternate or some other
   type pair of alternate.

   As described in [RFC5286], when a worse failure than is anticipated
   happens, using LFAs directed spanning
   trees that provides maximally disjoint paths towards their common
   root.  Only links or nodes whose failure would partition the network
   (i.e. cut-links and cut-vertices) are not downstream neighbors shared between the trees.  The
   MRT Lowpoint algorithm is given in
   [I-D.ietf-rtgwg-mrt-frr-algorithm].  This algorithm can cause
   micro-looping.  Section 1.1 of [RFC5286] gives an example of link-
   protecting alternates causing a loop on node failure.  Even if a
   worse failure be computed
   in O(e + n log n); it is less than anticipated happens, three SPFs.  This document
   describes how the use of MRTs can be used and not how to compute them.

   MRT alternates 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 not cause looping.  Therefore, while node-protecting LFAs may be
   preferred, selected between the certainty that no alternate-induced looping will occur MRT-Blue and MRT-Red.

   The most important thing to understand about MRTs is an advantage that for each
   pair of using MRT alternates when the available node-
   protecting LFA destination-routed MRTs, there is not a downstream path.

6.  Unicast Forwarding with MRT Fast-Reroute

   There are three possible types of routers involved in forwarding a
   packet along an MRT path.  At the MRT ingress router, the packet
   leaves the shortest path from every node X to
   the destination and follows an MRT path
   to the destination.  In a FRR application, D on the Blue MRT ingress router that is as disjoint as possible
   from the path on the Red MRT.

   For example, in Figure 2, there is
   the PLR.  An MRT transit router takes a packet network graph that arrives already is
   2-connected in (a) and associated with the particular MRT, MRTs in (b) and forwards it on that same MRT.
   In some situations (to be discussed later), (c).  One can
   consider the packet will need paths from B to
   leave R; on the Blue MRT, the paths are
   B->F->D->E->R or B->C->D->E->R.  On the Red MRT, the MRT path is B->A->R.
   These are clearly link and return to the shortest path.  This takes place
   at 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)                         (c)
   a 2-connected graph     Blue MRT egress router.  The towards R          Red MRT ingress and egress functionality
   may depend on towards R

                      Figure 2: A 2-connected Network

   By contrast, in Figure 3, the underlying type of packet being forwarded (LDP or
   IP).  The MRT transit functionality network in (a) is independent of not 2-connected.  If
   F, G or the type of
   packet being forwarded.  We first consider several MRT transit
   forwarding mechanisms.  Then we look at how these forwarding
   mechanisms can link F<->G failed, then the network would be applied partitioned.
   It is clearly impossible to carrying LDP and IP traffic.

6.1.  MRT Forwarding Mechanisms

   The following options for MRT forwarding mechanisms are considered.

   1.  MRT LDP Labels

       A.  Topology-scoped FEC encoded using a single label

       B.  Topology and FEC encoded using a two label stack

   2.  MRT IP Tunnels

       A.  MRT IPv4 Tunnels

       B.  MRT IPv6 Tunnels

6.1.1.  MRT LDP labels

   We consider have two options for the MRT forwarding mechanisms using MRT
   LDP labels.

6.1.1.1.  Topology-scoped FEC encoded using a single label (Option 1A)

   [RFC7307] provides a mechanism to distribute FEC-Label bindings
   scoped link-disjoint or node-disjoint
   paths from G, I or J to a R.  The MRTs given MPLS topology (represented by MPLS MT-ID).  To use
   multi-topology LDP to create MRT forwarding topologies, we associate
   two MPLS MT-IDs with the MRT-Red and MRT-Blue forwarding topologies, in addition (b) and (c) offer paths
   that are as disjoint as possible.  For instance, the paths from B to
   R are the default shortest path forwarding topology with MT-
   ID=0.

   With this forwarding mechanism, a single label is distributed for
   each topology-scoped FEC.  For a given FEC same as in Figure 2 and the default topology
   (call it default-FEC-A), two additional topology-scoped FECs would be
   created, corresponding path from G to R on the Red and Blue
   MRT forwarding topologies
   (call them red-FEC-A is G->F->D->E->R and blue-FEC-A).  A router supporting this MRT
   transit forwarding mechanism advertises a different FEC-label binding
   for each of on the three topology-scoped FECs.  When a packet Red MRT is
   received with G->F->B->A->R.

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

                                  (a)
                        a label corresponding to red-FEC-A (for example), an
   MRT transit router will determine the next-hop for the MRT-Red
   forwarding topology for that FEC, swap the incoming label with the
   outgoing label corresponding to red-FEC-A learned from the MRT-Red
   next-hop router, non-2-connected graph

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

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

                    Figure 3: A non-2-connected network

5.  Maximally Redundant Trees (MRT) and forward the packet.

   This forwarding mechanism Fast-Reroute

   In normal IGP routing, each router has its shortest path tree (SPT)to
   all destinations.  From the useful property that the FEC perspective of a particular destination,
   D, this looks like a reverse SPT.  To use maximally redundant trees,
   in addition, each destination D has two MRTs associated with it; by
   convention these will be called the packet MRT-Blue and MRT-Red.  MRT-FRR is maintained in the labels at each hop
   along the MRT.  We will take advantage of this property when
   specifying how to carry LDP traffic on MRT paths
   realized by using multi-topology
   LDP labels.

   This approach forwarding.  There is very simple for hardware to support.  However, it
   reduces the label space for other uses, and it increases the memory
   needed to store the labels and the communication required by LDP to
   distribute FEC-label bindings.

   This a MRT-Blue
   forwarding option uses the LDP signaling extensions described in
   [RFC7307].  The MRT-specific LDP extensions required to support this
   option are described in [I-D.ietf-mpls-ldp-mrt].

6.1.1.2.  Topology topology and FEC encoded using a two label stack (Option 1B)

   With this MRT-Red forwarding mechanism, a two label stack is used to encode
   the topology and the FEC of the packet.  The top label (topology-id
   label) identifies the MRT topology.

   Any IP/LDP fast-reroute technique beyond LFA requires an additional
   dataplane procedure, such as an additional forwarding topology, while the second label
   (FEC label) identifies the FEC. mechanism.  The top label would be a new FEC
   type with two values corresponding to MRT Red
   well-known options are multi-topology forwarding (used by MRT-FRR),
   tunneling (e.g.  [RFC6981] or [RFC7490]), and Blue topologies. per-interface
   forwarding (e.g.  Loop-Free Failure Insensitive Routing in
   [EnyediThesis]).

   When an MRT transit router receives a packet with there is a topology-id
   label, link or node failure affecting, but not partitioning,
   the router pops network, each node will still have at least one path via one of
   the top label and uses that it MRTs to guide the
   next-hop selection in combination with reach the next label destination D.  For example, in Figure 3, C
   would normally forward traffic to R across the stack
   (the FEC label).  The router then swaps the FEC label, using the FEC-
   label bindings learned through normal LDP mechanisms.  The router C<->R link.  If that
   C<->R link fails, then pushes the topology-id label for C could use the next-hop. Blue MRT path C->D->E->R.

   As with Option 1A, this forwarding mechanism also has the useful
   property that is always the FEC associated case with the packet fast-reroute technologies, forwarding does
   not change until a local failure is maintained in the
   labels at each hop detected.  Packets are forwarded
   along the MRT.

   This forwarding mechanism has minimal usage of additional labels,
   memory and LDP communication.  It does increase shortest path.  The appropriate alternate to use is pre-
   computed.  [I-D.ietf-rtgwg-mrt-frr-algorithm] describes exactly how
   to determine whether the size of packets
   and MRT-Blue next-hops or the complexity of MRT-Red next-hops
   should be the required label operations and look-ups.

   This forwarding option MRT alternate next-hops for a particular primary next-
   hop to a particular destination.

   MRT alternates are always available to use.  It is consistent with context-specific label
   spaces, as a local decision
   whether to use an MRT alternate, a Loop-Free Alternate or some other
   type of alternate.

   As described in [RFC5331].  However, [RFC5286], when a worse failure than is anticipated
   happens, using LFAs that are not downstream neighbors can cause
   looping among alternates.  Section 1.1 of [RFC5286] gives an example
   of link-protecting alternates causing a loop on node failure.  Even
   if a worse failure than anticipated happens, the precise LDP behavior
   required to support this option for use of MRT has
   alternates will not been specified.

6.1.1.3.  Compatibility of Option 1A and 1B

   In principle, cause looping.

6.  Unicast Forwarding with MRT transit forwarding mechanisms 1A and 1B can coexist Fast-Reroute

   There are three possible types of routers involved in the same network, with forwarding a
   packet being forwarding along a single an MRT path.  At the MRT ingress router, the packet
   leaves the shortest path using to the single label of option 1A for some hops destination and the
   two label stack of option 1B for other hops.

6.1.1.4.  Mandatory support for follows an MRT LDP Label option 1A

   If a router supports path
   to the destination.  In a profile that includes FRR application, the MRT LDP Label option
   for ingress router is
   the PLR.  An MRT transit forwarding mechanism, then it MUST support option 1A,
   which encodes topology-scoped FECs using a single label.

6.1.2.  MRT IP tunnels (Options 2A and 2B)

   IP tunneling can also be used as an MRT transit forwarding mechanism.
   Each router supporting this MRT transit forwarding mechanism
   announces two additional loopback addresses and their takes a packet that arrives already
   associated MRT
   color.  Those addresses are used as destination addresses for MRT-
   blue and MRT-red IP tunnels respectively.  The special loopback
   addresses allow the transit nodes to identify the traffic as being
   forwarded along either with the MRT-blue or MRT-red topology to reach particular MRT, and forwards it on that same MRT.
   In some situations (to be discussed later), the
   tunnel destination.  For example, an MRT ingress router can cause a packet will need to be tunneled along
   leave the MRT-red MRT path and return to router X by
   encapsulating the packet using the MRT-red loopback address
   advertised by router X.  Upon receiving the packet, router X would
   remove shortest path.  This takes place
   at the encapsulation header MRT egress router.  The MRT ingress and forward the packet based egress functionality
   may depend on the
   original destination address.

   Announcements underlying type of these two additional loopback addresses per router
   with their MRT color requires IGP extensions, which have not been
   defined.

   Either IPv4 (option 2A) packet being forwarded (LDP or IPv6 (option 2B) can be used as the
   tunneling mechanism.

   Note that
   IP).  The MRT transit functionality is independent of the two type of
   packet being forwarded.  We first consider several MRT transit
   forwarding mechanisms.  Then we look at how these forwarding
   mechanisms using can be applied to carrying LDP Label options do
   not require additional loopbacks per router, as is required by the IP
   tunneling mechanism.  This is because LDP labels are used on a hop-
   by-hop basis to identify MRT-blue and MRT-red forwarding topologies.

6.2.  Forwarding LDP Unicast Traffic over IP traffic.

6.1.  MRT Paths

   In the previous section, we examined several Forwarding Mechanisms

   The following options for providing MRT transit forwarding functionality, which is independent of the
   type of traffic being carried.  We now look at the mechanisms are considered.

   1.  MRT ingress
   functionality, which will depend on the type of traffic being carried
   (IP or LDP).  We start by considering LDP traffic.

   We also simplify the initial discussion by assuming that the network
   consists of Labels

       A.  Topology-scoped FEC encoded using a single IGP area, label

       B.  Topology and that all routers in the network
   participate in MRT.  Other deployment scenarios that require MRT
   egress functionality are considered later in this document.

   In principle, it is possible to carry LDP traffic in FEC encoded using a two label stack

   2.  MRT IP tunnels.
   However, for LDP traffic, it is desirable to avoid tunneling.
   Tunneling LDP traffic to a remote node requires knowledge of remote
   FEC-label bindings so that the LDP traffic can continue to be
   forwarded properly when it leaves the tunnel.  This requires targeted Tunnels

       A.  MRT IPv4 Tunnels

       B.  MRT IPv6 Tunnels

6.1.1.  MRT LDP sessions which can add management complexity.  As described
   below, the labels

   We consider two options for the MRT forwarding mechanisms that use LDP labels do not
   require targeted LDP sessions.

6.2.1.  Forwarding LDP traffic using MRT
   LDP Labels labels.

6.1.1.1.  Topology-scoped FEC encoded using a single label (Option 1A)

   The MRT LDP Label option 1A forwarding mechanism uses topology-scoped
   FECs encoded using

   [RFC7307] provides a single label as described in section
   Section 6.1.1.1.  When mechanism to distribute FEC-Label bindings
   scoped to a PLR receives an given MPLS topology (represented by MPLS MT-ID).  To use
   multi-topology LDP packet that needs to be
   forwarded on the Red create MRT (for example), it does a label swap
   operation, replacing forwarding topologies, we associate
   two MPLS MT-IDs with the usual LDP label for MRT-Red and MRT-Blue forwarding topologies,
   in addition to the FEC default shortest path forwarding topology with the Red MRT MT-
   ID=0.

   With this forwarding mechanism, a single label is distributed for that
   each topology-scoped FEC.  For a given FEC received from the next-hop router in the default topology
   (call it default-FEC-A), two additional topology-scoped FECs would be
   created, corresponding to the Red and Blue MRT
   computed by forwarding topologies
   (call them red-FEC-A and blue-FEC-A).  A router supporting this MRT
   transit forwarding mechanism advertises a different FEC-label binding
   for each of the PLR. three topology-scoped FECs.  When a packet is
   received with a label corresponding to red-FEC-A (for example), an
   MRT transit router will determine the next-hop router in for the Red MRT
   receives MRT-Red
   forwarding topology for that FEC, swap the packet incoming label with the Red MRT
   outgoing label for corresponding to red-FEC-A learned from the FEC, MRT-Red
   next-hop router, and forward the MRT
   transit packet.

   This forwarding functionality continues as described in
   Section 6.1.1.1.  In this way mechanism has the useful property that the original FEC
   associated with the packet is maintained in the labels at each hop
   along the MRT.

6.2.2.  Forwarding  We will take advantage of this property when
   specifying how to carry LDP traffic using MRT LDP Labels (Option 1B)

   The on MRT paths using multi-topology
   LDP Label option 1B forwarding mechanism encodes labels.

   This approach is very simple for hardware to support.  However, it
   reduces the topology label space for other uses, and it increases the memory
   needed to store the labels and the communication required by LDP to
   distribute FEC-label bindings.

   This forwarding option uses the LDP signaling extensions described in
   [RFC7307].  The MRT-specific LDP extensions required to support this
   option will be described elsewhere.

6.1.1.2.  Topology and FEC encoded using a two label stack as described in Section 6.1.1.2.
   When (Option 1B)

   With this forwarding mechanism, a PLR receives an LDP packet that needs two label stack is used to be forwarded on encode
   the
   Red MRT, it first does a normal LDP label swap operation, replacing topology and the incoming normal LDP label associated with a given FEC with of the
   outgoing normal LDP packet.  The top label for that FEC learned from the next-hop on (topology-id
   label) identifies the Red MRT.  In addition, MRT forwarding topology, while the PLR pushes second label
   (FEC label) identifies the topology-identification FEC.  The top label associated would be a new FEC
   type with the two values corresponding to MRT Red MRT, and forward the Blue topologies.

   When an MRT transit router receives a packet with a topology-id
   label, the router pops the top label and uses that it to guide the
   appropriate
   next-hop on selection in combination with the Red MRT.  When next label in the next-hop stack
   (the FEC label).  The router in then swaps the
   Red MRT receives FEC label, using the packet with FEC-
   label bindings learned through normal LDP mechanisms.  The router
   then pushes the Red MRT topology-id label for the FEC, the
   MRT transit forwarding functionality continues as described in
   Section 6.1.1.2. next-hop.

   As with option Option 1A, this forwarding mechanism also has the useful
   property that the original FEC associated with the packet is maintained in the
   labels at each hop along the MRT.

6.2.3.  Other considerations for forwarding LDP traffic using MRT LDP
        Labels

   Note that

   This forwarding mechanism has minimal usage of additional labels,
   memory and LDP traffic using MRT LDP Labels can be done
   without communication.  It does increase the use size of targeted LDP sessions when an MRT path to packets
   and the
   destination FEC complexity of the required label operations and look-ups.

   This forwarding option is used.  The alternates selected consistent with context-specific label
   spaces, as described in
   [I-D.ietf-rtgwg-mrt-frr-algorithm] use the MRT path to [RFC5331].  However, the
   destination FEC, so targeted precise LDP sessions are not needed.  If instead
   one found it desirable to have the PLR use an MRT behavior
   required to reach the
   primary next-next-hop support this option for the FEC, MRT has not been specified.

6.1.1.3.  Compatibility of Option 1A and then continue 1B

   In principle, MRT transit forwarding mechanisms 1A and 1B can coexist
   in the
   LDP same network, with a packet being forwarding along the shortest a single
   MRT path tree from the primary next-next-
   hop, this would require tunneling to using the primary next-next-hop and a
   targeted LDP session single label of option 1A for some hops and the PLR to learn the FEC-label binding
   two label stack of option 1B for other hops.

6.1.1.4.  Mandatory support for
   primary next-next-hop to correctly forward the packet.

   For greatest hardware compatibility, routers implementing MRT fast-
   reroute of LDP traffic MUST support Option Label option 1A of encoding the MT-ID
   in

   If a router supports a profile that includes the labels (See Section 9).

6.3.  Forwarding IP Unicast Traffic over MRT Paths

   For IPv4 traffic, there is no currently practical alternative except LDP Label option
   for MRT transit forwarding mechanism, then it MUST support option 1A,
   which encodes topology-scoped FECs using a single label.

6.1.2.  MRT IP tunnels (Options 2A and 2B)

   IP tunneling to gain the bits needed to indicate the MRT-Blue or MRT-Red can also be used as an MRT transit forwarding topology.  For IPv6 traffic, in principle one could define
   bits in mechanism.
   Each router supporting this MRT transit forwarding mechanism
   announces 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.  The special loopback
   addresses allow the IPv6 options header transit nodes to indicate identify the MRT-Blue traffic as being
   forwarded along either the MRT-blue or MRT-Red
   forwarding topology.  However, in this document, we have chosen not MRT-red topology to define a solution that would work for IPv6 traffic but not for
   IPv4 traffic.

   The choice of reach the
   tunnel egress MAY be flexible since any destination.  For example, an MRT ingress router closer
   to the destination than the next-hop can work.  This architecture
   assumes that cause a
   packet to be tunneled along the original destination in MRT-red path to router X by
   encapsulating the area is selected (see
   Section 11 for handling of multi-homed prefixes); another possible
   choice is packet using the next-next-hop towards MRT-red loopback address
   advertised by router X.  Upon receiving the destination.  As discussed in packet, router X would
   remove the previous section, for LDP traffic, using encapsulation header and forward the MRT to packet based on the
   original destination simplifies MRT-FRR by avoiding the need for targeted LDP
   sessions to address.

   Either IPv4 (option 2A) or IPv6 (option 2B) can be used as the next-next-hop.  For IP,
   tunneling mechanism.

   Note that consideration doesn't
   apply.  However, consistency with the two forwarding mechanisms using LDP is RECOMMENDED.

   Some situations Label options do
   not require tunneling IP traffic along an MRT to a tunnel
   endpoint that additional loopbacks per router, as is not the destination of required by the IP traffic.  These
   situations will be discussed in detail later.  We note here that an
   IP packet with a destination in a different IGP area/level from the
   PLR should be tunneled
   tunneling mechanism.  This is because LDP labels are used on the MRT a hop-
   by-hop basis to identify MRT-blue and MRT-red forwarding topologies.

6.2.  Forwarding LDP Unicast Traffic over MRT Paths

   In the ABR/LBR on the shortest path
   to previous section, we examined several options for providing
   MRT transit forwarding functionality, which is independent of the destination.  For a destination outside
   type of traffic being carried.  We now look at the PLR's MRT
   Island, the packet should be tunneled ingress
   functionality, which will depend on the MRT to a non-proxy-node
   immediately before the named proxy-node on that particular color MRT.

6.3.1.  Tunneling IP type of traffic using MRT LDP Labels

   An IP packet can be tunneled along an MRT path being carried
   (IP or LDP).  We start by pushing the
   appropriate MRT LDP label(s).  Tunneling using considering LDP labels, as opposed
   to IP headers, has traffic.

   We also simplify the initial discussion by assuming that the advantage network
   consists of a single IGP area, and that more installed all routers can
   do line-rate encapsulation and decapsulation using LDP than using IP.
   Also, no additional in the network
   participate in MRT.  Other deployment scenarios that require MRT
   egress functionality are considered later in this document.

   In principle, it is possible to carry LDP traffic in MRT IP addresses would need tunnels.
   However, for LDP traffic, it is desirable to be allocated or
   signaled.

6.3.1.1. avoid tunneling.
   Tunneling IP LDP traffic to a remote node requires knowledge of remote
   FEC-label bindings so that the LDP traffic can continue to be
   forwarded properly when it leaves the tunnel.  This requires targeted
   LDP sessions which can add management complexity.  As described
   below, the two MRT forwarding mechanisms that use LDP labels do not
   require targeted LDP sessions.

6.2.1.  Forwarding LDP traffic using MRT LDP Labels (Option 1A)

   The MRT LDP Label option 1A forwarding mechanism uses topology-scoped
   FECs encoded using a single label as described in section
   Section 6.1.1.1.  When a PLR receives an IP LDP packet that needs to be
   forwarded on the Red MRT to a particular tunnel endpoint, (for example), it does a label push operation.  The swap
   operation, replacing the usual LDP label pushed is for the FEC with the Red MRT
   label for a that FEC originated received from the next-hop router in the Red MRT
   computed by the tunnel endpoint, learned from PLR.  When the next-hop on router in the Red MRT
   receives the packet with the Red MRT label for the FEC, the MRT
   transit forwarding functionality continues as described in
   Section 6.1.1.1.  In this way the original FEC associated with the
   packet is maintained at each hop along the MRT.

6.3.1.2.  Tunneling IP

6.2.2.  Forwarding LDP traffic using MRT LDP Labels (Option 1B)

   The MRT LDP Label option 1B forwarding mechanism encodes the topology
   and the FEC using a two label stack as described in Section 6.1.1.2.
   When a PLR receives an IP LDP packet that needs to be forwarded on the
   Red MRT to MRT, it first does a particular tunnel endpoint, the PLR pushes two labels on normal LDP label swap operation, replacing
   the IP packet.  The first (inner) incoming normal LDP label is associated with a given FEC with the
   outgoing normal LDP label for that FEC learned from the next-hop on
   the Red MRT, associated with a FEC
   originated by the tunnel endpoint.  The second (outer) label is MRT.  In addition, the PLR pushes the topology-identification
   label associated with the Red MRT.

   For completeness, we note here a potential variation that uses a
   single label as opposed to two labels.  In order to tunnel an IP MRT, and forward the packet over an MRT to the destination of
   appropriate next-hop on the IP packet (as opposed to
   an arbitrary tunnel endpoint), then we could just push a topology-
   identification label directly onto Red MRT.  When the packet.  An MRT transit next-hop router
   would need to pop the topology-id label, do an IP route lookup in the
   context of that topology-id , and push the topology-id label.

6.3.2.  Tunneling IP traffic using MRT IP Tunnels

   In order to tunnel over the
   Red MRT to a particular tunnel endpoint, the
   PLR encapsulates receives the original IP packet with an additional IP header
   using the MRT-Blue or MRT-Red loopack address of Red MRT label for the tunnel endpoint.

6.3.3.  Required support

   For greatest hardware compatibility and ease FEC, the
   MRT transit forwarding functionality continues as described in removing
   Section 6.1.1.2.  As with option 1A, the MRT-
   topology marking original FEC associated with
   the packet is maintained at area/level boundaries, routers that support MPLS
   and implement IP MRT fast-reroute MUST support tunneling of IP each hop along the MRT.

6.2.3.  Other considerations for forwarding LDP traffic using MRT LDP
        Labels Option 1A (topology-scoped FEC encoded

   Note that forwarding LDP traffic using a single label).

7. MRT Island Formation

   The purpose LDP Labels can be done
   without the use of communicating support for targeted LDP sessions when an MRT in path to the IGP
   destination FEC is to
   indicate that used.  The alternates selected in
   [I-D.ietf-rtgwg-mrt-frr-algorithm] use the MRT-Blue and MRT-Red forwarding topologies are
   created for transit traffic.  The MRT architecture allows for
   different, potentially incompatible options.  In order to create
   constistent MRT forwarding topologies, the routers participating in a
   particular MRT Island need path to use the same set of options.  These
   options
   destination FEC, so targeted LDP sessions are grouped into MRT profiles.  In addition, not needed.  If instead
   one found it desirable to have the routers in PLR use an MRT Island all need to use reach the same set of nodes
   primary next-next-hop for the FEC, and links within then continue forwarding the Island when computing
   LDP packet along the MRT forwarding topologies.  This
   section describes shortest path tree from the information used by a router primary next-next-
   hop, this would require tunneling to determine the
   nodes primary next-next-hop and links to include in a particular MRT Island.  Some of this
   information is shared among routers using
   targeted LDP session for the newly-defined IGP
   signaling extensions PLR to learn the FEC-label binding for
   primary next-next-hop to correctly forward the packet.

   For greatest hardware compatibility, routers implementing MRT described in [I-D.ietf-ospf-mrt] and
   [I-D.ietf-isis-mrt].  Other information already exists fast-
   reroute of LDP traffic MUST support Option 1A of encoding the MT-ID
   in the IGPs
   and can be used by labels (See Section 9).

6.3.  Forwarding IP Unicast Traffic over MRT in Island formation, subject Paths

   For IPv4 traffic, there is no currently practical alternative except
   tunneling to gain the
   interpretation defined here.

   Deployment scenarios using multi-topology OSPF or IS-IS, bits needed to indicate the MRT-Blue or running
   both ISIS and OSPF on MRT-Red
   forwarding topology.  For IPv6 traffic, in principle one could define
   bits in the same routers is out of scope for this
   specification.  As with LFA, it is expected that OSPF Virtual Links
   will not be supported.

7.1.  IGP Area or Level

   All links in an MRT Island MUST be bidirectional and belong IPv6 options header to indicate the
   same IGP area MRT-Blue or level.  For ISIS, a link belonging MRT-Red
   forwarding topology.  However, in this document, we have chosen not
   to both level 1
   and level 2 define a solution that would qualify work for IPv6 traffic but not for
   IPv4 traffic.

   The choice of tunnel egress is flexible since any router closer to be in multiple MRT Islands.  A given ABR
   or LBR
   the destination than the next-hop can belong to multiple MRT Islands, corresponding to work.  This architecture
   assumes that the areas
   or levels original destination in which it participates.  Inter-area forwarding behavior the area is discussed in selected (see
   Section 10.

7.2.  Support 11 for a specific MRT profile

   All routers handling of multi-homed prefixes); another possible
   choice is the next-next-hop towards the destination.  As discussed in an MRT Island MUST support
   the same MRT profile.  A
   router advertises support previous section, for a given MRT profile LDP traffic, using the IGP
   extensions defined in [I-D.ietf-ospf-mrt] and [I-D.ietf-isis-mrt]
   using an 8-bit Profile ID value.  A given router can support multiple
   MRT profiles and participate in multiple MRT Islands.  The options to the original
   destination simplifies MRT-FRR by avoiding the need for targeted LDP
   sessions to the next-next-hop.  For IP, that make up consideration doesn't
   apply.

   Some situations require tunneling IP traffic along an MRT profile, as well as to a tunnel
   endpoint that is not the default MRT profile, are
   defined in Section 8.

7.3.  Excluding additional routers and interfaces from destination of the MRT Island

   MRT takes into account existing IGP mechanisms for discouraging
   traffic from using particular links and routers, and it introduces an
   MRT-specific exclusion mechanism for links.

7.3.1.  Existing IGP exclusion mechanisms

   Mechanisms for discouraging traffic from using particular links
   already exist IP traffic.  These
   situations will be discussed in ISIS and OSPF.  In ISIS, detail later.  We note here that an interface configured
   IP packet with a metric of 2^24-2 (0xFFFFFE) will only be used as a last
   resort.  (An interface configured with destination in a metric of 2^24-1 (0xFFFFFF)
   will not different IGP area/level from the
   PLR should be advertised into tunneled on the topology.)  In OSPF, an interface
   configured with MRT to the ABR/LBR on the shortest path
   to the destination.  For a metric destination outside of 2^16-1 (0xFFFF) will only be used as a
   last resort.  These metrics can the PLR's MRT
   Island, the packet should be configured manually tunneled on the MRT to enforce
   administrative policy, or they a non-proxy-node
   immediately before the named proxy-node on that particular color MRT.

6.3.1.  Tunneling IP traffic using MRT LDP Labels

   An IP packet can be set in tunneled along an automated manner as
   with MRT path by pushing the
   appropriate MRT LDP IGP synchronization [RFC5443].

   Mechanisms also exist in ISIS label(s).  Tunneling using LDP labels, as opposed
   to IP headers, has the the advantage that more installed routers can
   do line-rate encapsulation and OSPF decapsulation using LDP than using IP.
   Also, no additional IP addresses would need to prevent transit be allocated or
   signaled.

6.3.1.1.  Tunneling IP traffic
   from using a particular router.  In ISIS, the overload bit is used
   for this purpose.  In OSPF, [RFC6987] specifies setting all outgoing
   interface metrics to 0xFFFF to accomplish this.

   The following rules for MRT Island formation ensure that LDP Labels (Option 1A)

   The MRT FRR
   protection traffic does not use LDP Label option 1A forwarding mechanism uses topology-scoped
   FECs encoded using a link or router single label as described in section
   Section 6.1.1.1.  When a PLR receives an IP packet that is discouraged
   from carrying traffic by existing IGP mechanisms.

   1.  A bidirectional link MUST needs to be excluded from an MRT Island if
       either the forward or reverse cost
   forwarded on the link is 0xFFFFFE (for
       ISIS) or 0xFFFF for OSPF.

   2.  A router MUST be excluded from an Red MRT Island if to a particular tunnel endpoint, it does a
   label push operation.  The label pushed is advertised
       with the overload bit set (for ISIS), or it is advertised with
       metric values of 0xFFFF on all of its outgoing interfaces (for
       OSPF).

7.3.2.  MRT-specific exclusion mechanism

   This architecture also defines Red MRT label for a means of excluding an otherwise
   usable link
   FEC originated by the tunnel endpoint, learned from the next-hop on
   the Red MRT.

6.3.1.2.  Tunneling IP traffic using MRT Islands.  [I-D.ietf-ospf-mrt] and
   [I-D.ietf-isis-mrt] define LDP Labels (Option 1B)

   The MRT LDP Label option 1B forwarding mechanism encodes the IGP extensions for OSPF topology
   and ISIS used
   to advertise that the FEC using a link is MRT-Ineligible.  A link with either
   interface advertised two label stack as MRT-Ineligible MUST be excluded from described in Section 6.1.1.2.
   When a PLR receives an MRT
   Island.  Note IP packet that an interface advertised as MRT-Ineligigle by a
   router is ineligible with respect needs to all profiles advertised by that
   router.

7.4.  Connectivity

   All of the routers in an MRT Island MUST be connected by
   bidirectional links with other routers in forwarded on the
   Red MRT Island.
   Disconnected MRT Islands will operate independently of one another.

7.5.  Example algorithm

   An algorithm that allows a computing router to identify the routers
   and links in a particular tunnel endpoint, the local MRT Island satisfying PLR pushes two labels on
   the above rules is given
   in section 5.2 of [I-D.ietf-rtgwg-mrt-frr-algorithm].

8.  MRT Profile

   An MRT Profile IP packet.  The first (inner) label is the normal LDP label
   learned from the next-hop on the Red MRT, associated with a set of values and options related to MRT
   behavior. FEC
   originated by the tunnel endpoint.  The complete set of options second (outer) label is designated by the
   corresponding 8-bit Profile ID value.

   This document specifies
   topology-identification label associated with the values and options Red MRT.

   For completeness, we note here a potential variation that correspond uses a
   single label as opposed to the
   Default MRT Profile (Profile ID = 0).  Future documents may define
   other two labels.  In order to tunnel an IP
   packet over an MRT Profiles by specifying to the MRT Profile Options below.

8.1.  MRT Profile Options

   Below is a description destination of the values and options that define IP packet (as opposed to
   an MRT
   Profile.

   MRT Algorithm:   This identifies arbitrary tunnel endpoint), then we could just push a topology-
   identification label directly onto the particular packet.  An MRT algorithm used by
      the transit router for this profile.  Algorithm transitions can be managed
      by advertising multiple MRT profiles.

   MRT-Red MT-ID:   This specifies
   would need to pop the MT-ID topology-id label, do an IP route lookup in the
   context of that topology-id , and push the topology-id label.

6.3.2.  Tunneling IP traffic using MRT IP Tunnels

   In order to be associated tunnel over the MRT to a particular tunnel endpoint, the
   PLR encapsulates the original IP packet with an additional IP header
   using the MRT-Blue or MRT-Red forwarding topology.  It is needed for use in LDP
      signaling.  All routers loopack address of the tunnel endpoint.

6.3.3.  Required support

   For greatest hardware compatibility and ease in removing the MRT-
   topology marking at area/level boundaries, routers that support MPLS
   and implement IP MRT Island fast-reroute MUST agree on support tunneling of IP
   traffic using MRT LDP Labels Option 1A (topology-scoped FEC encoded
   using a value.

   MRT-Blue MT-ID:   This specifies the MT-ID single label).

7.  MRT Island Formation

   The purpose of communicating support for MRT is to be associated with indicate that the
   MRT-Blue and MRT-Red forwarding topology.  It is needed topologies are created for use in LDP
      signaling.  All transit
   traffic.  The MRT architecture allows for different, potentially
   incompatible options.  In order to create consistent MRT forwarding
   topologies, the routers participating in the a particular MRT Island MUST agree on a value.

   GADAG Root Selection Policy:   This specifes need
   to use the manner in which same set of options.  These options are grouped into MRT
   profiles.  In addition, the
      GADAG root is selected.  All routers in the an MRT island Island all need to use
   the same GADAG root in the calculations used construct set of nodes and links within the MRTs.
      A valid GADAG Root Selection Policy MUST be such that each router
      in Island when computing the
   MRT island chooses forwarding topologies.  This section describes the same GADAG root based on information
      available
   used by a router to all routers in determine the nodes and links to include in a
   particular MRT island.  GADAG Root Selection
      Priority values, advertised Island.  Some information already exists in the IGP as router-specific MRT
      parameters, MAY IGPs
   and can be used in a GADAG Root Selection Policy. by MRT Forwarding Mechanism:   This specifies which forwarding mechanism in Island formation, subject to the router uses
   interpretation defined here.

   Other information needs to carry transit traffic along MRT paths.  A
      router be communicated between routers for which supports a specific MRT forwarding mechanism must
      program appropriate next-hops into the forwarding plane.  The
      current options are MRT LDP Labels, IPv4 Tunneling, IPv6
      Tunneling, and None.  If the MRT LDP Labels option is supported,
      then option 1A and the appropriate signaling
   there do not currently exist protocol extensions.  This new
   information needs to be shared among all routers in an IGP area, so
   defining extensions MUST to existing IGPs to carry this information makes
   sense.  These new protocol extensions will be
      supported.  If IPv4 is supported, then defined elsewhere.

   Deployment scenarios using multi-topology OSPF or IS-IS, or running
   both MRT-Red ISIS and MRT-Blue
      IPv4 Loopback Addresses SHOULD be specified.  If IPv6 OSPF on the same routers is
      supported, both MRT-Red and MRT-Blue IPv6 Loopback Addresses
      SHOULD out of scope for this
   specification.  As with LFA, it is expected that OSPF Virtual Links
   will not be specified.  The None option supported.

7.1.  IGP Area or Level

   All links in may an MRT Island MUST be useful for
      multicast global protection.

   Recalculation:   Recalculation specifies the process bidirectional and timing by
      which new MRTs are computed after belong to the topology has been modified.

   Area/Level Border Behavior:   Should inter-area traffic on the MRT-
      Blue
   same IGP area or MRT-Red be put back onto the shortest path tree?  Should
      it level.  For ISIS, a link belonging to both level 1
   and level 2 would qualify to be swapped from MRT-Blue or MRT-Red in one area/level to MRT-
      Red multiple MRT Islands.  A given ABR
   or MRT-Blue in the next area/level LBR can belong to multiple MRT Islands, corresponding to avoid the potential
      failure of an ABR?  (See [I-D.atlas-rtgwg-mrt-mc-arch] for use-
      case details.

   Other Profile-Specific Behavior:   Depending upon the use-case areas
   or levels in which it participates.  Inter-area forwarding behavior
   is discussed in Section 10.

7.2.  Support for
      the profile, there may be additional profile-specific behavior.

   If a specific MRT profile

   All routers in an MRT Island MUST support the same MRT profile.  A
   router advertises support for multiple a given MRT profiles, then it
   MUST create the transit forwarding topologies for each of those,
   unless the profile specifies using an 8-bit MRT
   Profile ID value.  The registry for the None option MRT Profile ID is defined in
   this document.  The protocol extensions for advertising the MRT Forwarding
   Mechanism.
   Profile ID value will be defined elsewhere.  A given router MUST NOT advertise can
   support multiple MRT profiles that
   overlap and participate in their MRT-Red MT-ID or MRT-Blue MT-ID.

8.2.  Router-specific MRT paramaters

   For some profiles, additional router-specific multiple MRT parameters may need
   to be distributed via the IGP.  While the set of
   Islands.  The options indicated by
   the MRT Profile ID must be identical for all routers in that make up an MRT
   Island, these router-specific MRT parameters may differ between
   routers in profile, as well as the same
   default MRT island.  Several such parameters profile, are
   described below.

   GADAG Root Selection Priority:   A GADAG Root Selection Policy MAY
      rely on the GADAG Root Selection Priority values defined in Section 8.

   Note that a router may advertise support for multiple different MRT
   profiles.  The process of MRT Island formation takes place
   independently for each MRT profile advertised by
      each router a given router.  For
   example, consider a network with 40 connected routers in the same
   area advertising support for MRT island. Profile A GADAG Root Selection Policy may
      use the GADAG Root Selection Priority to allow network operators and MRT Profile B.  Two
   distinct MRT Islands will be formed corresponding to configure Profile A and
   Profile B, with each island containing all 40 routers.  A complete
   set of maximally redundant trees will be computed for each island
   following the rules defined for each profile.  If we add a parameter third MRT
   Profile to ensure that the GADAG root is selected
      from this example, with Profile C being advertised by a particular
   connected subset of routers.  An example 30 routers, there will be a third MRT Island
   formed corresponding to those 30 routers, and a third set of
   maximally redundant trees will be computed.  In this use example, 40
   routers would compute and install two sets of
      the GADAG Root Selection Priority value by the GADAG Root
      Selection Policy is given in the Default MRT profile below.

   MRT-Red Loopback Address:   This provides the router's loopback
      address transit forwarding
   entries corresponding to reach the router via the MRT-Red Profiles A and B, while 30 routers would
   compute and install three sets of MRT transit forwarding topology.
      It can be specified for either IPv4 entries
   corresponding to Profiles A, B, and IPv6.

   MRT-Blue Loopback Address:   This provides C.

7.3.  Excluding additional routers and interfaces from the router's loopback
      address to reach the router via the MRT-Blue forwarding topology.
      It can be specified MRT Island

   MRT takes into account existing IGP mechanisms for either IPv4 discouraging
   traffic from using particular links and IPv6.

   The extensions to OSPF routers, and ISIS it introduces an
   MRT-specific exclusion mechanism for advertising a router's GADAG Root
   Selection Priority value are defined in [I-D.ietf-ospf-mrt] and
   [I-D.ietf-isis-mrt]. links.

7.3.1.  Existing IGP extensions exclusion mechanisms

   Mechanisms for the advertising a router's
   MRT-Red and MRT-Blue Loopback Addresses have not been defined.

8.3.  Default MRT profile

   The following set of options defines the default MRT Profile.  The
   default MRT profile is indicated by the MRT Profile ID value of 0.

   MRT Algorithm:   MRT Lowpoint algorithm defined discouraging traffic from using particular links
   already exist in
      [I-D.ietf-rtgwg-mrt-frr-algorithm].

   MRT-Red MPLS MT-ID:   [I-D.ietf-mpls-ldp-mrt] contains the IANA
      request for allocation ISIS and OSPF.  In ISIS, an interface configured
   with a metric of this value from the MPLS Multi-Topology
      Identifiers Registry.  Prototype experiments have 2^24-2 (0xFFFFFE) will only be used as a value last
   resort.  (An interface configured with a metric of
      3997.

   MRT-Blue MPLS MT-ID:   [I-D.ietf-mpls-ldp-mrt] contains 2^24-1 (0xFFFFFF)
   will not be advertised into the IANA
      request for allocation topology.)  In OSPF, an interface
   configured with a metric of this value from the MPLS Multi-Topology
      Identifiers Registry.  Prototype experiments have 2^16-1 (0xFFFF) will only be used as a value of
      3998.

   GADAG Root Selection Policy:   Among the routers
   last resort.  These metrics can be configured manually to enforce
   administrative policy, or they can be set in the MRT Island
      and with the highest priority advertised, an implementation MUST
      pick the router automated manner as
   with the highest Router ID to be the GADAG root.

   Forwarding Mechanisms:   MRT LDP Labels

   Recalculation:   Recalculation of MRTs SHOULD occur as described IGP synchronization [RFC5443].

   Mechanisms also already exist in
      Section 12.2.  This allows the MRT forwarding topologies ISIS and OSPF to
      support IP/LDP fast-reroute traffic.

   Area/Level Border Behavior:   As described in Section 10, ABRs/LBRs
      SHOULD ensure that discourage or
   prevent transit traffic leaving the area also exits from using a particular router.  In ISIS, the MRT-Red
      or MRT-Blue forwarding topology.

9.  LDP signaling extensions
   overload bit is prevents transit traffic from using a router.

   For OSPFv2 and considerations

   The protocol extensions OSPFv3, [RFC6987] specifies setting all outgoing
   interface metrics to 0xFFFF to discourage transit traffic from using
   a router.( [RFC6987] defines the metric value 0xFFFF as
   MaxLinkMetric, a fixed architectural value for LDP are defined in
   [I-D.ietf-mpls-ldp-mrt].  A router must indicate OSPF.)  For OSPFv3,
   [RFC5340] specifies that it has a router be excluded from the
   ability to support MRT; having this explicit allows intra-area
   shortest path tree computation if the use of MRT-
   specific processing, such as special handling V6-bit or R-bit of FECs sent with the
   Rainbow MRT MT-ID.

   A FEC sent with LSA
   options is not set in the Rainbow Router LSA.

   The following rules for MRT MT-ID indicates Island formation ensure that MRT FRR
   protection traffic does not use a link or router that is discouraged
   or prevented from carrying traffic by existing IGP mechanisms.

   1.  A bidirectional link MUST be excluded from an MRT Island if
       either the FEC applies
   to all forward or reverse cost on the MRT-Blue and MRT-Red MT-IDs in supported MRT profiles.
   The FEC-label bindings link is 0xFFFFFE (for
       ISIS) or 0xFFFF for the default shortest-path based MT-ID 0 OSPF.

   2.  A router MUST still be sent (even though it could be inferred excluded from the Rainbow
   FEC-label bindings) to ensure continuous operation of normal LDP
   forwarding.  The Rainbow an MRT MT-ID Island if it is defined to provide an easy way
   to handle advertised
       with the special signaling that is needed at ABRs overload bit set (for ISIS), or LBRs.  It
   avoids the problem of needing to signal different MPLS labels to
   different LDP neighbors for the same FEC.  Because the Rainbow MRT
   MT-ID it is used only by ABRs/LBRs or advertised with
       metric values of 0xFFFF on all of its outgoing interfaces (for
       OSPFv2 and OSPFv3).

   3.  A router MUST be excluded from an LDP egress router, MRT Island if it is not
   MRT profile specific.

   [I-D.ietf-mpls-ldp-mrt] contains advertised
       with either the IANA request for V6-bit or R-bit of the Rainbow MRT
   MPLS MT-ID.

10.  Inter-area Forwarding Behavior

   Unless otherwise specified, LSA options not set in this section we will use the terms
   area and ABR to indicate either
       Router LSA.

7.3.2.  MRT-specific exclusion mechanism

   This architecture also defines a means of excluding an OSPF area and OSPF ABR or ISIS
   level and ISIS LBR.

   An ABR/LBR has two forwarding roles.  First, it forwards traffic
   within areas.  Second, it forwards traffic otherwise
   usable link from one area into
   another.  These same two roles apply MRT Islands.  The protocol extensions for
   advertising that a link is MRT-Ineligible will be defined elsewhere.
   A link with either interface advertised as MRT-Ineligible MUST be
   excluded from an MRT transit traffic.
   Traffic on MRT-Red or MRT-Blue destined inside the area needs to stay
   on MRT-Red or MRT-Blue in Island.  Note that area.  However, it an interface advertised as
   MRT-Ineligible by a router is desirable for
   traffic leaving the area ineligible with respect to also exit MRT-Red or MRT-Blue and return
   to shortest path forwarding.

   For unicast MRT-FRR, all profiles
   advertised by that router.

7.4.  Connectivity

   All of the need to stay on routers in an MRT forwarding topology
   terminates at the ABR/LBR whose best route is via a different area/
   level.  It is highly desirable to go back to the default forwarding
   topology when leaving an area/level.  There are three basic reasons
   for this.  First, the default topology uses shortest paths; Island MUST be connected by
   bidirectional links with other routers in the
   packet MRT Island.
   Disconnected MRT Islands will thus take the shortest possible route to the destination.
   Second, this allows failures operate independently of one another.

7.5.  Algorithm for MRT Island Identification

   An algorithm that might appear in multiple areas
   (e.g.  ABR/LBR failures) allows a computing router to be separately identified identify the routers
   and repaired
   around.  Third, links in the packet can be fast-rerouted again, if necessary,
   due to a failure local MRT Island satisfying the above rules is given
   in a different area. section 5.2 of [I-D.ietf-rtgwg-mrt-frr-algorithm].

8.  MRT Profile

   An ABR/LBR that receives MRT Profile is a packet on MRT-Red or MRT-Blue towards
   destination Z should continue to forward the packet along MRT-Red or
   MRT-Blue only if the best route set of values and options related to Z MRT
   behavior.  The complete set of options is in designated by the same area as
   corresponding 8-bit Profile ID value.

   This document specifies the
   interface values and options that correspond to the packet was received on.  Otherwise,
   Default MRT Profile (Profile ID = 0).  Future documents may define
   other MRT Profiles by specifying the packet
   should be removed from MRT-Red or MRT-Blue MRT Profile Options below.

8.1.  MRT Profile Options

   Below is a description of the values and forwarded on options that define an MRT
   Profile.

   MRT Algorithm:   This identifies the
   shortest-path default forwarding topology.

   To avoid per-interface forwarding state particular algorithm for
      computing maximally redundant trees used by the router for this
      profile.

   MRT-Red and MRT-Blue, MT-ID:   This specifies the
   ABR/LBR needs to arrange that packets destined MPLS MT-ID to a different area
   arrive at be associated with
      the ABR/LBR already not marked as MRT-Red or MRT-Blue.

10.1.  ABR Forwarding Behavior with MRT LDP Label Option 1A

   For LDP forwarding where a single label specifies (MT-ID, FEC), the
   ABR/LBR topology.  It is responsible for advertising the proper label to each
   neighbor.  Assume that an ABR/LBR has allocated three labels for a
   particular destination; those labels are L_primary, L_blue, and
   L_red.  To those routers in from the same area as MPLS
      Multi-Topology Identifiers Registry.

   MRT-Blue MT-ID:   This specifies the best route MPLS MT-ID to be associated with
      the
   destination, the ABR/LBR advertises the following FEC-label bindings:
   L_primary for MRT-Blue forwarding topology.  It is allocated from the default topology, L_blue for MPLS
      Multi-Topology Identifiers Registry.

   GADAG Root Selection Policy:   This specifies the MRT-Blue MT-ID and
   L_red for manner in which the MRT-Red MT-ID, as expected.  However, to
      GADAG root is selected.  All routers in
   other areas, the ABR/LBR advertises MRT island need to use
      the following FEC-label bindings:
   L_primary for same GADAG root in the default topology, and L_primary for calculations used construct the Rainbow MRT
   MT-ID.  Associating L_primary with MRTs.
      A valid GADAG Root Selection Policy MUST be such that each router
      in the Rainbow MRT MT-ID causes island chooses the
   receiving routers same GADAG root based on information
      available to use L_primary for all routers in the MRT-Blue MT-ID and for MRT island.  GADAG Root Selection
      Priority values, advertised as router-specific MRT parameters, MAY
      be used in a GADAG Root Selection Policy.

   MRT Forwarding Mechanism:   This specifies which forwarding mechanism
      the
   MRT-Red MT-ID.

   The ABR/LBR installs all router uses to carry transit traffic along MRT paths.  A
      router which supports a specific MRT forwarding mechanism must
      program appropriate next-hops for into the best area: primary next-
   hops for L_primary, MRT-Blue next-hops for L_blue, forwarding plane.  The
      current options are MRT LDP Labels, IPv4 Tunneling, IPv6
      Tunneling, and MRT-Red next-
   hops for L_red.  Because None.  If the ABR/LBR advertised (Rainbow MRT MT-ID,
   FEC) with L_primary to neighbors not in the best area, packets from
   those neighbors will arrive at LDP Labels option is supported,
      then option 1A and the ABR/LBR with a label L_primary appropriate signaling extensions MUST be
      supported.  If IPv4 is supported, then both MRT-Red and
   will MRT-Blue
      IPv4 Loopback Addresses SHOULD be forwarded into the best area along specified.  If IPv6 is
      supported, both MRT-Red and MRT-Blue IPv6 Loopback Addresses
      SHOULD be specified.

   Recalculation:   Recalculation specifies the default topology.  By
   controlling what labels process and timing by
      which new MRTs are advertised, computed after the ABR/LBR can thus enforce
   that packets exiting topology has been modified.

   Area/Level Border Behavior:   This specifies how traffic traveling on
      the MRT-Blue or MRT-Red in one area do so on should be treated when it
      passes into another area.

   Other Profile-Specific Behavior:   Depending upon the shortest-path default
   topology.

10.1.1.  Motivation use-case for Creating
      the Rainbow-FEC

   The desired forwarding behavior could profile, there may be achieved in the above
   example without using the Rainbow-FEC.  This could additional profile-specific behavior.

   When a new MRT Profile is defined, new and unique values should be done by having
   the ABR/LBR advertise
   allocated from the following FEC-label bindings MPLS Multi-Topology Identifiers Registry,
   corresponding to neighbors
   not in the best area: L1_primary MRT-Red and MRT-Blue MT-ID values for the default topology, L1_primary new
   MRT Profile .

   If a router advertises support for multiple MRT profiles, then it
   MUST create the MRT-Blue MT-ID, and L1_primary transit forwarding topologies for each of those,
   unless the MRT-Red MT-ID.  Doing
   this would require machinery to spoof profile specifies the labels None option for MRT Forwarding
   Mechanism.

   The ability of MRT-FRR to support transit forwarding entries for
   multiple profiles can be used in FEC-label
   binding advertisements on to facilitate a per-neighbor basis.  Such label-spoofing
   machinery does not currently exist in most LDP implmentations and
   doesn't have other obvious uses.

   Many smooth transition from
   an existing LDP implmentations do however have the ability deployed MRT Profile to
   filter FEC-label binding advertisements on a per-neighbor basis. new MRT Profile.  The
   Rainbow-FEC allows us to re-use new
   profile can be activated in parallel with the existing per-neighbor FEC
   filtering machinery to achieve profile,
   installing the desired result.  By introducing transit forwarding entries for the Rainbow FEC, we can use per-neighbor FEC-filtering machinery to
   advertise new profile without
   affecting the FEC-label binding transit forwarding entries for the Rainbow-FEC (and filter those
   for MRT-Blue and MRT-Red) to non-best-area neighbors of existing profile.
   Once the ABR.

   The new transit forwarding state has been verified, the router
   can be configured to use of the Rainbow-FEC alternates computed by the ABR for non-best-area
   advertisements is RECOMMENDED.  An ABR MAY advertise the label for new profile
   in the default topology in separate MRT-Blue and MRT-Red advertisements.
   However, event of a router that supports the LDP Label failure.

8.2.  Router-specific MRT Forwarding
   Mechanism MUST be able paramaters

   For some profiles, additional router-specific MRT parameters may need
   to receive and correctly interpret the
   Rainbow-FEC.

10.2.  ABR Forwarding Behavior with IP Tunneling (option 2)

   If IP tunneling is used, then the ABR/LBR behavior is dependent upon be advertised.  While the outermost IP address.  If set of options indicated by the outermost IP address is MRT
   Profile ID must be identical for all routers in an MRT
   loopback address of Island, these
   router-specific MRT parameters may differ between routers in the ABR/LBR, then same
   MRT island.  Several such parameters are described below.

   GADAG Root Selection Priority:   A GADAG Root Selection Policy MAY
      rely on the packet is decapsulated and
   forwarded based upon GADAG Root Selection Priority values advertised by
      each router in the inner IP address, which should go on MRT island.  A GADAG Root Selection Policy may
      use the
   default SPT topology.  If GADAG Root Selection Priority to allow network operators
      to configure a parameter to ensure that the outermost IP address GADAG root is not an MRT
   loopback address selected
      from a particular subset of routers.  An example of this use of
      the ABR/LBR, then GADAG Root Selection Priority value by the packet GADAG Root
      Selection Policy is simply forwarded
   along the associated forwarding topology.  A PLR sending traffic to a
   destination outside its local area/level will pick given in the Default MRT and use profile below.

   MRT-Red Loopback Address:   This provides the associated MRT router's loopback
      address of the selected ABR/LBR
   advertising the lowest cost to reach the external destination.

   Thus, for these two MRT Forwarding Mechanisms( MRT LDP Label option
   1A and IP tunneling option 2), there is no need for additional
   computation or per-area forwarding state.

10.3.  ABR Forwarding Behavior with LDP Label option 1B

   The other MRT forwarding mechanism described in Section 6 uses two
   labels, a topology-id label, and a FEC-label.  This mechanism would
   require that any router whose via the MRT-Red forwarding topology.
      It can be specified for either IPv4 or MRT-Blue next-hop IPv6.  Note that this
      parameter is an ABR/
   LBR would need not needed to determine whether support the ABR/LBR would forward Default MRT profile.

   MRT-Blue Loopback Address:   This provides the
   packet out of router's loopback
      address to reach the area/level.  If so, then that router should pop off via the topology-identification label before MRT-Blue forwarding the packet to the
   ABR/LBR.

   For example, in Figure 3, if node H fails, node E has to put traffic
   towards prefix p onto MRT-Red.  But since node D knows that ABR1 will
   use a best route from another area, it is safe topology.
      It can be specified for D to pop the
   Topology-Identification Label either IPv4 and just forward the packet IPv6.  Note that this
      parameter is not needed to ABR1
   along support the MRT-Red next-hop.  ABR1 Default MRT profile.

   Protocol extensions for advertising a router's GADAG Root Selection
   Priority value will use the shortest path be defined in Area
   10.

   In all cases for ISIS and most cases other documents.  Protocol
   extensions for OSPF, the penultimate router
   can determine what decision the adjacent ABR advertising a router's MRT-Red and MRT-Blue
   Loopback Addresses will make.  The one case
   where it can't be determined is when two ASBRs are in different non-
   backbone areas attached to defined elsewhere.

8.3.  Default MRT profile

   The following set of options defines the same ABR, then default MRT Profile.  The
   default MRT profile is indicated by the ASBR's Area MRT Profile ID may value of 0.

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

   MRT-Red MPLS MT-ID:   This value will be needed allocated from the MPLS
      Multi-Topology Identifiers Registry.  The IANA request for tie-breaking (prefer this
      allocation will be in another document.

   MRT-Blue MPLS MT-ID:   This value will be allocated from the route with MPLS
      Multi-Topology Identifiers Registry.  The IANA request for this
      allocation will be in another document.

   GADAG Root Selection Policy:   Among the largest OPSF
   area ID) routers in the MRT Island
      and with the Area ID isn't announced as part most preferred GADAG Root Selection Priority
      advertised (corresponding to the lowest numerical value of GADAG
      Root Selection Priority), an implementation MUST pick the ASBR link-
   state advertisement (LSA).  In this one case, suboptimal forwarding
   along router
      with the highest Router ID to be the GADAG root.

   Forwarding Mechanisms:   MRT LDP Labels

   Recalculation:   Recalculation of MRTs SHOULD occur as described in
      Section 12.2.  This allows the other area would happen.  If MRT forwarding topologies to
      support IP/LDP fast-reroute traffic.

   Area/Level Border Behavior:   As described in Section 10, ABRs/LBRs
      SHOULD ensure that becomes a
   realistic deployment scenario, OSPF traffic leaving the area also exits the MRT-Red
      or MRT-Blue forwarding topology.

9.  LDP signaling extensions could and considerations

   The protocol extensions for LDP will be considered.
   This is not covered defined in [I-D.ietf-ospf-mrt].

       +----[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 another document.
   A router must indicate that it has the ability to support MRT; having
   this explicit allows the use of MRT-specific processing, such as
   special handling of FECs sent with the Rainbow MRT in Area 0           (e) Red MT-ID.

   A FEC sent with the Rainbow MRT MT-ID indicates that the FEC applies
   to all the MRT-Blue and MRT-Red MT-IDs in Area supported MRT profiles.
   The FEC-label bindings for the default shortest-path based MT-ID 0

                Figure 3: ABR Forwarding Behavior and MRTs

11.  Prefixes Multiply Attached
   MUST still be sent (even though it could be inferred from the Rainbow
   FEC-label bindings) to ensure continuous operation of normal LDP
   forwarding.  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 to
   different LDP neighbors for the same FEC.  Because the Rainbow MRT
   MT-ID is used only by ABRs/LBRs or an LDP egress router, it is not
   MRT profile specific.

   The value of the Rainbow MRT MPLS MT-ID will be allocated from the
   MPLS Multi-Topology Identifiers Registry.  The IANA request for this
   allocation will be in another document.

10.  Inter-area Forwarding Behavior

   An ABR/LBR has two forwarding roles.  First, it forwards traffic
   within areas.  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 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 MRT-Blue and return
   to shortest path forwarding.

   For unicast MRT-FRR, the need to stay on an MRT forwarding topology
   terminates at the ABR/LBR whose best route is via a different area/
   level.  It is highly desirable to go back to the default forwarding
   topology when leaving an area/level.  There are three basic reasons
   for this.  First, the default topology uses shortest paths; the
   packet will thus take the shortest possible route to the destination.
   Second, this allows failures that might appear in multiple areas
   (e.g.  ABR/LBR failures) to be separately identified and repaired
   around.  Third, the packet can be fast-rerouted again, if necessary,
   due to a failure in a different area.

   An ABR/LBR that receives a packet on MRT-Red or MRT-Blue towards
   destination Z should continue to forward the packet along MRT-Red or
   MRT-Blue only if the best route to Z is in the same area as the
   interface that the packet was received on.  Otherwise, the packet
   should be removed from MRT-Red or 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 area
   arrive at the ABR/LBR already not marked as MRT-Red or MRT-Blue.

10.1.  ABR Forwarding Behavior with MRT LDP Label Option 1A

   For LDP forwarding where a single label specifies (MT-ID, FEC), the
   ABR/LBR is responsible for advertising the proper label to each
   neighbor.  Assume that an ABR/LBR has allocated three labels for a
   particular destination; those labels are L_primary, L_blue, and
   L_red.  To those routers in the same area as the best route to the
   destination, the ABR/LBR advertises the following FEC-label bindings:
   L_primary for the default topology, L_blue for the MRT-Blue MT-ID and
   L_red for the MRT-Red MT-ID, as expected.  However, to routers in
   other areas, the ABR/LBR advertises the following FEC-label bindings:
   L_primary for the default topology, and L_primary for the Rainbow MRT
   MT-ID.  Associating L_primary with the Rainbow MRT MT-ID causes the
   receiving routers to use L_primary for the MRT-Blue MT-ID and for the
   MRT-Red MT-ID.

   The ABR/LBR installs all next-hops for the 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 best area, packets from
   those neighbors will arrive at the ABR/LBR with a label L_primary and
   will be forwarded into the best area along the default topology.  By
   controlling what labels are advertised, the ABR/LBR can thus enforce
   that packets exiting the area do so on the shortest-path default
   topology.

10.1.1.  Motivation for Creating the Rainbow-FEC

   The desired forwarding behavior could be achieved in the above
   example without using the Rainbow-FEC.  This could be done by having
   the ABR/LBR advertise the following FEC-label bindings to neighbors
   not in the best area: L1_primary for the default topology, L1_primary
   for the MRT-Blue MT-ID, and L1_primary for the MRT-Red MT-ID.  Doing
   this would require machinery to spoof the labels used in FEC-label
   binding advertisements on a per-neighbor basis.  Such label-spoofing
   machinery does not currently exist in most LDP implmentations and
   doesn't have other obvious uses.

   Many existing LDP implmentations do however have the ability to
   filter FEC-label binding advertisements on a per-neighbor basis.  The
   Rainbow-FEC allows us to re-use the existing per-neighbor FEC
   filtering machinery to achieve the desired result.  By introducing
   the Rainbow FEC, we can use per-neighbor FEC-filtering machinery to
   advertise the FEC-label binding for the Rainbow-FEC (and filter those
   for MRT-Blue and MRT-Red) to non-best-area neighbors of the ABR.

   The use of the Rainbow-FEC by the ABR for non-best-area
   advertisements is RECOMMENDED.  An ABR MAY advertise the label for
   the default topology in separate MRT-Blue and MRT-Red advertisements.
   However, a router that supports the LDP Label MRT Forwarding
   Mechanism MUST be able to receive and correctly interpret the
   Rainbow-FEC.

10.2.  ABR Forwarding Behavior with IP Tunneling (option 2)

   If IP tunneling is used, then the ABR/LBR behavior is dependent upon
   the outermost IP address.  If the outermost IP address is an MRT
   loopback address of the ABR/LBR, then the packet is decapsulated and
   forwarded based upon the inner IP address, which should go on the
   default SPT topology.  If the outermost IP address is not an MRT
   loopback address of the 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 pick the MRT and use
   the associated MRT loopback address of the selected ABR/LBR
   advertising the lowest cost to the external destination.

   Thus, for these two MRT Forwarding Mechanisms (MRT LDP Label option
   1A and IP tunneling option 2), there is no need for additional
   computation or per-area forwarding state.

10.3.  ABR Forwarding Behavior with LDP Label option 1B

   The other MRT forwarding mechanism described in Section 6 uses two
   labels, a topology-id label, and a FEC-label.  This mechanism would
   require that any router whose MRT-Red or MRT-Blue next-hop is an ABR/
   LBR would need to determine whether the ABR/LBR would forward the
   packet out of the area/level.  If so, then that router should pop off
   the topology-identification label before forwarding the packet to the
   ABR/LBR.

   For example, in Figure 4, if node H fails, node E has to put traffic
   towards prefix p onto MRT-Red.  But since node D knows that ABR1 will
   use a best route from another area, it is safe for D to pop the
   Topology-Identification Label and just forward the packet to ABR1
   along the MRT-Red next-hop.  ABR1 will use the shortest path in Area
   10.

   In all cases for ISIS and most cases for OSPF, the penultimate router
   can determine what decision the 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 same ABR, then the ASBR's Area ID may
   be needed for tie-breaking (prefer the route with the largest OPSF
   area ID) and the Area ID isn't announced as part of the ASBR link-
   state advertisement (LSA).  In this one case, suboptimal forwarding
   along the MRT in the other area would happen.  If that becomes a
   realistic deployment scenario, protocol extensions could be developed
   to address this issue.

       +----[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

11.  Prefixes Multiply Attached to the MRT Island

   How a computing router S determines its local MRT Island for each
   supported MRT 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 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 profile for the MRT Island.

   The key difference is whether the traffic, once out of the MRT
   Island, might re-enter the MRT Island if a loop-free exit point is
   not selected.

   FRR using LFA has the useful property that it is able to protect
   multi-homed prefixes against ABR failure.  For instance, if a prefix
   from the backbone is available via both ABR A and ABR B, if A fails,
   then the traffic should be redirected to B.  This can be accomplished
   with MRT FRR as well.

   If ASBR protection is desired, this has additional complexities if
   the ASBRs are in different areas.  Similarly, protecting labeled BGP
   traffic in the event of an ASBR failure has additional complexities
   due to the 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.

   See Appendix A for a discussion of a general issue with multi-homed
   prefixes connected in two different areas.

   There are also two different approaches to protection.  The first is
   tunnel endpoint selection where the PLR picks a router to tunnel to
   where that router is loop-free with respect to the failure-point.
   Conceptually, the set of candidate routers to provide LFAs expands to
   all routers that can be reached via an MRT alternate, attached to the
   prefix.

   The second is to use a proxy-node, that can be named via MPLS label
   or IP address, and pick the appropriate label or IP address to reach
   it on either MRT-Blue or MRT-Red as appropriate to avoid the failure
   point.  A proxy-node can represent a destination prefix that can be
   attached to the 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
   an LDP FEC for the 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 attaching router; traffic is also explicitly
   forwarded from the attaching router along a predetermined interface
   towards the relevant prefixes.

   For IP traffic, multi-homed prefixes can use tunnel endpoint
   selection.  For IP traffic that is destined to a router outside the
   MRT Island, if that router is the egress for a FEC advertised into
   the MRT Island, then the named proxy-node approach can be used.

   For LDP traffic, there is always a FEC advertised into the MRT
   Island.  The named proxy-node approach should be used, unless the
   computing router S knows the label for the FEC at the selected tunnel
   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 FEC MUST also advertise labels
   for (MRT-Red, FEC) and (MRT-Blue, FEC) to neighbors inside the MRT
   Island.  Any router receiving a FEC corresponding to a router outside
   the MRT Island or to a multi-homed prefix MUST compute and install
   the transit MRT-Blue and MRT-Red next-hops for that FEC.  The FEC-
   label bindings for the topology-scoped FECs ((MT-ID 0, FEC), (MRT-
   Red, FEC), and (MRT-Blue, FEC)) MUST also be provided via LDP to
   neighbors inside the MRT Island.

11.1.  Protecting Multi-Homed Prefixes using Tunnel Endpoint Selection

   Tunnel 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 tunnel 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 S and the link (S, F) for link-protection.  If B will
   always prefer to send traffic to p via a different area/level, then
   this is definitional.  Otherwise, distance-based computations are
   necessary and an SPF from B's perspective may be necessary.  The
   following equations give the checks needed; the rationale is similar
   to that given in [RFC5286].

   Loop-Free for 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 the following, which avoids the need to
   compute the shortest path from F to p.

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

   Finally, the rules for Endpoint selection are given below.  The basic
   idea is to repair to the prefix-advertising router selected for the
   shortest-path and only to select and tunnel to a different 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 packet to A along that alternate.  For example,
       if LDP is the forwarding mechanism, then push the label (MRT-Red,
       A) or (MRT-Blue, A) onto the 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 MRT Island

   How label (MRT-Red, B) or (MRT-Blue, B) onto the 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 computing router B that is loop-free to reach p
       while avoiding S determines its local and the link from S to F?  If so, select B as
       the endpoint and the MRT Island alternate for each
   supported MRT profile is already discussed in Section 7.

   There are two types of prefixes or FECs reaching B from S that may be multiply attached
   to an MRT Island.
       avoid the link (S,F).

   The first type are multi-homed prefixes that
   usually connect at tunnel endpoint selected will receive a domain or protocol boundary.  The second type
   represent routers that do not support packet destined to itself
   and, being the profile egress, will pop that MPLS label (or have signaled
   Implicit Null) and forward based on what is underneath.  This
   suffices for IP traffic since the MRT Island.

   The key difference is whether tunnel endpoint can use the traffic, once out IP
   header of the MRT
   Island, remains in original packet to continue forwarding the same area/level and might re-enter packet.
   However, tunnelling of LDP traffic requires targeted LDP sessions for
   learning the MRT
   Island if a loop-free exit point is not selected.

   FRR FEC-label binding at the tunnel endpoint.

11.2.  Protecting Multi-Homed Prefixes using LFA has Named Proxy-Nodes

   Instead, the useful property named proxy-node method works with LDP traffic without
   the need for targeted LDP sessions.  It also has a clear advantage
   over tunnel endpoint selection, in that it is able possible to protect
   multi-homed prefixes against ABR failure.  For instance, if a prefix explicitly
   forward from the backbone is available via both ABR A and ABR B, if A fails,
   then the traffic should be redirected to B.  This can be accomplished
   with MRT FRR as well.

   If ASBR protection is desired, this has additional complexities if
   the ASBRs are in different areas.  Similarly, protecting labeled BGP
   traffic in the event of Island along an ASBR failure has additional complexities
   due interface to the 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 loop-free island
   neighbor when that interface may not be a primary next-hop.

   A named proxy-node represents one ABR,

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

   o  A prefix destinations and, for LDP
   forwarding, has a FEC associated with iBGP multipath to different ASBRs,

   o  etc.

   There are also two different approaches to protection.  The first it that is
   tunnel endpoint selection where signalled into the PLR picks a router
   MRT Island.  Therefore, it is possible to tunnel explicitly label packets to
   where that router is loop-free with respect
   go to (MRT-Red, FEC) or (MRT-Blue, FEC); at the failure-point.
   Conceptually, the set border of candidate routers to provide LFAs expands to
   all routers that can be reached via an the MRT alternate, attached to
   Island, the
   prefix.

   The second is label will swap to use a proxy-node, that can meaning (MT-ID 0, FEC).  It would be
   possible to have named via MPLS label
   or proxy-nodes for IP address, and pick the appropriate label or forwarding, but this would
   require extensions to signal two IP address addresses to reach
   it on either MRT-Blue or be associated with
   MRT-Red as appropriate to avoid and MRT-Blue for the failure
   point. proxy-node.  A named proxy-node can represent a destination prefix that can be
   attached to
   uniquely represented by the two routers in the 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 which it
   is
   an LDP FEC for the associated prefix or because MRT-Red and MRT-Blue connected.  The extensions to signal such IP addresses are advertised (in an as-yet undefined fashion) for that
   proxy-node.  Traffic will be
   defined elsewhere.  The details of what label-bindings must be
   originated will be described in another document.

   Computing the MRT next-hops to a named proxy-node may take a different path
   than traffic to and the attaching router; traffic is also explicitly
   forwarded from MRT
   alternate for the attaching computing router along S to avoid a predetermined interface
   towards particular failure
   node F is straightforward.  The details of the relevant prefixes.

   For IP traffic, multi-homed prefixes can use tunnel endpoint
   selection.  For IP traffic that simple constant-time
   functions, Select_Proxy_Node_NHs() and
   Select_Alternates_Proxy_Node(), are given in
   [I-D.ietf-rtgwg-mrt-frr-algorithm].  A key point is destined to that computing
   these MRT next-hops and alternates can be done as new named proxy-
   nodes are added or removed without requiring a router outside the new MRT Island, if that router computation or
   impacting other existing MRT paths.  This maps very well to, for
   example, how OSPFv2 (see [RFC2328] Section 16.5) does incremental
   updates for new summary-LSAs.

   The remaining question is how to attach the named proxy-node to the egress for a FEC advertised into
   MRT Island; all the routers in the MRT Island, then Island MUST do this
   consistently.  No more than 2 routers in the named proxy-node approach MRT Island can be used.

   For LDP traffic,
   selected; one should only be selected if there is always a FEC advertised into are no others that
   meet the MRT
   Island. necessary criteria.  The named proxy-node approach should be used, unless the
   computing router S knows is logically part
   of the label area/level.

   There are two sources for the FEC at the selected tunnel
   endpoint.

   If a FEC is advertised from outside candidate routers in the MRT Island into to
   connect to the named proxy-node.  The first set are those routers in
   the MRT Island and the forwarding mechanism specified in that are advertising the profile includes
   LDP, then prefix; the routers learning that FEC MUST also advertise labels
   for (MRT-Red, FEC) and (MRT-Blue, FEC) named-proxy-cost
   assigned to neighbors inside the MRT
   Island.  Any each prefix-advertising router receiving a FEC corresponding is the announced cost to a router outside
   the prefix.  The second set are those routers in the MRT Island or that
   are connected to a multi-homed prefix MUST compute and install routers not in the transit MRT-Blue and MRT-Red next-hops for that FEC.  The FEC-
   label bindings for MRT Island but in the topology-scoped FECs ((MT-ID 0, FEC), (MRT-
   Red, FEC), and (MRT-Blue, FEC)) MUST also same area/
   level; such routers will be provided via LDP defined as Island Border Routers (IBRs).
   The routers connected to
   neighbors inside the MRT Island.

11.1.  Protecting Multi-Homed Prefixes using Tunnel Endpoint Selection

   Tunnel endpoint selection is a local matter for a router IBRs that are not in the MRT Island and
   are in the same area/level as the MRT island are Island since it pertains
   Neighbors(INs).

   Since packets sent to selecting and using an alternate and does
   not affect the transit named proxy-node along MRT-Red and or MRT-Blue forwarding topologies.

   Let the computing
   may come from any router be S and the next-hop F be inside the node whose
   failure MRT Island, it is to be avoided.  Let the destination be prefix p.  Have A
   be the necessary that
   whatever router to which an IBR forwards the prefix p is attached for S's shortest path packet be loop-free with
   respect to p.

   The candidates the whole MRT Island for tunnel endpoint selection are those to which the
   destination prefix destination.  Thus, an IBR is attached in the area/level.  For
   a particular candidate B, it is necessary to determine router only if B is loop-free to reach
   p with respect to S and F for node-protection or it possesses at least with
   respect to S and the link (S, F) for link-protection.  If B will
   always prefer to send traffic to p via a different area/level, then
   this is definitional.  Otherwise, distance-based computations are
   necessary and an SPF from B's perspective may be necessary.  The
   following equations give the checks needed; the rationale is similar
   to that given in [RFC5286].

   Loop-Free for 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 the following, which avoids the need to
   compute the one IN whose
   shortest path from F to p.

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

   Finally, the rules prefix does not enter the MRT Island.  A method
   for Endpoint selection are identifying loop-free Island Neighbors(LFINs) is given below. in
   [I-D.ietf-rtgwg-mrt-frr-algorithm].  The basic
   idea is to repair named-proxy-cost assigned to
   each (IBR, IN) pair is cost(IBR, IN) + D_opt(IN, prefix).

   From the set of prefix-advertising router selected for the
   shortest-path and only to select routers and tunnel to a different 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 set of IBRs with
   at least one LFIN, the packet to A along that alternate. two routers with the lowest named-proxy-cost
   are selected.  Ties are broken based upon the lowest Router ID.  For example,
       if LDP is
   ease of discussion, the two selected routers will be referred to as
   proxy-node attachment routers.

   A proxy-node attachment router has a special forwarding mechanism, then push the label role.  When a
   packet is received destined to (MRT-Red,
       A) prefix) or (MRT-Blue, A) onto
   prefix), if the packet.

   2.  If not, then is there a proxy-node attachment 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 an IBR, it MUST swap
   to reach B while avoiding F.  Tunnel the packet shortest path forwarding topology (e.g. swap to B along that alternate.  For example, with LDP,
       push the label (MRT-Red, B) for
   (MT-ID 0, prefix) or (MRT-Blue, B) onto remove the packet.

   3.  If not, then does S have a link-protecting alternate outer IP encapsulation) and forward
   the packet to A?  If
       so, select that.

   4. the IN whose cost was used in the selection.  If not, then is there a the
   proxy-node attachment router B that is loop-free to reach p
       while avoiding S and not an IBR, then the link packet MUST be
   removed from S to F?  If so, select B as the endpoint MRT forwarding topology and sent along the MRT alternate for reaching B from S
   interface(s) that
       avoid caused the link (S,F).

   The tunnel endpoint selected will receive a packet destined router to itself
   and, being advertise the egress, will pop that MPLS label (or have signaled
   Implicit Null) and forward based on what is underneath.  This
   suffices prefix; this
   interface might be out of the area/level/AS.

11.3.  MRT Alternates for IP traffic since Destinations Outside the tunnel endpoint can use MRT 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 IP
   header case of the original packet
   MRT FRR, where it provides alternates when appropriate LFAs aren't
   available, there are also deployment scenarios where it may make
   sense to only enable some routers in an area with MRT FRR.  A simple
   example of such a scenario would be a ring of 6 or more routers that
   is connected via two routers to continue forwarding the packet.
   However, tunnelling rest of LDP traffic requires targeted LDP sessions for
   learning the FEC-label binding at area.

   Destinations inside the tunnel endpoint.

11.2.  Protecting Multi-Homed Prefixes using local island can obviously use MRT
   alternates.  Destinations outside the local island can be treated
   like a multi-homed prefix and either Endpoint Selection or Named
   Proxy-Nodes can be used.  Named Proxy-Nodes

   Instead, the named proxy-node method works with LDP traffic without
   the need for targeted MUST be supported when
   LDP sessions.  It also has forwarding is supported and a clear advantage
   over tunnel endpoint selection, in that it label-binding for the destination
   is possible sent to explicitly
   forward from the MRT Island along an interface to a loop-free island
   neighbor when that interface may not be a primary next-hop.

   A named proxy-node represents one or IBR.

   Naturally, there are more destinations and, complicated options to improve coverage,
   such as connecting multiple MRT islands across tunnels, but the need
   for LDP
   forwarding, the additional complexity has not been justified.

12.  Network Convergence and Preparing for the Next Failure

   After a FEC associated with it failure, MRT detours ensure that is signalled into 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 Island.  Therefore, it re-calculation.

12.1.  Micro-loop prevention and MRTs

   A micro-loop is possible to explicitly label packets to
   go to (MRT-Red, FEC) a transient packet forwarding loop among two or (MRT-Blue, FEC); at the border more
   routers that can occur during convergence of the MRT
   Island, the label will swap to meaning (MT-ID 0, FEC).  It would be
   possible to have named proxy-nodes IGP forwarding state.
   [RFC5715] discusses several techniques for IP forwarding, but this would
   require extensions preventing micro-loops.
   This section discusses how MRT-FRR relates to signal two IP addresses of the micro-loop
   prevention techniques discussed in [RFC5715], Nearside Tunneling and
   Farside Tunneling.

   In Nearside Tunneling, a router (PLR) adjacent to be associated with
   MRT-Red a failure perform
   local repair and MRT-Blue for inform remote routers of the proxy-node.  A named proxy-node can be
   uniquely represented failure.  The remote
   routers initially tunnel affected traffic to the nearest PLR, using
   tunnels which are unaffected by the two failure.  Once the forwarding
   state for normal shortest path routing has converged, the remote
   routers in return the MRT Island traffic to which it shortest path forwarding.  MRT-FRR is connected.
   relevant for Nearside Tunneling for the following reason.  The extensions
   process of tunneling traffic to signal such IP addresses are not
   defined in [I-D.ietf-ospf-mrt].  The details the PLRs and waiting a sufficient
   amount of what label-bindings
   must time for IGP forwarding state convergence with Nearside
   Tunneling means that traffic will generally be originated are described relying on the local
   repair at the PLR for longer than it would in [I-D.ietf-mpls-ldp-mrt].

   Computing the MRT next-hops to a named proxy-node absence of Nearside
   Tunneling.  Since MRT-FRR provides 100% coverage for single link and
   node failure, it may be an attractive option to provide the MRT
   alternate local
   repair paths when Nearside Tunneling is deployed.

   MRT-FRR is also relevant for the computing router S to avoid Farside Tunneling micro-loop
   prevention technique.  In Farside Tunneling, remote routers tunnel
   traffic affected by a particular failure to a node F is straightforward.  The details downstream of the simple constant-time
   functions, Select_Proxy_Node_NHs() and
   Select_Alternates_Proxy_Node(), are given in
   [I-D.ietf-rtgwg-mrt-frr-algorithm].  A key point is that computing
   these MRT next-hops and alternates failure
   with respect to traffic destination.  This node can be done viewed 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
   example, how OSPFv2 (see [RFC2328] Section 16.5) does incremental
   updates for new summary-LSAs.

   The remaining question is how to attach
   being on the farside of the named proxy-node failure with respect to the
   MRT Island; all node
   initiating the routers in tunnel.  Note that the MRT Island MUST do this
   consistently.  No more than 2 routers discussion of Farside Tunneling
   in [RFC5715] focuses on the MRT Island can be
   selected; one should only be selected if there are no others that
   meet case where the necessary criteria.  The named proxy-node farside node is logically part
   of
   immediately adjacent to a failed link or node.  However, the area/level.

   There are two sources for candidate routers in farside
   node may be any node downstream of the MRT Island failure with respect to
   connect
   traffic destination, including the destination itself.  The tunneling
   mechanism used to reach the named proxy-node. farside node must be unaffected by the
   failure.  The first set are those routers in alternative forwarding paths created by MRT-FRR have
   the MRT Island that are advertising potential to be used to forward traffic from the prefix; remote routers
   upstream of the named-proxy-cost
   assigned failure all the way to each prefix-advertising router is the announced cost destination.  In the event
   of failure, either the MRT-Red or MRT-Blue path from the remote
   upstream router to the prefix. destination is guaranteed to avoid a link
   failure or inferred node failure.  The second set are those routers in the MRT Island that forwarding paths are connected also
   guaranteed to routers not in the MRT Island but in the same area/
   level; such routers will be defined as Island Border Routers (IBRs).
   The routers connected subject to micro-loops because they are locked
   to the IBRs topology before the failure.

   We note that are not in the MRT Island and
   are computations in [I-D.ietf-rtgwg-mrt-frr-algorithm]
   address the same area/level as the MRT island are Island
   Neighbors(INs).

   Since packets sent case of a PLR adjacent to the named proxy-node along a failure determining which
   choice of MRT-Red or MRT-Blue will avoid a failed link or node.  More
   computation may come from any router inside the MRT Island, it is necessary that
   whatever be required for an arbitrary remote upstream router
   to which an IBR forwards the packet be loop-free with
   respect determine whether to choose MRT-Red or MRT-Blue for a given
   destination and failure.

12.2.  MRT Recalculation for the whole Default MRT Island Profile

   This section describes how the MRT recalculation SHOULD be performed
   for the destination.  Thus, an IBR Default MRT Profile.  This is intended to support FRR
   applications.  Other approaches are possible, but they are not
   specified in this document.

   When a candidate failure event happens, traffic is put by the PLRs onto the MRT
   topologies.  After that, each router only if it possesses at least one IN whose recomputes its shortest path
   tree (SPT) and moves traffic over to that.  Only after all the prefix does not enter the MRT Island.  A method
   for identifying loop-free Island Neighbors(LFINs) is given in
   [I-D.ietf-rtgwg-mrt-frr-algorithm].  The named-proxy-cost assigned PLRs
   have switched to
   each (IBR, IN) pair is cost(IBR, IN) + D_opt(IN, prefix).

   From the set of prefix-advertising routers using their SPTs and traffic has drained from the set of IBRs with
   at least one LFIN, the two routers with the lowest named-proxy-cost
   are selected.  Ties are broken based upon
   MRT topologies should each router install the lowest Router ID.  For
   ease of discussion, recomputed MRTs into
   the two selected routers will be referred to as
   proxy-node attachment routers.

   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 FIBs.

   At each router, therefore, the proxy-node attachment router sequence is an IBR, it MUST swap
   to as follows:

   1.  Receive failure notification

   2.  Recompute SPT.

   3.  Install the shortest path forwarding topology (e.g. swap to new SPT in the label for
   (MT-ID 0, prefix) or remove FIB.

   4.  If the outer IP encapsulation) and forward network was stable before the packet failure occured, wait a
       configured (or advertised) period for all routers to be using
       their SPTs and traffic to drain from the IN whose cost was used MRTs.

   5.  Recompute MRTs.

   6.  Install new MRTs in the selection.  If FIB.

   While the
   proxy-node attachment router is recomputed MRTs are not an IBR, then installed in the packet MUST be
   removed from FIB, protection
   coverage is lowered.  Therefore, it is important to recalculate the MRT forwarding topology
   MRTs and sent along the
   interface(s) that caused install them quickly.

   New protocol extensions for advertising the router time needed to advertise recompute
   shortest path routes and install them in the prefix; this
   interface might FIB will be out defined
   elsewhere.

13.  Implementation Status

   [RFC Editor: please remove this section prior to publication.]

   This section records the status of known implementations of the area/level/AS.

11.3.  MRT Alternates for Destinations Outside
   protocol defined by this specification at the MRT Island

   A natural concern with new functionality is how to have it be useful
   when it time of posting of this
   Internet-Draft, and is not deployed across an entire IGP area.  In the case based on a proposal described in [RFC6982].
   The description of
   MRT FRR, where it provides alternates when appropriate LFAs aren't
   available, there are also deployment scenarios where it may make
   sense implementations in this section is intended to only enable some routers
   assist the IETF in an area with MRT FRR.  A simple
   example its decision processes in progressing drafts to
   RFCs.  Please note that the listing of such a scenario would any individual implementation
   here does not imply endorsement by the IETF.  Furthermore, no effort
   has been spent to verify the information presented here that was
   supplied by IETF contributors.  This is not intended as, and must not
   be construed to be, a ring catalog of 6 available implementations or more routers their
   features.  Readers are advised to note that
   is connected via two routers other implementations may
   exist.

   According to [RFC6982], "this will allow reviewers and working groups
   to assign due consideration to documents that have the rest benefit of
   running code, which may serve as evidence of valuable experimentation
   and feedback that have made the area.

   Destinations inside implemented protocols more mature.
   It is up to the local island can obviously individual working groups to use MRT
   alternates.  Destinations outside this information as
   they see fit".

   Juniper Networks Implementation

   o  Organization responsible for the local island can be treated
   like a multi-homed prefix implementation: Juniper Networks

   o  Implementation name: MRT-FRR

   o  Implementation description: MRT-FRR using OSPF as the IGP has been
      implemented and either Endpoint Selection or Named
   Proxy-Nodes can be used.  Named Proxy-Nodes MUST be supported when
   LDP forwarding is supported verified.

   o  The implementation's level of maturity: prototype

   o  Protocol coverage: This implementation of the MRT-FRR includes
      Island identification, GADAG root selection, MRT Lowpoint
      algorithm, augmentation of GADAG with additional links, and a label-binding for
      calculation of MRT transit next-hops alternate next-hops based on
      draft "draft-ietf-rtgwg-mrt-frr-algorithm-00".  This
      implementation also includes the destination
   is sent to an IBR.

   Naturally, there are more complicated options to improve coverage,
   such M-bit in OSPF based on "draft-
      atlas-ospf-mrt-01" as connecting multiple well as LDP MRT islands across tunnels, but the need Capability based on "draft-
      atlas-mpls-ldp-mrt-00".

   o  Licensing: proprietary
   o  Implementation experience: Implementation was useful for the additional complexity verifying
      functionality and lack of gaps.  It has not also been justified.

12.  Network Convergence and Preparing useful for
      improving aspects of 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 algorithm.

   o  Contact information: akatlas@juniper.net, shraddha@juniper.net,
      kishoret@juniper.net

   Huawei Technology Implementation

   o  Organization responsible for the new shortest paths.  Two things need attention: micro-loop
   prevention implementation: Huawei Technology
      Co., Ltd.

   o  Implementation name: MRT-FRR and IS-IS extensions for MRT.

   o  Implementation description: The MRT-FRR using IS-IS extensions for
      MRT re-calculation.

12.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 LDP multi-topology have been implemented and verified.

   o  The implementation's level of maturity: prototype

   o  Protocol coverage: This implementation of the failure.  Managing micro-loops is an orthogonal issue to having
   alternates MRT algorithm
      includes Island identification, GADAG root selection, MRT Lowpoint
      algorithm, augmentation of GADAG with additional links, and
      calculation of MRT transit next-hops alternate next-hops based on
      draft "draft-enyedi-rtgwg-mrt-frr-algorithm-03".  This
      implementation also includes IS-IS extension for local repair, such as MRT fast-reroute provides.

   There are two possible micro-loop prevention mechanisms discussed in
   [RFC5715].  The first based on
      "draft-li-mrt-00".

   o  Licensing: proprietary

   o  Implementation experience: It is Ordered FIB [RFC6976].  The important produce a second
      implementation to verify the algorithm is
   Farside Tunneling which requires tunnels or an alternate topology implemented correctly
      without looping.  It is important to
   reach routers on verify the farside ISIS extensions
      work for MRT-FRR.

   o  Contact information: lizhenbin@huawei.com, eric.wu@huawei.com

14.  Operational Considerations

   The following aspects of MRT-FRR are useful to consider when
   deploying the failure.

   Since MRTs provide an alternate topology through which traffic can be
   sent technology in different operational environments and which can be manipulated separately from the SPT, it is
   possible that MRTs could be
   network topologies.

14.1.  Verifying Forwarding on MRT Paths

   The forwarding paths created by MRT-FRR are not used by normal (non-
   FRR) traffic.  They are only used to support Farside Tunneling.
   Details carry FRR traffic for a short
   period of how time after a failure has been detected.  It is RECOMMENDED
   that an operator proactively monitor the MRT forwarding paths in
   order to do so are outside be certain that the scope of this document.

   Micro-loop mitigation mechanisms can also work paths will be able to carry FRR traffic
   when combined needed.  Therefore, an implementation SHOULD provide an operator
   with
   MRT.

12.2.  MRT Recalculation for the Default ability to test MRT Profile

   This section describes how the paths with OAM traffic.  For example,
   when MRT recalculation SHOULD be performed paths are realized using LDP labels distributed for
   topology-scoped FECs, an implementation can use the Default MRT Profile.  This is intended to support FRR
   applications.  Other approaches are possible, but they are not
   specified MPLS ping and
   traceroute as defined in this document.

   When [RFC4379] and extended in [RFC7307] for
   topology-scoped FECs.

14.2.  Traffic Capacity on Backup Paths

   During a failure fast-reroute event happens, initiated by a PLR in response to a
   network failure, the flow of traffic is put by in the PLRs onto network will generally
   not be identical to the MRT
   topologies.  After that, each router recomputes its shortest path
   tree (SPT) and moves flow of traffic over to that.  Only after all the PLRs IGP forwarding
   state has converged, taking the failure into account.  Therefore,
   even if a network has been engineered to have switched enough capacity on the
   appropriate links to using their SPTs and carry all traffic after the IGP has drained from converged
   after the
   MRT topologies should each router install failure, the recomputed MRTs into network may still not have enough capacity on
   the FIBs.

   At each router, therefore, appropriate links to carry the sequence flow of traffic during a fast-
   reroute event.  This can result in more traffic loss during the fast-
   reroute event than might otherwise be expected.

   Note that there are two somewhat distinct aspects to this phenomenon.
   The first is as follows:

   1.  Receive failure notification

   2.  Recompute SPT

   3.  Install new SPT

   4.  If that the network was stable before path from the failure occured, wait a
       configured (or advertised) period for all routers PLR to the destination during the
   fast-reroute event may be using
       their SPTs and traffic to drain different from the MRTs.

   5.  Recompute MRTs
   6.  Install new MRTs.

   While path after the recomputed MRTs are not installed in IGP
   converges.  In this case, any traffic for the FIB, protection
   coverage is lowered.  Therefore, it is important to recalculate destination that
   reaches the
   MRTs and install them quickly.

13.  Implementation Status

   [RFC Editor: please remove this section prior PLR during the fast-reroute event will follow a different
   path from the PLR to publication.]

   This section records the status of known implementations destination than will be followed after IGP
   convergence.

   The second aspect is that the amount of the
   protocol defined by this specification traffic arriving at the time of posting PLR
   for affected destinations during the fast-reroute event may be larger
   than the amount of this
   Internet-Draft, and is based on traffic arriving at the PLR for affected
   destinations after IGP convergence.  Immediately after a proposal described in [RFC6982].
   The description of implementations in this section is intended failure, any
   non-PLR routers that were sending traffic to
   assist the IETF in its decision processes in progressing drafts PLR before the
   failure will continue sending traffic to
   RFCs.  Please note the PLR, and that traffic
   will be carried over backup paths from the listing of any individual implementation
   here does not imply endorsement by PLR to the IETF.  Furthermore, no effort
   has been spent destinations.
   After IGP convergence, upstream non-PLR routers may direct some
   traffic away from the PLR.

   In order to verify reduce or eliminate the information presented here potential for transient traffic
   loss due to inadequate capacity during fast-reroute events, an
   operator can model the amount of traffic taking different paths
   during a fast-reroute event.  If it is determined that was
   supplied by IETF contributors.  This there is not intended as, and must not
   be construed
   enough capacity to be, support a catalog of available implementations given fast-reroute event, the operator
   can address the issue either by augmenting capacity on certain links
   or their
   features.  Readers are advised modifying the backup paths themselves.

   The MRT Lowpoint algorithm produces a pair of diverse paths to note that other implementations may
   exist.

   According each
   destination.  These paths are generated by following the directed
   links on a common GADAG.  MRT-FRR allows an operator to [RFC6982], "this will allow reviewers exclude a
   link from the MRT Island, and working groups
   to assign due consideration to documents that have thus the GADAG, by advertising it as
   MRT-Ineligible.  Such a link will not be used on the benefit of
   running code, which may serve MRT forwarding
   path for any destination.  Advertising links as evidence MRT-Ineligible is the
   main tool provided by MRT-FRR for keeping backup traffic off of valuable experimentation
   and feedback lower
   bandwidth links during fast-reroute events.

   Note that have made all of the implemented protocols more mature.
   It is up to backup paths produced by the individual working groups MRT Lowpoint
   algorithm are closely tied to use this information as
   they see fit".

   Juniper Networks Implementation

   o  Organization responsible for the implementation: Juniper Networks

   o  Implementation name: MRT-FRR algorithm

   o  Implementation description: The MRT-FRR algorithm using OSPF common GADAG computed as
      the IGP has been implemented and verified.

   o  The implementation's level part of maturity: prototype

   o  Protocol coverage:
   that algorithm.  Therefore, it is generally not possible to modify a
   subset of paths without affecting other paths.  This implementation precludes more
   fine-grained modification of individual backup paths when using only
   paths computed by the MRT algorithm
      includes Island identification, GADAG root selection, Lowpoint
      algorithm, augmentation of GADAG algorithm.

   However, it may be desirable to allow an operator to use MRT-FRR
   alternates together with additional links, and
      calculation of MRT transit next-hops alternates provided by other FRR
   technologies.  A policy-based alternate next-hops based on
      draft "draft-ietf-rtgwg-mrt-frr-algorithm-00".  This
      implementation also includes selection process can allow
   an operator to select the M-bit in OSPF based on "draft-
      atlas-ospf-mrt-01" as well as LDP best alternate from those provided by MRT Capability based on "draft-
      atlas-mpls-ldp-mrt-00".

   o  Licensing: proprietary

   o  Implementation experience: Implementation was useful for verifying
      functionality
   and lack of gaps.  It has also been useful other FRR technologies.  As a concrete example, it may be
   desirable to implement a policy where a downstream LFA (if it exists
   for
      improving aspects of a given failure mode and destination) is preferred over a given
   MRT alternate.  This combination gives the algorithm.

   o  Contact information: akatlas@juniper.net, shraddha@juniper.net,
      kishoret@juniper.net

   Huawei Technology Implementation

   o  Organization responsible for operator the implementation: Huawei Technology
      Co., Ltd.

   o  Implementation name: MRT-FRR algorithm and IS-IS extensions for
      MRT.

   o  Implementation description: The MRT-FRR algorithm, IS-IS
      extensions ability to
   affect where traffic flows during a fast-reroute event, while still
   producing backup paths that use no additional labels for MRT and LDP multi-topology have been implemented traffic
   and verified.

   o  The implementation's level of maturity: prototype

   o  Protocol coverage: will not loop under multiple failures.  This implementation and other choices of
   alternate selection policy can be evaluated in the MRT algorithm
      includes Island identification, GADAG root selection, Lowpoint
      algorithm, augmentation context of GADAG with additional links, their
   effect on fast-reroute traffic flow and
      calculation of available capacity, as well
   as other deployment considerations.

   Note that future documents may define MRT transit next-hops alternate next-hops based on
      draft "draft-enyedi-rtgwg-mrt-frr-algorithm-03".  This
      implementation also includes IS-IS extension for profiles in addition to the
   default profile defined here.  Different MRT based on
      "draft-li-mrt-00".

   o  Licensing: proprietary

   o  Implementation experience: It is important profiles will generally
   produce a second alternate paths with different properties.  An implementation
   may allow an operator to verify the algorithm is implemented correctly
      without looping.  It is important use different MRT profiles instead of or in
   addition to verify the ISIS extensions
      work for MRT-FRR.

   o  Contact information: lizhenbin@huawei.com, eric.wu@huawei.com

14.  Operations and default profile.

14.3.  MRT IP Tunnel Loopback Address Management Considerations

   An

   As described in Section 6.1.2, if an implementation SHOULD provide uses IP tunneling
   as the mechanism to realize MRT forwarding paths, each node must
   advertise an operator with MRT-Red and an MRT-Blue loopback address.  These IP
   addresses must be unique within the ability routing domain to test
   MRT paths the extent that
   they do not overlap with OAM traffic.  For example, when MRT paths are realized
   using LDP labels distributed for topology-scoped FECs, an
   implementation can each other or with any other routing table
   entries.  It is expected that operators will use the MPLS ping existing tools and traceroute as defined
   processes for managing infrastructure IP addresses to manage these
   additional MRT-related loopback addresses.

14.4.  MRT-FRR in
   [RFC4379] and extended a Network with Degraded Connectivity

   Ideally, routers is a service provider network using MRT-FRR will be
   initially deployed in [RFC7307] for topology-scoped FECs.

15.  Applying Policy a 2-connected topology, allowing MRT-FRR to
   find completely diverse paths to Select all destinations.  However, a
   network can differ from Multiple Possible Alternates an ideal 2-connected topology for FRR

   For a given topology, GADAG root, many
   possible reasons, including network failures and profile, MRT planned maintenance
   events.

   MRT-FRR is designed to continue to function properly when network
   connectivity is degraded.  When a network contains cut-vertices or
   cut-links dividing the network into different 2-connected blocks,
   MRT-FRR will continue to provide completely diverse paths for
   destinations within the same block as the PLR.  For a
   node-protecting alternate path from each PLR to each destination for
   any single link or node failure, if such in
   a path exists.  Therefore,
   an implementation may choose to only use different block from the alternates determined PLR, the redundant paths created by
   MRT to provide 100% MRT-
   FRR coverage.

   However, it may will be desirable link and node diverse within each block, and the paths
   will only share links and nodes that are cut-links or cut-vertices in
   the topology.

   If a network becomes partitioned with one set of routers having no
   connectivity to allow an operator another set of routers, MRT-FRR will function
   independently in each set of connected routers, providing redundant
   paths to use MRT
   alternates together with alternates provided by other FRR
   technologies. destinations in same set of connected routers as a given
   PLR.

14.5.  Partial Deployment of MRT-FRR in a Network

   A policy-based alternate selection process can allow
   an network operator to select the best alternate from those provided by MRT
   and other FRR technologies.  As an example, it may be desirable choose to
   implement a policy where deploy MRT-FRR only on a node-protecting LFA (if it exists subset of
   routers in an IGP area.  MRT-FRR is designed to accommodate this
   partial deployment scenario.  Only routers that advertise support for
   a given failure mode and destination) is preferred over MRT profile will be included in a given MRT
   alternate.  [I-D.ietf-rtgwg-lfa-manageability] discusses many of Island.  For a
   PLR within the
   potential criteria that one might take into account when evaluating
   different alternates for selection.

   Note that future documents may define MRT profiles in addition Island, MRT-FRR will create redundant forwarding
   paths to all destinations with the
   default profile defined here.  Different MRT profiles will generally
   produce alternate Island using maximally
   redundant trees all the way to those destinations.  For destinations
   outside of the MRT Island, MRT-FRR creates paths with different properties.  An implementation
   may allow an operator to the destination
   which use different forwarding state created by MRT-FRR within the MRT profiles instead Island
   and shortest path forwarding state outside of or in
   addition the MRT Island.  The
   paths created by MRT-FRR to non-Island destinations are guaranteed to
   be diverse within the default profile.

16. MRT Island (if topologically possible).
   However, the part of the paths outside of the MRT Island may not be
   diverse.

15.  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, Ted
   Qian, Kishore Tiruveedhula, Shraddha Hegde, Santosh Esale, Nitin
   Bahadur, Harish Sitaraman, Raveendra Torvi, Anil Kumar SN, Bruno
   Decraene, Eric Wu, and Janos Farkas Farkas, Rob Shakir, and Stewart Bryant for
   their suggestions and review.

17.

16.  IANA Considerations

   Please create an MRT Profile

   IANA is requested to create a registry for the MRT entitled "MRT Profile TLV.
   Identifier Registry".  The range is 0 to 255.  The default Default MRT
   Profile defined in this document has value 0.  Values 1-200 are
   allocated by Standards Action.  Values 201-220 are for
   experimentation.  Values 221-255 are for vendor private use.

18.

17.  Security Considerations

   In general, MRT forwarding paths do not follow shortest paths.  The
   transit forwarding state corresponding to the MRT paths is created
   during normal operations (before a failure occurs).  Therefore, a
   malicious packet with an appropriate header injected into the network
   from a compromised location would be forwarded to a destination along
   a non-shortest path.  When this technology is deployed, a network
   security design should not rely on assumptions about potentially
   malicious traffic only following shortest paths.

   It should be noted that the creation of non-shortest forwarding paths
   is not unique to MRT.

19.

   MRT-FRR requires that routers advertise information used in the
   formation of MRT backup paths.  While this document does not specify
   the protocol extensions used to advertise this information, we
   discuss security considerations related to the information itself.
   Injecting false MRT-related information could be used to direct some
   MRT backup paths over compromised transmission links.  Combined with
   the ability to generate network failures, this could be used to send
   traffic over compromised transmission links during a fast-reroute
   event.  In order to prevent this potential exploit, a receiving
   router needs to be able to authenticate MRT-related information that
   claims to have been advertised by another router.

18.  Contributors
      Robert Kebler
      Juniper Networks
      10 Technology Park Drive
      Westford, MA  01886
      USA
      Email: rkebler@juniper.net

      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

      Russ White
      VCE
      Email: russw@riw.us

20.

19.  References

20.1.

19.1.  Normative References

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

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

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

20.2.

19.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-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-02 (work in progress), 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.francois-rtgwg-segment-routing-ti-lfa]
              Francois, P., Filsfils, C., Bashandy, A., and B. Decraene,
              "Topology Independent Fast Reroute using Segment Routing",
              draft-francois-rtgwg-segment-routing-ti-lfa-00 (work in
              progress), August 2015.

   [I-D.ietf-isis-mrt]
              Li, Z., Wu, N., <>, Q., Atlas, A., Bowers, C., and J.
              Tantsura, "Intermediate System to Intermediate System (IS-
              IS) Extensions for Maximally Redundant Trees (MRT)",
              draft-ietf-isis-mrt-01 (work in progress), October 2015.

   [I-D.ietf-mpls-ldp-mrt]
              Atlas, A., Tiruveedhula, K., Bowers, C., Tantsura, J., and
              I. Wijnands, "LDP Extensions to Support Maximally
              Redundant Trees", draft-ietf-mpls-ldp-mrt-02 (work in
              progress), September 2015.

   [I-D.ietf-ospf-mrt]
              Atlas, A., Hegde, S., Bowers, C., Tantsura, J., and Z. Li,
              "OSPF Extensions to Support Maximally Redundant Trees",
              draft-ietf-ospf-mrt-01 (work in progress), October 2015.

   [I-D.ietf-rtgwg-lfa-manageability]
              Litkowski, S., Decraene, B., Filsfils, C., Raza, K.,
              Horneffer, M., and P. Sarkar, "Operational management of
              Loop Free Alternates", draft-ietf-rtgwg-lfa-
              manageability-11 (work in progress), June 2015.

   [I-D.ietf-rtgwg-rlfa-node-protection]
              Sarkar, P., Hegde, S., Bowers, C., Gredler, H., and S.
              Litkowski, "Remote-LFA Node Protection and Manageability",
              draft-ietf-rtgwg-rlfa-node-protection-05 (work in
              progress), December 2015.

   [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,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
              DOI 10.17487/RFC2328, April 1998,
              <http://www.rfc-editor.org/info/rfc2328>.

   [RFC4379]  Kompella, K. and G. Swallow, "Detecting Multi-Protocol
              Label Switched (MPLS) Data Plane Failures", RFC 4379,
              DOI 10.17487/RFC4379, February 2006,
              <http://www.rfc-editor.org/info/rfc4379>.

   [RFC5331]  Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream
              Label Assignment and Context-Specific Label Space",
              RFC 5331, DOI 10.17487/RFC5331, August 2008,
              <http://www.rfc-editor.org/info/rfc5331>.

   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
              <http://www.rfc-editor.org/info/rfc5340>.

   [RFC5443]  Jork, M., Atlas, A., and L. Fang, "LDP IGP
              Synchronization", RFC 5443, DOI 10.17487/RFC5443, March
              2009, <http://www.rfc-editor.org/info/rfc5443>.

   [RFC5714]  Shand, M. and S. Bryant, "IP Fast Reroute Framework",
              RFC 5714, DOI 10.17487/RFC5714, January 2010,
              <http://www.rfc-editor.org/info/rfc5714>.

   [RFC5715]  Shand, M. and S. Bryant, "A Framework for Loop-Free
              Convergence", RFC 5715, DOI 10.17487/RFC5715, January
              2010, <http://www.rfc-editor.org/info/rfc5715>.

   [RFC6571]  Filsfils, C., Ed., Francois, P., Ed., Shand, M., Decraene,
              B., Uttaro, J., Leymann, N., and M. Horneffer, "Loop-Free
              Alternate (LFA) Applicability in Service Provider (SP)
              Networks", RFC 6571, DOI 10.17487/RFC6571, June 2012,
              <http://www.rfc-editor.org/info/rfc6571>.

   [RFC6976]  Shand, M., Bryant, S., Previdi, S., Filsfils, C.,
              Francois, P., and O. Bonaventure, "Framework for Loop-Free
              Convergence Using the Ordered Forwarding Information Base
              (oFIB) Approach", RFC 6976, DOI 10.17487/RFC6976, July
              2013, <http://www.rfc-editor.org/info/rfc6976>.

   [RFC6981]  Bryant, S., Previdi, S., and M. Shand, "A Framework for IP
              and MPLS Fast Reroute Using Not-Via Addresses", RFC 6981,
              DOI 10.17487/RFC6981, August 2013,
              <http://www.rfc-editor.org/info/rfc6981>.

   [RFC6982]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
              Code: The Implementation Status Section", RFC 6982,
              DOI 10.17487/RFC6982, July 2013,
              <http://www.rfc-editor.org/info/rfc6982>.

   [RFC6987]  Retana, A., Nguyen, L., Zinin, A., White, R., and D.
              McPherson, "OSPF Stub Router Advertisement", RFC 6987,
              DOI 10.17487/RFC6987, September 2013,
              <http://www.rfc-editor.org/info/rfc6987>.

   [RFC7307]  Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
              King, "LDP Extensions for Multi-Topology", RFC 7307,
              DOI 10.17487/RFC7307, July 2014,
              <http://www.rfc-editor.org/info/rfc7307>.

   [RFC7490]  Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N.
              So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)",
              RFC 7490, DOI 10.17487/RFC7490, April 2015,
              <http://www.rfc-editor.org/info/rfc7490>.

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 4: 5: AS external prefixes in different areas

   Consider the network in Figure 4 5 and assume there is a richer
   connective topology that isn't shown, where the same prefix is
   announced by ASBR X and ASBR Y which are in 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 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
   one area are not yet aware of the failure in 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 the tunnel avoids the failure point.  In that case,
   A must determine that it should use an explicit tunnel instead of an
   MRT alternate.

Authors' Addresses

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

   Email: akatlas@juniper.net

   Chris Bowers
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   USA

   Email: cbowers@juniper.net

   Gabor Sandor Enyedi
   Ericsson
   Konyves Kalman krt 11.
   Budapest  1097
   Hungary

   Email: Gabor.Sandor.Enyedi@ericsson.com