[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04

Internet Engineering Task Force                               Yimin Shen
Internet-Draft                                           Minto Jeyananth
Intended status: Standards Track                        Juniper Networks
Expires: August 5, 2017                                   Bruno Decraene
                                                                  Orange
                                                          Hannes Gredler
                                                             RtBrick Inc
                                                          Carsten Michel
                                                        Deutsche Telekom
                                                        February 1, 2017


                    MPLS Egress Protection Framework
             draft-shen-mpls-egress-protection-framework-04

Abstract

   This document specifies the framework of a fast reroute mechanism for
   protecting IP/MPLS services and MPLS transport tunnels against egress
   node and egress link failures.  In this framework, the penultimate-
   hop router of an MPLS tunnel acts as the point of local repair (PLR)
   for egress node failure, and the egress router of the MPLS tunnel
   acts as the PLR for egress link failure.  They each pre-establishes a
   bypass tunnel to a protector.  Upon an egress node or link failure,
   the PLR performs local failure detection and local repair, by
   rerouting packets over the bypass tunnel.  The protector in turn
   performs context label switching or context IP forwarding to send the
   packets to ultimate service destination(s).  This mechanism can be
   used to reduce traffic loss before global repair reacts to the
   failure and control plane protocols converge on the topology changes
   due to the failure.  The framework is applicable to all types of IP/
   MPLS services and MPLS tunnels.  Under the framework, service
   protocol extensions may be further specified to support service label
   distribution to protector.

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




Yimin Shen, et al.       Expires August 5, 2017                 [Page 1]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 5, 2017.

Copyright Notice

   Copyright (c) 2017 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
   2.  Specification of Requirements . . . . . . . . . . . . . . . .   5
   3.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   6
   5.  Egress node protection  . . . . . . . . . . . . . . . . . . .   8
     5.1.  Reference topology  . . . . . . . . . . . . . . . . . . .   8
     5.2.  Egress node failure . . . . . . . . . . . . . . . . . . .   8
     5.3.  Protector and PLR . . . . . . . . . . . . . . . . . . . .   9
     5.4.  Protected egress  . . . . . . . . . . . . . . . . . . . .   9
     5.5.  Egress-protected tunnel . . . . . . . . . . . . . . . . .  10
     5.6.  Egress-protected service  . . . . . . . . . . . . . . . .  10
     5.7.  Egress-protected service to egress-protected tunnel
           mapping . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.8.  Egress-protection bypass tunnel . . . . . . . . . . . . .  11
     5.9.  Context ID, context label, and context based forwarding .  11
     5.10. IGP advertisement and path resolution for context ID  . .  13
     5.11. Egress-protection bypass tunnel establishment . . . . . .  14
     5.12. Local Repair on PLR . . . . . . . . . . . . . . . . . . .  14
     5.13. Service label distribution from egress router to
           protector . . . . . . . . . . . . . . . . . . . . . . . .  15
     5.14. Centralized protector mode  . . . . . . . . . . . . . . .  15
   6.  Egress link protection  . . . . . . . . . . . . . . . . . . .  17
   7.  Global repair . . . . . . . . . . . . . . . . . . . . . . . .  20
   8.  Example:  Layer-3 VPN egress protection . . . . . . . . . . .  21
     8.1.  Egress node protection  . . . . . . . . . . . . . . . . .  22
     8.2.  Egress link protection  . . . . . . . . . . . . . . . . .  23



Yimin Shen, et al.       Expires August 5, 2017                 [Page 2]


Internet-Draft      MPLS Egress Protection Framework       February 2017


     8.3.  Global repair . . . . . . . . . . . . . . . . . . . . . .  23
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  23
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  23
   11. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  24
   12. References  . . . . . . . . . . . . . . . . . . . . . . . . .  24
     12.1.  Normative References . . . . . . . . . . . . . . . . . .  24
     12.2.  Informative References . . . . . . . . . . . . . . . . .  24
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

   In MPLS networks, LSPs (label switched paths) are widely used as
   transport tunnels to carry IP and MPLS services across MPLS domains.
   Examples of MPLS services are layer-2 VPNs, layer-3 VPNs,
   hierarchical LSPs, and others.  In general, a tunnel may carry
   multiple services of one or multiple types, given that the tunnel can
   satisfy both individual and aggregate requirements (e.g.  CoS, QoS)
   of these services.  The egress router of the tunnel must host
   corresponding service instances for the services.  An MPLS service
   instance is responsible for forwarding service packets via an egress
   link to the service destination, based on a service label.  An IP
   service instance is responsible for forwarding service packets via an
   egress link to the service destination, based on IP destination
   address.  The egress link is often called a PE-CE (provider edge -
   customer edge) link or attachment circuit (AC).

   Today, local repair based fast reroute mechanisms (RFC4090, RFC5286,
   RFC7490, RFC7812) have been widely deployed to protect MPLS tunnels
   against transit link/node failures.  They can achieve fast
   restoration of traffic in the order of tens of milliseconds.  Local
   repair refers to the scenario where the router (aka.  PLR, i.e. point
   of local repair) upstream adjacent to an anticipated failure pre-
   establishes a bypass tunnel to the router (aka.  MP, i.e. merge
   point) downstream of the failure, and pre-installs the forwarding
   state of the bypass tunnel in the data plane.  The PLR also uses a
   rapid mechanism (e.g. link layer OAM, BFD, and others) to locally
   detect the failure in the data plane.  When the failure occurs, the
   PLR reroutes traffic through the bypass tunnel to the MP, allowing
   the traffic to continue to flow to the tunnel's egress router.

   This document describes a fast reroute framework for egress node and
   egress link protection.  Similar to the transit link/node protection,
   this framework relies on local failure detection and local repair to
   be performed by a PLR.  In egress node protection, the PLR is the
   penultimate-hop router of a tunnel.  In egress link protection, the
   PLR is the egress router of the tunnel.  However, there is no MP in
   this case, because the tunnel does not have a router downstream of
   the egress router.  Instead, this framework relies on a so-called



Yimin Shen, et al.       Expires August 5, 2017                 [Page 3]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   "protector" to serve as the tailend of a bypass tunnel.  The
   protector is a router that hosts some protection service instances
   and has its own connectivity or paths to service destinations.  When
   the PLR does local repair, the protector is responsible for
   performing context label switching for rerouted MPLS service packets
   based on service labels assigned by the egress router, and performing
   context IP forwarding for rerouted IP service packets.  Thus, the
   service packets can continue to reach service destinations with
   minimum disruption.

   This framework considers an egress node failure as a failure of a
   tunnel, as well as a failure of all the services carried by the
   tunnel, because service packets can no longer reach the service
   instances on the egress router.  Therefore, the framework addresses
   egress node protection at both tunnel level and service level
   simultaneously.  Likewise, the framework considers an egress link
   failure as a failure of all the services traversing the link, and
   addresses egress link protection at service level.

   This framework requires that the destination (a CE or site) of a
   service must be dual-homed or have dual paths to an MPLS network,
   normally via two MPLS edge routers.  One of them is the egress router
   of the service's transport tunnel, and the other is a backup egress
   router.  In the co-located protector mode in this document, the
   backup egress router serves as a protector, and the service instance
   hosted on the router acts as a protection instance.  In the
   centralized protector mode (Section 5.14), a protector and a backup
   egress router may be decoupled.

   The framework is described by mainly referring to P2P (point-to-
   point) tunnels.  However, it is equally applicable to P2MP (point-to-
   multipoint), MP2P (multipoint-to-point) and MP2MP (multipoint-to-
   multipoint) tunnels, when a sub-LSP can be viewed as a P2P tunnel
   from traffic flow's perspective.

   The framework is a multi-service and multi-transport framework.  It
   is applicable to all existing and future types of MPLS tunnels and
   IP/MPLS services.  It does not require extensions for the existing
   signaling and label distribution protocols (e.g.  RSVP, LDP, BGP,
   etc.) of MPLS tunnels, because all tunnels and bypass tunnels are
   expected to be established by using the generic mechanisms provided
   by the protocols.  However, The framework does not preclude future
   extensions to the protocols which may facilitate its procedures.  The
   framework may need extensions for IGPs and service label distribution
   protocols, to support protection establishment and context label
   switching.  This document provides guidelines for these extensions,
   but the details should be addressed in separate documents.




Yimin Shen, et al.       Expires August 5, 2017                 [Page 4]


Internet-Draft      MPLS Egress Protection Framework       February 2017


2.  Specification of Requirements

   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

   Egress router - A router at the egress endpoint of a tunnel.  It
   hosts service instances for all the services carried by the tunnel,
   and has connectivity with the destinations of the services.

   Egress node failure - A node failure of an egress router.

   Egress link failure - A failure of the egress link (e.g.  PE-CE link,
   attachment circuit) of a service.

   Egress failure - An egress node failure or an egress link failure.

   Egress-protected tunnel - A tunnel whose egress router is protected
   by mechanisms according to this framework.  The egress router is
   considered as a protected egress router.

   Egress-protected service - An IP or MPLS service which is carried by
   an egress-protected tunnel, and hence protected by mechanisms
   according to this framework.

   Backup egress router - Given an egress-protected tunnel and its
   egress router, this is another router which has connectivity with all
   or a subset of the destinations of the egress-protected services
   carried by the egress-protected tunnel.  In this framework, the
   service instances on this router are considered as backup service
   instances, and the corresponding services are called backup services.

   Backup service instance - A service instance which is hosted by a
   backup egress router, and corresponding to the service instance of an
   egress-protected service on a protected egress router.

   Protector - A role acted by a router as an alternate of a protected
   egress router, to handle service packets in the event of an egress
   failure.  It protects an egress-protected tunnel, and hosts
   protection service instances for the egress-protected services
   carried by the tunnel.  A protector may be physically co-located with
   or decoupled from a backup egress router, depending on the co-located
   or centralized protector mode.

   Protection service instance - A service instance hosted by a
   protector, protecting the service instance of an egress-protected



Yimin Shen, et al.       Expires August 5, 2017                 [Page 5]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   service on a protected egress router.  A protection service instance
   is a backup service instance, if the protector is co-located with a
   backup egress router.

   PLR - A router at point of local repair.  In egress node protection,
   it is the penultimate-hop router on an egress-protected tunnel.  In
   egress link protection, it is the egress router of the egress-
   protected tunnel.

   Protected egress {E, P} - A virtual node consisting of an ordered
   pair of egress router E and protector P.  It serves as the virtual
   destination for an egress-protected tunnel.  It also serves as the
   virtual location of service instances for the egress-protected
   services carried by the tunnel.

   Context identifier (ID) - A globally unique IP address assigned to a
   protected egress {E, P}.

   Context label - A non-reserved label assigned to a context ID by a
   protector.

   Egress-protection bypass tunnel - An tunnel used for rerouting
   service packets around an egress failure.  In egress node protection,
   it is established from a penultimate-hop router (i.e.  PLR) to a
   protector, bypassing a protected egress router.  In egress link
   protection, it is established from a protected egress router (i.e.
   PLR) to a protector.

   Co-located protector mode - The scenario where a protector and a
   backup egress router are co-located as one router, and hence each
   backup service instance serves as a protection service instance.

   Centralized protector mode - The scenario where protector is a
   dedicated router, and is decoupled from a backup egress router.

   Context label switching - Label switching performed by a protector,
   in the label space of an egress router indicated by a context label.

   Context IP forwarding - IP forwarding performed by a protector, in
   the IP address space of an egress router indicated by a context
   label.

4.  Requirements

   This document considers the followings as requirements of the egress
   protection framework.





Yimin Shen, et al.       Expires August 5, 2017                 [Page 6]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   o  The framework must be based on local failure detection and local
      repair, in a similar manner to transit link/node protection.

   o  The framework must support P2P tunnels.  It should equally support
      P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P
      tunnel.

   o  The framework must support multi-service and multi-transport
      networks.  It must accommodate existing and future signaling and
      label-distribution protocols of tunnels and bypass tunnels,
      including RSPV, LDP, BGP, IGP, segment routing, and others.  It
      must also accommodate existing and future IP/MPLS services,
      including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and
      others.  It must provide a generic solution for environments where
      different types of services and transport tunnels co-exist.

   o  The framework must consider minimizing disruption for deployment.
      It must involve only routers with proximity to egress, and limit
      the set of routers to include only PLRs, protectors, and backup
      egress routers.  It must be transparent to ingress routers and
      other transit routers.

   o  In egress node protection, a PLR must be agnostic with services
      and service labels, like PLRs in the transit link/node protection.
      It must maintain bypass tunnels and bypass forwarding state on a
      per-transport-tunnel basis, rather than per-service-destination or
      per-service-label basis.  It should also support bypass tunnel
      sharing between transport tunnels.

   o  A PLR must be able to use its local visibility or information of
      routing and/or TE domain to compute or resolve path for a bypass
      tunnel to a protector.

   o  A protector must be able to perform context label switching for
      rerouted MPLS service packets, based on service label(s) assigned
      by an egress router.  It must be able to perform context IP
      forwarding for rerouted IP service packets, in the public or
      private IP address space used by an egress router.

   o  The framework must be able to work seamlessly with transit link/
      node protection mechanisms to achieve end-to-end coverage.

   o  The framework must be able to work in conjunction with global
      repair and control plane convergence.







Yimin Shen, et al.       Expires August 5, 2017                 [Page 7]


Internet-Draft      MPLS Egress Protection Framework       February 2017


5.  Egress node protection

5.1.  Reference topology

   This document refers to the following topology when describing the
   procedures for egress node protection.


                  services 1, ..., N
        =====================================> tunnel

      I ------ R1 ------- PLR --------------- E ----
   ingress          penultimate-hop        egress    \
                           |  .           (primary    \
                           |  .            service     \
                           |  .            instances)   \
                           |  .                          \
                           |  .                           \   service
                           |  .                             destinations
                           |  .                           / (CEs, sites)
                           |  .                          /
                           |  . bypass                  /
                           |  . tunnel                 /
                           |  .                       /
                           |  ...............        /
                           R2 --------------- P ----
                                          protector
                                         (protection
                                          service
                                          instances)


                                 Figure 1

5.2.  Egress node failure

   An egress node failure refers to the failure of an MPLS tunnel's
   egress router.  At service level, it also means a service instance
   failure for each IP/MPLS service carried by the tunnel.

   All the local failure detection mechanisms used by PLRs in transit
   link/node protection are applicable to egress node failure detection.
   In a case where a PLR does not have a fast and reliable mechanism to
   detect a node failure or distinguish between a link failure and a
   node failure, it may conservatively treat a link failure as a node
   failure and trigger egress node protection.





Yimin Shen, et al.       Expires August 5, 2017                 [Page 8]


Internet-Draft      MPLS Egress Protection Framework       February 2017


5.3.  Protector and PLR

   A router is assigned to the "protector" role to protect a tunnel and
   the services carried by the tunnel against an egress node failure.
   The protector is responsible for hosting a protection service
   instance for each protected service, serving as the tailend of a
   bypass tunnel, and performing context label switching and/or context
   IP forwarding for rerouted service packets.

   A tunnel can be protected by only one protector at a given time.
   Multiple tunnels to a given egress router may be protected by a
   common protector or different protectors.  A protector may protect
   multiple tunnels which may have a common egress router or different
   egress routers.

   For each tunnel, its penultimate-hop router acts as a PLR.  The PLR
   pre-establishes a bypass tunnel to the protector, and pre-installs
   bypass forwarding state in the data plane.  Upon detection of an
   egress node failure, the PLR reroutes all the service packets
   received on the tunnel though the bypass tunnel to the protector.
   For MPLS service packets, the PLR keeps service labels intact in the
   packets.  The protector in turn forwards rerouted service packets
   towards the ultimate service destinations.  Specifically, it performs
   context label switching for MPLS service packets, based on service
   labels assigned by the protected egress router; It performs context
   IP forwarding for IP service packets, based on their destination
   addresses.  The protector must have its own connectivity with each
   service destination, via a direct link or a multi-hop path, which
   must not traverse the protected egress router or be affected by the
   egress node failure.  This also means that each service destination
   must be dual-homed or have dual paths to the egress router and a
   backup egress router which serves as the protector.  Each protection
   service instance on the protector relies on such connectivity to set
   up forwarding state for context label switching and/or context IP
   forwarding.

5.4.  Protected egress

   This document introduces the notion of "protected egress" as a
   virtual node consisting of the egress router E of a tunnel and a
   protector P.  It is denoted by an ordered pair of {E, P}, indicating
   the primary-and-protector relationship between the two routers in the
   egress protection schema.  It serves as the virtual destination of
   the tunnel, and the virtual location of service instances for the
   services carried by the tunnel.  The tunnel and services are
   considered as being "associated" with the protected egress {E, P}.





Yimin Shen, et al.       Expires August 5, 2017                 [Page 9]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   A given egress router E may be the tailend of multiple tunnels.  In
   general, the tunnels may be protected by different protectors, e.g.
   P1, P2, and so on, with each Pi protecting a subset of the tunnels.
   Thus, these routers form multiple protected egress', i.e. {E, P1} ,
   {E, P2}, and so on.  Each tunnel is associated with one and only one
   protected egress {E, Pi}. All the services carried by the tunnel are
   then automatically associated with the same protected egress {E, Pi}.
   Conversely, a service associated with a protected egress {E, Pi} must
   be carried by a tunnel associated with the same protected egress {E,
   Pi}. This mapping must be ensured by the ingress router of the tunnel
   and the service (Section 5.7).

   Two routers X and Y may be protectors for each other.  In this case,
   they form two distinct protected egress {X, Y} and {Y, X}.

5.5.  Egress-protected tunnel

   A tunnel, which is associated with a protected egress {E, P}, is
   called an egress-protected tunnel.  An egress-protected tunnel is
   associated with one and only one protected egress {E, P}. Multiple
   egress-protected tunnels may be associated with a given protected
   egress {E, P}. In this case, they share the common egress router and
   protector, but may or may not share a common ingress router, a common
   path, or a common PLR.

   An egress-protected tunnel is considered as logically "destined" for
   its protected egress {E, P}. However, its path must be resolved and
   established with E as the physical tailend.

5.6.  Egress-protected service

   A service, which is associated with a protected egress {E, P}, is
   called an egress-protected service.  The egress router E hosts the
   primary instance of the service, and the protector P hosts the
   protection instance.

   An egress-protected service is associated with one and only one
   protected egress {E, P}. Multiple egress-protected services may be
   associated with a given protected egress {E, P}. In this case, these
   services share the common egress router and protector, but may or may
   not share a common egress-protected tunnel or a common ingress
   router.

5.7.  Egress-protected service to egress-protected tunnel mapping

   An egress-protected service must be mapped to an egress-protected
   tunnel by its ingress router, based on the common protected egress
   {E, P} of the service and the tunnel.  This is achieved by



Yimin Shen, et al.       Expires August 5, 2017                [Page 10]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   introducing the notion of "context ID" for protected egress {E, P},
   as described in (Section 5.9).

5.8.  Egress-protection bypass tunnel

   An egress-protected tunnel destined for a protected egress {E, P}
   must have a bypass tunnel from its PLR to the protector P.  This
   bypass tunnel is called an egress-protection bypass tunnel.  The
   bypass tunnel is considered as logically "destined" for the protected
   egress {E, P}. However, due to its bypass tunnel nature, it MUST be
   resolved and established with P as the physical tailend and E as the
   node to avoid.  The bypass tunnel MUST have the property that it is
   not affected by any topology change caused by an egress node failure.

   An egress-protection bypass tunnel is associated with one and only
   one protected egress {E, P}. A PLR may share an egress-protection
   bypass tunnel between multiple egress-protected tunnels associated
   with a common protected egress {E, P}. For multiple egress-protected
   tunnels associated with a common protected egress {E, P}, there may
   be one or multiple egress-protection bypass tunnels from one or
   multiple PLRs to the protector P.

5.9.  Context ID, context label, and context based forwarding

   In this framework, a globally unique IPv4/v6 address is assigned to a
   protected egress {E, P} to serve as the identifier of the protected
   egress {E, P}. It is called a "context ID" due to its specific usage
   in context label switching and context IP forwarding on the
   protector.  It is an IP address that is logically owned by both the
   egress router and the protector.  For the egress node, it indicates
   the protector.  For the protector, it indicates the egress router,
   particularly the egress router's forwarding context.  For other
   routers in the network, it is an address reachable via both the
   egress router and the protector in routing domain and TE domain
   (Section 5.10).

   The main purpose of a context ID is to coordinate ingress router,
   egress router, PLR and protector in setting up egress protection.
   Given an egress-protected service associated with a protected egress
   {E, P}, its context ID is used as below:

   o  If the service is an MPLS service, when E distributes the service
      label binding message to the ingress router, E attaches the
      context ID to the message.  If the service is an IP service, when
      E advertises the service destination address to the ingress
      router, E also attaches the context ID to the advertisement
      message.  How the context ID is encoded in the messages is a




Yimin Shen, et al.       Expires August 5, 2017                [Page 11]


Internet-Draft      MPLS Egress Protection Framework       February 2017


      choice of the service protocol, and may need protocol extensions
      to define a dedicated "context ID" object.

   o  The ingress router uses the context ID as destination to establish
      or resolve an egress-protected tunnel.  The ingress router then
      maps the service to the tunnel for transportation.

   o  The context ID is conveyed to the PLR by the signaling protocol of
      the egress-protected tunnel, or learned by the PLR via an IGP or
      topology-driven label distribution protocol.  The PLR uses the
      context ID as destination to establish or resolve an egress-
      protection bypass tunnel to P while avoiding E.

   o  P maintains a dedicated label space or a dedicated IP address
      space for E, depending on whether the service is MPLS or IP.  This
      is referred to as E's label space or E's IP address space,
      respectively.  P uses the context ID to identify the space.

   o  If the service is an MPLS service, E also distributes the service
      label binding message to P.  This is the same label binding
      message that E advertises to the ingress router, attached with the
      context ID.  Based on the context ID, P installs the service label
      in the MPLS forwarding table corresponding to E's label space.  If
      the service is an IP service, P installs an IP route in the IP
      forwarding table corresponding to E's IP address space.  In either
      case, the protection service instance on P interprets the service
      and constructs forwarding state for the route based on P's own
      connectivity to the service's destination.

   o  P assigns a non-reserved label to the context ID.  In the data
      plane, this label serves in the context ID's stead to indicate E's
      label space and IP address space.  Therefore, it is called a
      "context label".

   o  The PLR may establish the egress-protection bypass tunnel to P in
      several manners.  If the bypass tunnel is signaled by RSVP, its
      destination must be the context ID, and P binds the context label
      to the bypass tunnel.  If the bypass tunnel is established by LDP,
      P advertises the context label for the context ID as an IP prefix
      FEC.  If the bypass tunnel is established by the PLR in a
      hierarchical manner, the PLR treats the context label as a one-hop
      LSP over a regular bypass tunnel to P (e.g. a bypass tunnel to P's
      loopback IP address).  If the bypass tunnel is constructed by
      using segment routing, the bypass tunnel is represented by a stack
      of labels with the context label as the inner-most label
      (Section 5.11).  In any case, the bypass tunnel is a UHP tunnel
      whose incoming label at P is the context label.




Yimin Shen, et al.       Expires August 5, 2017                [Page 12]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   o  During local repair, all the service packets received by P on the
      bypass tunnel will have the context label as top label.  P will
      first pop the context label.  For MPLS service packets, P will
      further look up the service label in E's label space indicated by
      the context label, which is called context label switching.  For
      IP service packets, P will look up the IP destination address in
      E's IP address space indicated by the context label, which is
      called context IP forwarding.

5.10.  IGP advertisement and path resolution for context ID

   Path resolution or computation for context ID is done on ingress
   router for egress-protected tunnel, and on PLR for egress-protection
   bypass tunnel.  Therefore, given a protected egress {E, P} and its
   context ID, E and P must coordinate in IGP advertisement for the
   context ID in routing domain and TE domain.  The context ID must be
   advertised in such a manner that any egress-protected tunnels MUST
   have E as tailend, and any egress-protection bypass tunnels MUST have
   P as tailend while avoiding E.

   This document suggests two approaches:

   1.  The first approach is called "proxy mode".  It requires E and P,
       but not PLR, to have the knowledge of the egress protection
       schema.  E and P advertise the context ID as a virtual proxy node
       (i.e. a logical node) connected to the two routers, with the link
       between the proxy node and E having more preferable IGP and TE
       metrics than the link between the proxy node and P.  Therefore,
       all egress-protected tunnels destined for the context ID should
       automatically follow the shortest IGP paths or TE paths to E.
       Each PLR will no longer view itself as a penultimate-hop, but
       rather two hops away from the proxy node, via E.  The PLR will be
       able to find a bypass path via P to the proxy node, while the
       bypass tunnel should actually be terminated by P.

   2.  The second approach is called "alias mode".  It requires P and
       PLR, but not E, to have the knowledge of the egress protection
       schema.  E simply advertises the context ID as a regular IP
       address.  P advertises the context ID and the context label by
       using a "context ID label binding" advertisement.  The
       advertisement must be understood by the PLR.  In both routing
       domain and TE domain, the context ID is only reachable via E.
       This ensures that all egress-protected tunnels destined for the
       context ID should have E as tailend.  Based on the "context ID
       label binding" advertisement, the PLR can establish an egress-
       protection bypass tunnel in several manners (Section 5.11).  The
       "context ID label binding" advertisement may use the IGP




Yimin Shen, et al.       Expires August 5, 2017                [Page 13]


Internet-Draft      MPLS Egress Protection Framework       February 2017


       extensions for IGP mirroring context segment described in
       [SR-ARCH], [SR-OSPF] and [SR-ISIS].

5.11.  Egress-protection bypass tunnel establishment

   A PLR must know the context ID of a protected egress {E, P} in order
   to establish an egress-protection bypass tunnel.  The information is
   obtained from the signaling or label distribution protocol of egress-
   protected tunnel.  The PLR may or may not need to have the knowledge
   of egress protection schema.  All it does is to set up a bypass
   tunnel to a context ID while avoiding the next-hop router (i.e.
   egress router).  As the context ID is advertised in routing domain
   and TE domain by IGP according to Section 5.10, the PLR should be
   able to resolve or establish such a bypass path with the protector as
   tailend.  In some cases like the proxy mode, the PLR may do so in the
   same manner as transit node protection.

   An egress-protection bypass tunnel may be established via several
   methods:

   [1] It may be established by a signaling protocol (e.g.  RSVP), with
   the context ID as destination.  The protector binds the context label
   to the tunnel.

   [2] It may be formed by a topology driven protocol (e.g.  LDP).  The
   protector binds the context label to the context ID as an IP prefix
   FEC.

   [3] It may be constructed as a hierarchical tunnel.  When the
   protector uses the alias mode (Section 5.10), the PLR will have the
   knowledge of the context ID, context label, and protector (i.e. the
   advertiser).  The PLR can then establish the bypass tunnel in a
   hierarchical manner, with the context label as a one-hop LSP over a
   regular bypass tunnel to the protector's IP address (e.g. loopback
   address).  This regular bypass tunnel may be established by RSVP,
   LDP, and others.

   [4] It may be constructed by using segment routing.  In this case,
   the protector uses the alias mode (Section 5.10), and advertises the
   context ID and context label binding as an IGP mirroring context
   segment.  The PLR can then construct the bypass tunnel as a stack of
   labels, with the context label as the inner-most label.

