MPLS Working Group                                              A. Atlas
Internet-Draft                                           K. Tiruveedhula
Intended status: Standards Track                               C. Bowers
Expires: January 5, April 30, 2015                                 Juniper Networks
                                                             J. Tantsura
                                                                Ericsson
                                                            IJ. Wijnands
                                                     Cisco Systems, Inc.
                                                            July 4,
                                                        October 27, 2014

          LDP Extensions to Support Maximally Redundant Trees
                      draft-atlas-mpls-ldp-mrt-01
                      draft-atlas-mpls-ldp-mrt-02

Abstract

   This document specifies extensions to LDP to support the creation of
   label-switched paths for Maximally Redundant Trees (MRT).  A prime
   use of MRTs is for unicast and multicast IP/LDP Fast-Reroute (MRT-
   FRR). Fast-Reroute, which
   we will refer to as MRT-FRR.

   The sole protocol extension to LDP is simply the ability to advertise
   an MRT Capability.  This document describes that extension and the
   associated behavior expected for LSRs and LERs advertising the MRT
   Capability.

   MRT-FRR uses LDP multi-topology extensions and requires three
   different multi-topology IDs to be allocated from the LDP MT-ID
   space.

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 January 5, April 30, 2015.

Copyright Notice

   Copyright (c) 2014 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  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3   4
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3   4
   4.  Overview of LDP Signaling Extensions for MRT  . . . . . . . .   4   5
     4.1.  MRT Capability Advertisement  . . . . . . . . . . . . . .   5
       4.1.1.  Interaction of LDP MRT Capability with IPv4 and IPv6    6
     4.2.  Behavior Related to  Use of the Rainbow MRT MT-ID  . . . . . . . .   6 . . . . . .   7
     4.3.  MRT-Blue and MRT-Red FECs . . . . . . . . . . . . . . . .   7
   5.  LDP MRT FEC Advertisements  . . . . . . . . . . . . . . . . .   7
     5.1.  Downstream Unsolicited Mode  MRT-specific behavior . . . . . . . . . . . . . . .   7 . . .   8
       5.1.1.  ABR behavior and use of the Rainbow FEC . . . . . . .   8
       5.1.2.  Proxy-node attachment router behavior . . . . . . . .   9
     5.2.  Downstream On Demand Mode  LDP protocol procedures in the context of MRT label
           distribution  . . . . . . . . . . . . . . . . . .   8
     5.3.  Inter-Area . . . .  10
       5.2.1.  LDP peer in RFC5036 . . . . . . . . . . . . . . . . .  10
       5.2.2.  Next hop in RFC5036 . .   8 . . . . . . . . . . . . . . .  10
       5.2.3.  Egress LSR in RFC5036 . . . . . . . . . . . . . . . .  11
       5.2.4.  Use of Rainbow FEC to satisfy label mapping existence
               requirements in RFC5036 . . . . . . . . . . . . . . .  12
       5.2.5.  Validating FECs in routing table  . . . . . . . . . .  13
       5.2.6.  Recognizing new FECs  . . . . . . . . . . . . . . . .  13
       5.2.7.  Not propagating Rainbow FEC label mappings  . . . . .  13
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8  13
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9  14
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9  14
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   9  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10  15

1.  Introduction

   This document describes the LDP signaling extension and associated
   behavior necessary to support the architecture that defines how IP/
   LDP Fast-Reroute can use MRTs [I-D.ietf-rtgwg-mrt-frr-architecture].
   It is necessary to read be familiar with the architecture in
   [I-D.ietf-rtgwg-mrt-frr-architecture] to understand how and why the
   LDP extensions for behavior are needed.

   At least one common standardized algorithm, such as algorithm (e.g. the lowpoint MRT Lowpoint
   algorithm explained and fully documented in
   [I-D.ietf-rtgwg-mrt-frr-algorithm],
   [I-D.ietf-rtgwg-mrt-frr-algorithm]) is required so that the routers
   supporting MRT computation consistently compute the same MRTs.  LDP
   depends on the an IGP to compute the for computation of MRTs and alternates.  Extensions
   to OSPF are defined in [I-D.atlas-ospf-mrt].  Extension to IS-IS are
   defined in [I-D.li-isis-mrt] [I-D.li-isis-mrt].

   MRT can also be used to protect multicast traffic (signalled via PIM
   or mLDP) using either global protection or local protection.[I-D.atlas-rtgwg-mrt-mc-arch] protection
   [I-D.atlas-rtgwg-mrt-mc-arch].  An MRT path can be used to provide
   node-protection for mLDP traffic via the mechanisms described in
   [I-D.wijnands-mpls-mldp-node-protection]; an MRT path can also be use
   used to provide link protection for mLDP traffic.

   For each destination, IP/LDP Fast-Reroute with MRT (MRT-FRR) creates
   two alternate destination-based trees separate from the primary next-
   hop shortest path
   forwarding used during stable operation.  LDP uses the multi-
   topology multi-topology
   extensions [I-D.ietf-mpls-ldp-multi-topology] [RFC7307] to signal FECs Forwarding Equivalency Classes (FECs)
   for these two new sets of forwarding topologies, known as trees, MRT-Blue and MRT-
   Red. MRT-Red.

   In order to create MRT paths and support IP/LDP Fast-Reroute, a new
   capability extension is needed for LDP.  An LDP implementation
   supporting MRT must MUST also follow the described rules described here for
   originating and managing FECs related to MRT, as indicated by their multi-
   topology
   multi-topology ID.  Network reconvergence is described in
   [I-D.ietf-rtgwg-mrt-frr-architecture] and the worst-cast worst-case network
   convergence time can be flooded via the extension in Section 7 of
   [I-D.atlas-ospf-mrt].

   IP/LDP Fast-Reroute using MRTs can provide 100% coverage for link and
   node failures in an arbitrary network topology where the failure
   doesn't split the network.  It can also be deployed incrementally; an
   MRT Island is formed of connected supporting routers and the MRTs are
   computed inside that island.

2.  Requirements Language

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

3.  Terminology

   For ease of reading, some of the terminology defined in
   [I-D.ietf-rtgwg-mrt-frr-architecture] is repeated here.

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

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

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

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

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

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

4.  Overview of LDP

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

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

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

4.  Overview of LDP Signaling Extensions for MRT

   Routers need to know which of their neighbors support MRT.
   Supporting MRT indicates several different aspects of behavior, as
   listed below.

   1.  Support for Multi-Topology (MT) - this MAY also be indicated via
       the Multi-Capability MT Multi-Topology LDP Capability
       [I-D.ietf-mpls-ldp-multi-topology]. [RFC7307].

   2.  Understand the Rainbow MRT MT-ID and apply the associated labels
       to all relevant MT-IDs.

   3.  Advertise the Rainbow MRT MT-ID to the appropriate neighbors for
       the associated prefix.

   4.  If acting as LDP egress for a prefix in the default topology,
       also advertise and act as egress for the same prefix in MRT-Red
       and MRT-Blue.

   5.  For a FEC learned from a neighbor that does not support MRT,
       originate FECS for MRT-Red and MRT-Blue with the same prefix.
       This MRT Island egress behavior is to support an MRT Island that
       does not include all routers in the area/level.

4.1.  MRT Capability Advertisement

   It is not possible to support MRT without supporting the LDP multi-
   topology extensions, but it is possible that the only use of the
   multi-topology extensions is for MRT.  In that case, a router MAY not
   negotiate the multi-topology capability and only negotiate the MRT
   Capability with its LDP peer. peers.  Negotiation of the MT multi-topology
   capability is not required with negotiation of the MRT capability.

   [EDITOR NOTE: How do we deal with different abilities for IPv4 and
   IPv6?  The MT capability has the Wildcard FEC to indicate this.  Do
   we just assume??]

   A new MRT Capability Parameter TLV is defined, which is defined in accordance with LDP
   Capability definition guidelines[RFC5561].

   The LDP MRT capability can be advertised during the LDP session
   initialization or after the LDP session is established.
   Advertisement of the MRT capability indicates support of the
   procedures for establishing the MRT-Blue and MRT-Red LSP paths
   detailed in this document.  If the peer has not advertised the MRT
   capability, then it indicates that LSR does not support MRT
   procedures.

   If a router advertises the LDP MRT capability to its peer, but the
   peer has not advertised the MRT capability, then the router MUST NOT
   advertise MRT-related FEC-label bindings to that peer, until that
   peer starts to advertise the MRT capability. peer.

   The following is the format of the MRT Capability Parameter.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |U|F| MRT Capability (IANA)     |      Length (= 1)             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S| Reserved    |
     +-+-+-+-+-+-+-+-+

                         MRT Capability TLV Format

   Where:

   U- and F-bits:

   U-bit:   The unknown TLV bit MUST be 1 1.  A router that does not
      recognize the MRT Capability TLV will silently ignore the TLV and 0, respectively,
      process the rest of the message as if the unknown TLV did not
      exist.

   F-bit:   The forward unknown TLV bit MUST be 0 as per required by
      Section 3.
      (Signaling Extensions) 3 of LDP Capabilities [RFC5561].

   MRT Capability:   TBA-MRT-LDP-1 (To Be Allocated by IANA)

   Length:   The length (in octets) of TLV.  Its value is 1.

   S-bit:   The State bit MUST be 1 if used in LDP "Initialization"
      message.  MAY be set to 0 or 1 in dynamic "Capability" message to
      advertise or withdraw the capability respectively.

   Length:   The length (in octets) respectively, as described in
      [RFC5561].