5.12.  Local Repair on PLR

   A PLR is agnostic on services and services labels.  This obviates the
   need to maintain bypass forwarding state on per-service basis, and
   allows bypass tunnel sharing between egress-protected tunnels.



Yimin Shen, et al.       Expires August 5, 2017                [Page 14]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   During local repair, the PLR simply reroutes all service packets
   received on a tunnel to the corresponding bypass tunnel.  Service
   labels remain intact in MPLS service packets.

   Label operation during the rerouting depends on the bypass tunnel's
   characteristics.  If the bypass tunnel is a single level tunnel, the
   rerouting will involve swapping the incoming label of the egress-
   protected tunnel to the outgoing label of the bypass tunnel.  If the
   bypass tunnel is a hierarchical tunnel, the rerouting will involve
   swapping the incoming label of the egress-protected tunnel to a
   context label, and pushing the outgoing label of a regular bypass
   tunnel.  If the bypass tunnel is constructed by segment routing, the
   rerouting will involve swapping the incoming label of the egress-
   protected tunnel to a stack of labels, with a context label as the
   inner-most label.

5.13.  Service label distribution from egress router to protector

   As mentioned in previous sections, when a protector receives a
   rerouted MPLS service packet, it performs context label switching
   based on the packet's service label which is assigned by the
   corresponding egress router.  In order to achieve this, the protector
   MUST maintain such kind of service labels in dedicated label spaces
   on a per protected egress {E, P} basis, i.e. one label space for each
   egress router that it protects.

   Also, there must be a session of service label distribution protocol
   between each egress router and the protector.  Through this protocol,
   the protector learns the label binding of each egress-protected
   service.  This is the same label binding that the egress router
   advertises to the corresponding ingress router, attached with a
   context ID.  The corresponding protection service instance on the
   protector recognizes the service, and resolves forwarding state based
   on its own connectivity with the service's destination.  It installs
   the service label with the forwarding state in the label space of the
   egress router, as indicated by the context ID (i.e. context label).

   Different service protocols may use different mechanisms for such
   kind of label distribution.  Specific protocol extensions may be
   needed on a per protocol basis or per service type basis.  The
   details of the extensions are out of the scope of this framework, and
   SHOULD be specified in separate documents.