4.1.1.  Interaction of TLV.  Its value LDP MRT Capability with IPv4 and IPv6

   An LSR which advertises the MRT LDP capability is 1.

4.2.  Behavior Related expected to
   advertise MRT-related FEC-label bindings for both IPv4 and IPv6
   address families, if the LSR originates shortest-path FEC-label
   bindings for those address families.

4.2.  Use of the Rainbow MRT MT-ID

   In

   Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture], [I-D.ietf-rtgwg-mrt-frr-architecture] describes the
   need for an area border router (ABR) to
   advertise have different neighbors use
   different MPLS labels when sending traffic to different neighbors the ABR for the same
   FEC
   FEC.  More detailed discussion of the Rainbow MRT MT-ID is described.  This can be shortly summarized as either
   advertising provided
   in Section 5.1.1.

   Another use for the Rainbow MRT MT-ID differentiated labels is for an LSR to a neighbor or just
   advertising the same MPLS label for the default topology, for MRT-Red
   and MRT-Blue.  MRT-supporting neighbors in the same domain as the
   default SPT next-hop get the differentiated MPLS labels; all other
   neighbors do not.

   A second use for the Rainbow MRT MT-ID is for an egress LER to send send the
   Rainbow MRT MT-ID with an IMPLICIT_NULL label to indicate
   penultimate-hop-popping for all three types of FECs (IP Prefix FEC,
   MRT-Blue MT-IP Prefix FEC, (shortest path,
   red, and MRT-Red MT-IP Prefix FEC). blue).  The use of the Rainbow-FEC by the ABR for non-best-area
   advertisements is RECOMMENDED.  An ABR MAY advertise the EXPLICIT_NULL label for
   the default topology in separate MRT-Blue and MRT-Red advertisements.
   An LSR advertising the MRT capability MUST recognize advertised using the Rainbow
   MRT MT-ID and associate similarly applies to all the advertised label with types of FECs.  Note that the specific prefix
   with
   only scenario in which it is generally useful to advertise the MRT-Red and MRT-Blue MT-IDs associated with
   implicit or explicit null label for all MRT Profiles
   that advertise LDP as three FEC types is when the forwarding mechanism.
   FEC refers to the LSR itself.  See Section 5.2.3 for more details.

   The value of the Rainbow MRT MT-ID (TBA-MRT-LDP-2) will be assigned
   by IANA from the LDP MT-ID space.  Prototype experiments have used
   the value 3999.

4.3.  MRT-Blue and MRT-Red FECs

   To provide MRT support in LDP, the MT Prefix FEC is used.
   [I-D.ietf-rtgwg-mrt-frr-architecture] contains the IANA request for
   the MRT-Red and MRT-Blue MT-IDs associated with the Default MRT
   Profile.

   The MT Prefix FEC encoding is defined in
   [I-D.ietf-mpls-ldp-multi-topology] [RFC7307] and is used
   without alteration for
   signaling advertising label mappings for MRT-Blue, MRT-Red MRT-
   Red and Rainbow MRT FECs.