5.14.  Centralized protector mode

   In this framework, it is assumed that the service destination of an
   egress-protected service MUST be dual-homed to two edge routers of an
   MPLS network.  One of them is the protected egress router, and the



Yimin Shen, et al.       Expires August 5, 2017                [Page 15]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   other is a backup egress router.  So far in this document, the
   discussion has been focusing on the scenario where a protector and a
   backup egress router are co-located as one router.  Therefore, the
   number of protectors in a network is the number of backup egress
   routers.  As another scenario, a network may assign a small number of
   routers to serve as dedicated protectors, each protecting a subset of
   egress routers.  These protectors are called centralized protectors.

   Topologically, a centralized protector may be decoupled from all
   backup egress routers, or it may be co-located with one backup egress
   router while decoupled from the other backup egress routers.  The
   procedures in this section apply to egress-protected tunnels and
   services whose protectors and backup egress routers are strictly
   decoupled.



                  services 1, ..., N
        =====================================> tunnel

      I ------ R1 ------- PLR --------------- E ----
   ingress          penultimate-hop        egress    \
                           |  .           (primary    \
                           |  .            service     \
                           |  .            instances)   \
                           |  .                          \
                           |  . bypass                    \   service
                          R2  . tunnel                      destinations
                           |  .                           / (CEs, sites)
                           |  .                          /
                           |  .                         /
                           |  .                        /
                           |  .    tunnel             /
                           |   =============>        /
                           P ---------------- E' ---
                       protector        backup egress
                      (protection          (backup
                       service              service
                       instances)           instances)


                                 Figure 2

   Like a co-located protector, a centralized protector hosts protection
   service instances, receives rerouted service packets from PLRs, and
   performs context label switching and/or context IP forwarding.  For
   each service, instead of sending service packets directly to the
   service destination, the protector MUST send them via a transport



Yimin Shen, et al.       Expires August 5, 2017                [Page 16]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   tunnel to the corresponding backup service instance on a backup
   egress router.  The backup service instance in turn forwards them to
   the service destination.  Specifically, in the case of an MPLS
   service, the protector MUST swap the service label in each received
   service packet to the label of the backup service advertised by the
   backup egress router, and then push a label (or label stack) of the
   transport tunnel.

   In order for a centralized protector to map an egress-protected MPLS
   service to a service hosted on a backup egress router, there MUST be
   a session of service label distribution protocol between the backup
   egress router and the protector, in addition to the session between
   the egress router and the protector (Section 5.13).  Through this
   session, the backup egress router advertises the service label of the
   backup service, attached with the FEC of the egress-protected service
   and the context ID of the protected egress {E, P}. Based on this
   information, the protector associates the egress-protected service
   with the backup service, resolves or establishes a transport tunnel
   to the backup egress router, and accordingly sets up forwarding state
   for the label of the egress-protected service in the label space of
   the egress router.

   The service label which the backup egress router advertises to the
   protector can be the same as the label which the backup egress router
   advertises to ingress router(s), if and only if the forwarding state
   of the label does not direct service packets towards the egress
   router.  Otherwise, the label is not usable for egress protection,
   because it will loop rerouted service packets back to the egress
   router which should be avoided.  In this case, the backup egress
   router MUST advertise a unique service label dedicated for egress
   protection, and set its forwarding state to use the backup egress
   router's connectivity with the service destination.