5.  LDP MRT FEC Advertisements

   This sections describes how and when labels for MRT-Red and MRT-Blue
   FECs are advertised.  The associated LSPs must be created before a
   failure occurs, in order to provide protection paths which are
   immediately usable by a PLR.

5.1.  Downstream Unsolicited Mode

   If the upstream session is negotiated with the MRT capability, point of local repair in the
   Egress LER advertises via event of a Rainbow MRT FEC an allocated MPLS label;
   failure.

   In this may be Explicit Null, Implicit Null, or another value.

   Based on section, we will use the MRT algorithm [I-D.ietf-rtgwg-mrt-frr-algorithm], term "shortest path FEC" to refer to
   the
   IGP computes usual FEC associated with the MRT-Red and MRT-Blue disjoint paths at Ingress and
   Transit LSRs.  Once shortest path destination-based
   forwarding tree for a given prefix as determined by the IGP computes IGP.  We will
   use the terms "red FEC" and "blue FEC" to refer to FECs associated
   with the MRT-Red and MRT-Blue next-
   hops, LDP will advertise the Label Mapping destination-based forwarding trees for the MRT-Blue and MRT-
   Red FECs.  If
   a label is received from given prefix as determined by a downstream LSR for an MRT-
   Red or MRT-Blue FEC where particular MRT algorithm.

   We first describe label distribution behavior specific to MRT.  Then
   we provide the downstream correct interpretation of several important concepts
   in [RFC5036] in the context of MRT FEC label distribution.

5.1.  MRT-specific behavior

5.1.1.  ABR behavior and use of the Rainbow FEC

   Section 10.1 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes the
   need for an area border router (ABR) to have different neighbors use
   different MPLS labels when sending traffic to the ABR for the same
   FEC.  The method to accomplish this using the Rainbow MRT MT-ID is
   described in detail in [I-D.ietf-rtgwg-mrt-frr-architecture].  Here
   we provide a brief summary.  To those LDP peers in the same area as
   the best route to the destination, the ABR advertises two different
   labels corresponding to the MRT-Red and MRT-Blue forwarding trees for
   the destination.  An LDP peer receiving these advertisements forwards
   MRT traffic to the ABR using these two different labels, depending on
   the FEC of the traffic.  We refer to this as best-area advertising
   and forwarding behavior, which is identical to normal MRT behavior.

   For all other LDP peers supporting MRT, the ABR advertises a FEC-
   label binding for the Rainbow MRT MT-ID scoped FEC with the label
   corresponding to the default forwarding tree for the destination.  An
   LDP peer receiving this advertisement forwards MRT traffic to the ABR
   using this label, for both MRT Red and MRT Blue traffic.  We refer to
   this as non-best-area advertising and forwarding behavior.

   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.
   An LSR advertising the MRT capability MUST recognize the Rainbow MRT
   MT-ID and associate the advertised label with the specific prefix
   with the MRT-Red and MRT-Blue MT-IDs associated with all MRT Profiles
   that advertise LDP as the forwarding mechanism.

   Due to changes in topology or configuration, an ABR and a given LDP
   peer may need to transition from best-area advertising and forwarding
   behavior to non-best-area behavior for a given destination, and vice
   versa.  When the ABR requires best-area behavior for a red(blue) FEC,
   it MUST withdraw any existing label mappings advertisements for the
   corresponding rainbow FEC and advertise label mappings for the
   red(blue) FEC.  When the ABR requires non-best-area behavior for a
   red(blue) FEC, it MUST withdraw any existing label mappings for both
   red and blue FECs and advertise label mappings for the corresponding
   Rainbow FEC label binding.

   If an LSR receives a label mapping advertisement for a rainbow FEC
   from an MRT LDP peer while it still retains a label mapping for the
   corresponding red or blue FEC, the LSR MUST continue to use the label
   mapping for the red or blue FEC, and it MUST send a Label Release
   Message corresponding to the rainbow FEC label advertisement.  If an
   LSR receives a label mapping advertisement for red or blue FEC while
   it still retains a label mapping for the corresponding rainbow FEC,
   the LSR MUST continue to use the label mapping for the rainbow FEC,
   and it MUST send a Label Release Message corresponding to the red or
   blue FEC label advertisement.

5.1.2.  Proxy-node attachment router behavior

   Section 11.2 of [I-D.ietf-rtgwg-mrt-frr-architecture] describes how
   MRT provides FRR protection for multi-homed prefixes using
   calculations involving a named proxy-node.  This covers the scenario
   where a prefix is originated by a router in the same area as the MRT
   Island, but outside of the MRT Island.  It also covers the scenario
   of a prefix being advertised by a multiple routers in the MRT Island.

   In the named proxy-node calculation, each multi-homed prefix is
   represented by a conceptual proxy-node which is attached to two real
   proxy-node attachment routers.  (A single proxy-node attachment
   router is allowed in the case of a prefix advertised by a same area
   router outside of the MRT Island which is singly connected to the MRT
   Island.)  All routers in the MRT Island perform the same calculations
   to determine the same two proxy-node attachment routers for each
   multi-homed prefix.  The resulting graph in the computation consists
   of the MRT Island with the proxy-node representing the multi-homed
   prefix directly attached to the two proxy-node attachment routers.
   Conceptually, one then runs the MRT algorithm on this simplified
   graph to determine the MRT-red and blue next-hops to reach the proxy-
   node, which gives the next-hops to reach the prefix.  In this manner,
   one can see that one of the two proxy-node attachment routers will
   always have a MRT-red next-hop to the proxy-node while the other will
   always have the MRT-blue next-hop to the proxy-node.  We will refer
   to these as the red and blue proxy-node attachment routers
   respectively.  (In practice, the MRT-red and blue next-hops to reach
   the proxy-node can then be determined in a more computationally
   efficient manner based on the MRT-red and blue next-hops to reach the
   proxy-node attachment routers, as described in
   [I-D.ietf-rtgwg-mrt-frr-algorithm].)

   In terms of LDP behavior, a red proxy-node attachment router for a
   given prefix MUST originate a label mapping for the red FEC for that
   prefix, while the a blue proxy-node attachment router for a given
   prefix MUST originate a label mapping for the blue FEC for that
   prefix.  If the red(blue) proxy-node attachment router is an Island
   Border Router (IBR), then when it receives a packet with the label
   corresponding to the red(blue) FEC for a prefix, it MUST forward the
   packet to the Island Neighbor (IN) whose whose cost was used in the
   selection of the IBR as a proxy-node attachment router.  The IBR MUST
   swap the incoming label for the outgoing label corresponding to the
   shortest path FEC for the prefix advertised by the IN.  In the case
   where the IN does not support LDP, the IBR MUST pop the incoming
   label and forward the packet to the IN.

   If the proxy-node attachment router is not an IBR, then the packet
   MUST be removed from the MRT forwarding topology and sent along the
   interface(s) that caused the router to advertise the prefix.  This
   interface might be out of the area/level/AS.

5.2.  LDP protocol procedures in the context of MRT label distribution

   [RFC5036] specifies the LDP label distribution procedures for
   shortest path FECs.  In general, the same procedures can be applied
   to the distribution of label mappings for red and blue FECs, provided
   that the procedures are interpreted in the context of MRT FEC label
   distribution.  The correct interpretation of several important
   concepts in [RFC5036] in the context of MRT FEC label distribution is
   provided below.

5.2.1.  LDP peer in RFC5036

   In the context of distributing label mappings for red and blue FECs,
   we restrict LDP peer in [RFC5036] to mean LDP peers for which the LDP
   MRT capability has been negotiated.  In order to make this
   distinction clear, in this document we will use the term "MRT LDP
   peer" to refer to an LDP peer for which the LDP MRT capability has
   been negotiated.