6.  Egress link protection

   In normal situations, an egress router forwards service packets to a
   service destination based on a service label.  The service label is
   advertised by this egress router, and the service label's forwarding
   state points to an egress link.  In egress link protection, the
   egress router acts as PLR by performing local failure detection and
   local repair.  Specifically, the egress router pre-establishes an
   egress-protection bypass tunnel to a protector, and installs bypass
   forwarding state for the service label, pointing to the bypass
   tunnel.  During local repair, the egress router reroutes service
   packets via the bypass tunnel to the protector.  The protector in
   turn forwards the packets to the service destination (in the co-
   located protector mode), or forwards the packets first to a backup
   egress router and then to the service destination (in the centralized



Yimin Shen, et al.       Expires August 5, 2017                [Page 17]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   protector mode).  This is shown in Figure-3 and Figure-4,
   respectively.


                    any given service
        =====================================> tunnel

      I ------ R1 -------  R2 --------------- E ----
   ingress                 |  ............. egress   \
                           |  .              PLR      \
                           |  .            (primary    \
                           |  .             service     \
                           |  .             instance)    \
                           |  .                           \
                           |  . bypass                        service
                           |  . tunnel                      destination
                           |  .                           / (CE, site)
                           |  .                          /
                           |  .                         /
                           |  .                        /
                           |  .                       /
                           |  ...............        /
                           R3 --------------- P ----
                                          protector
                                         (protection
                                          service
                                          instance)

                                 Figure 3






















Yimin Shen, et al.       Expires August 5, 2017                [Page 18]


Internet-Draft      MPLS Egress Protection Framework       February 2017


                    any given service
        =====================================> tunnel

      I ------ R1 -------  R2 --------------- E ----
   ingress                 |  ............. egress   \
                           |  .              PLR      \
                           |  .            (primary    \
                           |  .             service     \
                           |  .             instance)   \
                           |  .                           \
                           |  . bypass                        service
                           |  . tunnel                      destination
                           |  .                           / (CE, site)
                           |  .                          /
                           |  .                         /
                           |  .                        /
                           |  .    tunnel             /
                           |   =============>        /
                           R3 --------------- P ----
                       protector        backup egress
                      (protection         (backup
                       service             service
                       instance)           instance)


                                 Figure 4

   There are two approaches to set up the bypass forwarding state on the
   egress router, depending on the service label distribution mode of
   the given service.  The difference is that one approach requires the
   protector to perform context label switching, and the other one does
   not.  Therefore, the first approach is more consistent with egress
   node protection.

      [1] The first approach applies when the egress router does not
      know or care about the service label advertised by the backup
      egress router.  This is often the case when the egress router
      advertises its service label to the ingress router over a targeted
      protocol session.  In this case, the egress router can set up the
      bypass forwarding state as a label push with the outgoing label of
      the egress-protection bypass tunnel.  Rerouted packets will have
      the egress router's service label intact.  Therefore, the
      protector MUST perform context label switching.  The bypass tunnel
      MUST be destined for the context ID of the {egress router,
      protector} and established as described in Section 5.11.  The
      protector serves both egress node protection and egress link
      protection, in both the co-located and centralized protector
      modes.