5.2.2.  Next hop in RFC5036

   Several procedures in [RFC5036] use the next hop of a (shortest path)
   FEC to determine behavior.  The next hop of the shortest path FEC is
   based on the shortest path forwarding tree to the prefix associated
   with the FEC.  When the procedures of [RFC5036] are used to
   distribute label mapping for red and blue FECs, the next hop for the
   red/blue FEC is based on the MRT-Red/Blue forwarding tree to the
   prefix associated with the FEC.

   For example, Appendix A.1.7. of [RFC5036] specifies the response by
   an LSR to a change in the next hop for a FEC.  For a shortest path
   FEC, the next hop may change as the result of the LSR running a
   shortest path computation on a modified IGP topology database.  For
   the red and blue FECs, the red and blue next hops may change as the
   result of the LSR running a particular MRT algorithm on a modified
   IGP topology database.

   As another example, Section 2.6.1.2 of [RFC5036] specifies how that
   when an LSR is using LSP Ordered Control, it may initiate the
   transmission of a label mapping only for a (shortest path) FEC for
   which it has a label mapping for the FEC next hop, or for which the
   LSR is the egress.  The FEC next hop for a shortest path FEC is based
   on the shortest path forwarding tree to the prefix associated with
   the FEC.  In the context of distributing MRT LDP labels, this
   procedure is understood to mean the following.  When an LSR is capable using
   LSP Ordered Control, it may initiate the transmission of MRT, a label
   mapping only for a red(blue) FEC for which it has a label mapping for
   the red(blue) FEC next hop, or for which the LSR is the egress.  The
   red or blue FEC next hop is based on the MRT-Red or Blue forwarding
   tree to the prefix associated with the FEC.

5.2.3.  Egress LSR in RFC5036

   Procedures in [RFC5036] related to Ordered Control label distribution
   mode rely on whether or not an LSR may act as an egress LSR for a
   particular FEC in order to determine whether or not the LSR may
   originate a label mapping for that FEC.  The status of being an
   egress LSR for a particular FEC is also used in loop detection
   procedures in [RFC5036].  Section 2.6.1.2 of [RFC5036] specifies the
   conditions under which an LSR may act as an egress LSR with respect
   to a particular (shortest path) FEC.

   1.  The (shortest path) FEC refers to the LSR itself (including one
       of its directly attached interfaces).

   2.  The next hop router for the (shortest path) FEC is outside of the
       Label Switching Network.

   3.  (Shortest path) FEC elements are reachable by crossing a routing
       domain boundary.

   The conditions for determining an egress LSR with respect to a red or
   blue FEC need to be modified.  An LSR may act as an egress LSR with
   respect to a particular red(blue) FEC under any of the following
   conditions:

   1.  The prefix associated with the red(blue) FEC refers to the LSR
       itself (including one of its directly attached interfaces).

   2.  The LSR is the red(blue) proxy-node attachment router with
       respect to the multi-homed prefix associated with the red(blue)
       FEC.  This includes the degenerate case of a single red and blue
       proxy-node attachment router for a single-homed prefix.

   3.  The LSR is an area border router (ABR) AND the MRT LDP peer
       requires non-best-area advertising and forwarding behavior for
       the prefix associated with the
   MRT-Red FEC or MRT-Blue FEC.

   Note that condition(3) scopes an LSR's status as an egress LSR with
   respect to a particular FEC label is swapped according to a particular MRT LDP peer.  Therefore,
   the
   received downstream label.  An condition "Is LSR may also choose egress for FEC?" that occurs in several
   procedures in [RFC5036] needs to use the MRT-Red
   or MRT-Blue path be interpreted as an alternate "Is LSR egress for doing fast-reroute
   FEC with respect to Peer?"

   Also note that there is no explicit condition that allows an LSR to
   be classified as an egress LSR with respect a red or blue FEC based
   only on the primary next-hop for the local
   traffic.

   When a downstream router is shortest path FEC not capable of MRT, supporting
   LDP, or not supporting LDP MRT capability.  These situations are
   covered by the LSR is proxy-node attachment router and ABR conditions
   (conditions 2 and 3).  In particular, an MRT Island Border Router (IBR) and SHOULD advertise Label Bindings for is not
   the MRT-Red FEC and MRT-Blue egress LSR for a red(blue) FEC as well as unless it is also the associated normal
   topology.  The normal topology's primary next-hops will red(blue)
   proxy-node attachment router for that FEC.

   Also note that in general a proxy-node attachment router for a given
   prefix should not advertise an implicit or explicit null label for
   the corresponding red or blue FEC, even though it may be used an egress
   LSR for the shortest path FEC.  In general, the proxy-node attachment
   router needs to forward red or blue traffic received for that prefix to a
   particular loop free island neighbor, which may be different from the MRT-Red FEC or
   shortest path next-hop.  The proxy-node attachment router needs to
   receive the MRT-Blue red or blue traffic with a non-null label to correctly
   forward it.

5.2.4.  Use of Rainbow FEC
   where the FEC's destination is outside to satisfy label mapping existence
        requirements in RFC5036

   Several procedures in [RFC5036] require the MRT Island.  This
   functionality is critical LSR to determine if it
   has previously received and retained a label mapping for partial deployment scenarios.

5.2.  Downstream On Demand Mode

   After a FEC from
   the IGP computes next hop.  In the MRT-Red case of an LSR that has received and MRT-Blue paths, retained a
   label mapping for a Rainbow FEC from an ABR, the IGP MAY
   also decide to use either label mapping for
   the MRT-Red or MRT-Blue path as a fast-
   reroute alternate Rainbow FEC satisfies the label mapping existence requirement for
   the particular FEC.  If so, then when corresponding red and blue FECs.  Label mapping existence
   requirements in
   Downstream On Demand Mode, the context of MRT LDP label distribution are
   modified as: "Has LSR sends previously received and retained a Label Request label
   mapping for either the MRT-Red or MRT-Blue red(blue) FEC to (or the downstream LSR.  The downstream corresponding Rainbow FEC) from
   the red(blue) next hop?"

   As an example, this behavior allows an LSR responds by either sending a Label Mapping if available or by
   sending a Label Request to its downstream LSR.  Once which has received and
   retained a Label Mapping
   is received, the associated label may be used as a fast-reroute
   alternate mapping for the Rainbow FEC to forward IP advertise label
   mappings for the corresponding red and LDP traffic.

   A Label Mapping may be available blue FECs when operating in the following circumstances:

   o  The
   Ordered Control label distribution mode.

5.2.5.  Validating FECs in routing table

   In [RFC5036] an LSR is acting as Egress

   o  A uses its routing table to validate prefixes
   associated with shortest path FECs.  For example, section 3.5.7.1 of
   [RFC5036] specifies that "an LSR receiving a Label Mapping was already received message
   from its a downstream router

   o  A Label Mapping LSR for a Prefix SHOULD NOT use the label for
   forwarding unless its routing table contains an entry that exactly
   matches the default topology FEC was received and Element."  In the
      downstream router is not capable context of MRT FECs, a red or is in blue
   FEC element matches a different MRT
      Island.

5.3.  Inter-Area

   As discussed in Section 4.2, routing table entry if the Rainbow MRT corresponding
   shortest path FEC is defined to
   facilitate signaling the same label for multiple topologies. element matches a routing table entry.

5.2.6.  Recognizing new FECs

   Section 9 A.1.6 of [I-D.ietf-rtgwg-mrt-frr-architecture] recommends that
   traffic leaving an OSPF area or IS-IS level SHOULD use [RFC5036] describes the default
   topology's shortest-path-tree next-hops instead response of remaining on an LSR to the
   MRT-Red or MRT-Blue paths.  If
   "Recognize New FEC" event, which occurs when an LDP peer is in LSR learns a new
   (shortest path) FEC via the same OSPF area
   or IS-IS level as routing table.  In the primary next-hop, then context of MRT
   FECs, when MRT LDP SHOULD advertise
   different label values for capability has been enabled, when an LSR learns a given set of MRT-Red FEC, MRT-Blue
   new shortest path FEC, it should generate "Recognize New FEC" events
   for the corresponding red and FEC, unless Explicit-Null or Implicit-Null is appropriate.  If an
   LDP peer is blue FECs, in a different OSPF area or IS-IS level from addition to the primary
   next-hop, then LDP SHOULD either advertise
   "Recognize New FEC" event for the same shortest path FEC.

5.2.7.  Not propagating Rainbow FEC label value mappings

   A label mapping for the given set of MRT-Red FEC, MRT-Blue FEC, and Rainbow FEC or advertise should only be originated by an
   ABR under the conditions described in Section 5.1.1.  A neighbor of
   the ABR that receives a
   single label mapping for the Rainbow MRT FEC, whose behavior is defined in
   Section 4.2. FEC MUST NOT
   propagate a label mapping for that Rainbow FEC.