Yimin Shen, et al.       Expires August 5, 2017                [Page 19]


Internet-Draft      MPLS Egress Protection Framework       February 2017


      [2] The second approach applies when the egress router knows the
      service label advertised by the backup egress router.  This is
      often the case when the type of service uses BGP as the service
      label distribution protocol.  Since BGP normally distributes
      service labels over a full mesh of BGP sessions between all PEs,
      the egress router can automatically learn the service label of the
      backup egress router.  In this case, the backup egress router MUST
      serve as the protector for egress link protection, regardless of
      the protector of egress node protection, which should be the same
      router in the co-located protector mode but may be a different
      router in the centralized protector mode.  The egress router can
      set up the bypass forwarding state as a label swap from the
      incoming service label to the service label of the protector,
      followed by a label push with the outgoing label of the egress-
      protection bypass tunnel.  In this case, the bypass tunnel MUST be
      a regular tunnel destined for an IP address of the protector,
      instead of the context ID of the {egress router, protector}. The
      protector will simply forward rerouted packets based on its own
      service label, rather than performing context label switching.
      This forwarding behavior is different than that of a protector in
      the approach [1] and a protector in egress node protection.

   In a network where different types of services co-exist, the two
   approaches may be used in parallel, or the approach [1] may be used
   consistently for all types of services.

   Note that for a bidirectional service, the physical link of an egress
   link may carry service traffic bidirectionally.  Therefore, a failure
   of the physical link may be considered as an egress link failure for
   the traffic towards the service destination, as well as an ingress
   link failure for the traffic in the opposite direction.  However,
   protection for ingress link failure should be provided by a separate
   mechanism, and hence is out of the scope of this framework.

7.  Global repair

   This framework provides a fast but temporary repair for traffic upon
   an egress node/link failure.  For permanent repair, it is RECOMMENDED
   that the traffic SHOULD be moved to an alternative tunnel or
   alternative services that are fully functional.  This is referred to
   as global repair.  Possible triggers of global repair include control
   plane notifications for tunnel and service status, end-to-end OAM and
   fault detection at tunnel or service levels, and others.  These
   alternative tunnel and services may be pre-established as backups, or
   newly established as a result of the triggers or network protocol
   convergence.





Yimin Shen, et al.       Expires August 5, 2017                [Page 20]


Internet-Draft      MPLS Egress Protection Framework       February 2017


8.  Example: Layer-3 VPN egress protection

   This section shows an example of egress protection for a layer-3 VPN.



                          ---------- R1 ----------- PE2 -
                         /          (PLR)          (PLR)  \
  (  site 1   )         /            |               |     (  site 2   )
  (           )        /             |               |     (           )
  (  subnet   )-- PE1 <              |               R3    (  subnet   )
  ( 8.0.0.0/8 )        \             |               |     ( 9.0.0.0/8 )
  (           )         \            |               |     (           )
                         \           |               |    /
                          ---------- R2 ----------- PE3 -
                                                (protector)


                                 Figure 5

   In this example, the site 1 of a given VPN is attached to PE1, and
   site 2 is dual-homed to PE2 and PE3.  PE2 is the primary PE for site
   2, and PE3 is the backup PE.  Every PE hosts a VPN instance.  R1 and
   R2 are transit routers in the MPLS network.  The network uses OSPF as
   routing protocol, and RSVP-TE as tunnel signaling protocol.  The PEs
   use BGP to exchange VPN prefixes and VPN labels between each other.

   Using the framework in this document, the network assigns PE3 to be a
   protector for PE2 to protect the VPN traffic in the direction from
   site 1 to site 2.  This is the co-located protector mode.  Hence, PE2
   and PE3 form a protected egress {PE2, PE3}. A context ID 1.1.1.1 is
   assigned to the protected egress {PE2, PE3}. The VPN instance on PE3
   serves as a protection instance for the VPN instance on PE2.  On PE3,
   a context label 100 is assigned to the context ID, and a label table
   pe2.mpls is created to represent PE2's label space.  PE3 installs the
   label 100 in its default MPLS forwarding table, with nexthop pointing
   to the label table pe2.mpls.  PE2 and PE3 are coordinated to use the
   proxy mode to advertise the context ID in routing domain and TE
   domain.

   PE2 uses per-VRF VPN label allocation mode.  It assigns a single
   label 9000 for the VRF of the VPN.  For a given VPN prefix 9.0.0.0/8
   in site 2, PE2 advertises it along with the label 9000 and other
   attributes to PE1 and PE3 via BGP.  In particular, the NEXT_HOP
   attribute is set to the context ID 1.1.1.1.

   Similarly, PE3 also uses per-VRF VPN label allocation mode.  It
   assigns a single label 10000 for the VRF of the VPN.  For the VPN



Yimin Shen, et al.       Expires August 5, 2017                [Page 21]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   prefix 9.0.0.0/8 in site 2, PE3 advertises it along with the label
   10000 and other attributes to PE1 and PE2 via BGP.  In particular,
   the NEXT_HOP attribute is set to an IP address of PE3.

   Upon receipt and acceptance of the BGP advertisement, PE1 uses the
   context ID 1.1.1.1 as destination to compute a TE path for an egress-
   protected tunnel.  The resulted path is PE1->R1->PE2.  PE1 then uses
   RSVP to signal the tunnel, with the context ID 1.1.1.1 as
   destination, and with the "node protection desired" flag set in the
   SESSION_ATTRIBUTE of RSVP Path message.  Once the tunnel comes up,
   PE1 maps the VPN prefix 9.0.0.0/8 to the tunnel and installs a route
   for the prefix in the corresponding VRF.  The route's nexthop is a
   push with the VPN label 9000, followed by a push with the outgoing
   label of the egress-protected tunnel.

   Upon receipt of the above BGP advertisement from PE2, PE3 (i.e. the
   protector) recognizes the context ID 1.1.1.1 in the NEXT_HOP
   attribute, and installs a route for label 9000 in the label table
   pe2.mpls.  PE3 sets the route's nexthop to a "protection VRF".  This
   protection VRF contains IP routes corresponding to the IP prefixes in
   the dual-homed site 2, including 9.0.0.0/8.  The nexthops of these
   routes MUST be based on PE3's connectivity with site 2 even if this
   connectivity is not the best path in PE3's VRF due to metrics (e.g.
   MED, loc preference, etc), and MUST NOT use any path traversing PE2.
   Note that the protection VRF is a logical concept, and it may simply
   be PE3's own VRF if the VRF satisfies the requirement.