6.  Security Considerations

   This LDP extension is

   The labels distributed by the extensions in this document create
   additional forwarding paths that do not believed following shortest path
   routes.  The transit label swapping operations defining these
   alternative forwarding paths are created during normal operations
   (before a failure occurs).  Therefore, a malicious packet with an
   appropriate label injected into the network from a compromised
   location would be forwarded to introduce new a destinations along a non-shortest
   path.  When this technology is deployed, a network security
   concerns. design
   should not rely on assumptions about potentially malicious traffic
   only following shortest paths.

   It relies upon should be noted that the security architecture already provided
   for LDP. creation of non-shortest forwarding paths
   is not unique to MRT.

7.  IANA Considerations

   Please

   IANA is requested to allocate a value for the new LDP Capability TLV
   (the first free value in the range 0x0500 to 0x05FF) from the LDP
   registry "TLV Type Name Space": MRT Capability TLV (TBA-MRT-LDP-1).

   Please

    Value          Description         Reference     Notes / Reg. Date
    -------------  ------------------  ------------  -----------------
    TBA-MRT-LDP-1  MRT Capability TLV  [This draft]

   IANA is requested to allocate a value from the LDP MPLS Multi-Topology (MT) ID
   Identifiers Name Space [I-D.ietf-mpls-ldp-multi-topology]: [RFC7307]: Rainbow MRT MT-ID (TBA-MRT-LDP-2).

              Value          Purpose             Reference
              -------------  ------------------  ------------
              TBA-MRT-LDP-2  Rainbow MRT MT-ID (TBA-MRT-
   LDP-2).   [This draft]

8.  Acknowledgements

   The authors would like to thank Ross Callon and Loa Andersson for his
   their suggestions.

9.  References

9.1.  Normative References

   [I-D.ietf-mpls-ldp-multi-topology]
              Zhao, Q., Raza, K., Zhou,

   [I-D.ietf-rtgwg-mrt-frr-algorithm]
              Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., Fang, L., Li, L., and D.
              King, "LDP Extensions A.
              Gopalan, "Algorithms for computing Maximally Redundant
              Trees for Multi Topology", draft-ietf-
              mpls-ldp-multi-topology-12 IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr-
              algorithm-01 (work in progress), April July 2014.

   [I-D.ietf-rtgwg-mrt-frr-architecture]
              Atlas, A., Kebler, R., Bowers, C., Enyedi, G., Csaszar,
              A., Tantsura, J., Konstantynowicz, M., and R. White, "An
              Architecture for IP/LDP Fast-Reroute Using Maximally
              Redundant Trees", draft-rtgwg-mrt-frr-architecture-04
              (work in progress), July 2014.

   [RFC5036]  Andersson, L., Minei, I., and B. Thomas, "LDP
              Specification", RFC 5036, October 2007.

   [RFC5561]  Thomas, B., Raza, K., Aggarwal, S., Aggarwal, R., and JL.
              Le Roux, "LDP Capabilities", RFC 5561, July 2009.

   [RFC7307]  Zhao, Q., Raza, K., Zhou, C., Fang, L., Li, L., and D.
              King, "LDP Extensions for Multi-Topology", RFC 7307, July
              2014.

9.2.  Informative References

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

   [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.ietf-rtgwg-mrt-frr-algorithm]
              Enyedi, G., Csaszar, A., Atlas, A., Bowers, C., and A.
              Gopalan, "Algorithms for computing Maximally Redundant
              Trees for IP/LDP Fast-Reroute", draft-rtgwg-mrt-frr-
              algorithm-01 (work in progress), July 2014.

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

   [I-D.wijnands-mpls-mldp-node-protection]
              Wijnands, I., Rosen, E., Raza, K., Tantsura, J., Atlas,
              A., and Q. Zhao, "mLDP Node Protection", draft-wijnands-
              mpls-mldp-node-protection-04 (work in progress), June
              2013.

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

   [RFC4915]  Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P.
              Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC
              4915, June 2007.

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

Authors' Addresses

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

   Email: akatlas@juniper.net

   Kishore Tiruveedhula
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Email: kishoret@juniper.net
   Chris Bowers
   Juniper Networks
   1194 N. Mathilda Ave.
   Sunnyvale, CA  94089
   USA

   Email: cbowers@juniper.net

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

   Email: jeff.tantsura@ericsson.com

   IJsbrand Wijnands
   Cisco Systems, Inc.

   Email: ice@cisco.com