8.1.  Egress node protection

   R1, i.e. the penultimate-hop router of the egress-protected tunnel,
   serves as the PLR for egress node protection.  Based on the "node
   protection desired" flag and the destination address (i.e. context ID
   1.1.1.1) of the tunnel, R1 computes a bypass path to 1.1.1.1 while
   avoiding PE2.  The resulted bypass path is R1->R2->PE3.  R1 then
   signals the path as an egress-protection bypass tunnel, with 1.1.1.1
   as destination.

   Upon receipt of RSVP Path message of the egress-protection bypass
   tunnel, PE3 recognizes the context ID 1.1.1.1 as the destination, and
   hence responds with the context label 100 in RSVP Resv message.

   After the egress-protection bypass tunnel comes up, R1 installs a
   bypass nexthop for the egress-protected tunnel.  The bypass nexthop
   is a swap from the incoming label of the egress-protected tunnel to
   the outgoing label of the egress-protection bypass tunnel.

   When R1 detects a failure of PE2, it will invoke the above bypass
   nexthop to reroute VPN service packets.  The packets will have the



Yimin Shen, et al.       Expires August 5, 2017                [Page 22]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   label of the bypass tunnel as outer label, and the VPN label 9000 as
   inner label.  When the packets arrive at PE3, they will have the
   context label 100 as outer label, and the VPN label 9000 as inner
   label.  The context label will first be popped, and then the VPN
   label will be looked up in the label table pe2.mpls.  The lookup will
   cause the VPN label to be popped, and the IP packets will finally be
   forwarded to site 2 based on the protection VRF.

8.2.  Egress link protection

   PE2 serves as the PLR for egress link protection.  It has already
   learned the VPN label 10000 from PE3, and hence it uses the approach
   [2] described in Section 6 to set up bypass forwarding state.  It
   signals an egress-protection bypass tunnel to PE3, by using
   PE2->R3->PE3 as path, and PE3's IP address as destination.  After the
   bypass tunnel comes up, PE2 installs a bypass nexthop for the VPN
   label 9000.  The bypass nexthop is a label swap from the incoming
   label 9000 to the VPN label 10000 of PE3, followed by a label push
   with the outgoing label of the bypass tunnel.

   When PE3 detects a failure of the egress link, it will invoke the
   above bypass nexthop to reroute VPN service packets.  The packets
   will have the label of the bypass tunnel as outer label, and the VPN
   label 10000 as inner label.  When the packets arrive at PE3, the VPN
   label 10000 will be popped, and the IP packets will be forwarded
   based on the VRF indicated by on the VPN label 10000.

8.3.  Global repair

   Eventually, global repair will take effect, as control plane
   protocols converge on the new topology.  PE1 will choose PE3 as new
   entrance to site 2.  Before that happens, the VPN traffic has been
   protected by the above local repair.

9.  IANA Considerations

   This document has no request for new IANA allocation.

10.  Security Considerations

   As with any kind of fast reroute mechanisms, the framework in this
   document relies on traffic rerouting around a network failure.
   Specifically, service traffic can be temporarily rerouted by a PLR to
   a protector.  In the centralized protector mode, the traffic can be
   further rerouted to a backup egress router.  The rerouted traffic is
   planned and anticipated, and hence it should not be viewed as a new
   security threat.




Yimin Shen, et al.       Expires August 5, 2017                [Page 23]


Internet-Draft      MPLS Egress Protection Framework       February 2017


   The framework requires a label distribution protocol to run between
   an egress router and a protector, which is achievable in a secured
   fashion.

11.  Acknowledgements

   This document leverages work done by Yakov Rekhter, Kevin Wang and
   Zhaohui Zhang on MPLS egress protection.

12.  References

12.1.  Normative References

   [SR-ARCH]  Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
              and R. Shakir, "Segment Routing Architecture", draft-ietf-
              spring-segment-routing (work in progress), 2016.

   [SR-OSPF]  Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
              Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
              Extensions for Segment Routing", draft-ietf-ospf-segment-
              routing-extensions (work in progress), 2016.

   [SR-ISIS]  Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
              Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
              Extensions for Segment Routing", draft-ietf-isis-segment-
              routing-extensions (work in progress), 2016.

12.2.  Informative References

   [RFC4090]  Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
              Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
              DOI 10.17487/RFC4090, May 2005,
              <http://www.rfc-editor.org/info/rfc4090>.

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

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

   [RFC7812]  Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
              IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-
              FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
              <http://www.rfc-editor.org/info/rfc7812>.



Yimin Shen, et al.       Expires August 5, 2017                [Page 24]


Internet-Draft      MPLS Egress Protection Framework       February 2017


Authors' Addresses

   Yimin Shen
   Juniper Networks
   10 Technology Park Drive
   Westford, MA  01886
   USA

   Phone: +1 9785890722
   Email: yshen@juniper.net


   Minto Jeyananth
   Juniper Networks
   1133 Innovation Way
   Sunnyvale, CA  94089
   USA

   Phone: +1 4089367563
   Email: minto@juniper.net


   Bruno Decraene
   Orange

   Email: bruno.decraene@orange.com


   Hannes Gredler
   RtBrick Inc

   Email: hannes@rtbrick.com


   Carsten Michel
   Deutsche Telekom

   Email: c.michel@telekom.de













Yimin Shen, et al.       Expires August 5, 2017                [Page 25]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/