Internet DRAFT - draft-ietf-mpls-egress-protection-framework

draft-ietf-mpls-egress-protection-framework







Internet Engineering Task Force                               Yimin Shen
Internet-Draft                                           Minto Jeyananth
Intended status: Standards Track                        Juniper Networks
Expires: February 1, 2020                                 Bruno Decraene
                                                                  Orange
                                                          Hannes Gredler
                                                             RtBrick Inc
                                                          Carsten Michel
                                                        Deutsche Telekom
                                                             Huaimo Chen
                                           Huawei Technologies Co., Ltd.
                                                           July 31, 2019


                    MPLS Egress Protection Framework
             draft-ietf-mpls-egress-protection-framework-07

Abstract

   This document specifies a fast reroute framework for protecting IP/
   MPLS services and MPLS transport tunnels against egress node and
   egress link failures.  For each type of egress failure, it defines
   the roles of point of local repair (PLR), protector, and backup
   egress router, and the procedures of establishing a bypass tunnel
   from a PLR to a protector.  It describes the behaviors of these
   routers in handling an egress failure, including local repair on the
   PLR, and context-based forwarding on the protector.  The framework
   can be used to develop egress protection mechanisms to reduce traffic
   loss before global repair reacts to an egress failure and control
   plane protocols converge on the topology changes due to the egress
   failure.

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 https://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 February 1, 2020.



Yimin Shen, et al.      Expires February 1, 2020                [Page 1]

Internet-Draft      MPLS Egress Protection Framework           July 2019


Copyright Notice

   Copyright (c) 2019 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
   (https://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  . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Egress node protection  . . . . . . . . . . . . . . . . . . .   8
     5.1.  Reference topology  . . . . . . . . . . . . . . . . . . .   8
     5.2.  Egress node failure and detection . . . . . . . . . . . .   8
     5.3.  Protector and PLR . . . . . . . . . . . . . . . . . . . .   9
     5.4.  Protected egress  . . . . . . . . . . . . . . . . . . . .  10
     5.5.  Egress-protected tunnel and service . . . . . . . . . . .  11
     5.6.  Egress-protection bypass tunnel . . . . . . . . . . . . .  11
     5.7.  Context ID, context label, and context-based forwarding .  12
     5.8.  Advertisement and path resolution for context ID  . . . .  13
     5.9.  Egress-protection bypass tunnel establishment . . . . . .  15
     5.10. Local repair on PLR . . . . . . . . . . . . . . . . . . .  16
     5.11. Service label distribution from egress router to
           protector . . . . . . . . . . . . . . . . . . . . . . . .  16
     5.12. Centralized protector mode  . . . . . . . . . . . . . . .  17
   6.  Egress link protection  . . . . . . . . . . . . . . . . . . .  19
   7.  Global repair . . . . . . . . . . . . . . . . . . . . . . . .  22
   8.  Operational Considerations  . . . . . . . . . . . . . . . . .  22
   9.  General context-based forwarding  . . . . . . . . . . . . . .  23
   10. Example: Layer-3 VPN egress protection  . . . . . . . . . . .  23
     10.1.  Egress node protection . . . . . . . . . . . . . . . . .  25
     10.2.  Egress link protection . . . . . . . . . . . . . . . . .  25
     10.3.  Global repair  . . . . . . . . . . . . . . . . . . . . .  26
     10.4.  Other modes of VPN label allocation  . . . . . . . . . .  26
   11. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  26
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  26
   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  27
   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  28



Yimin Shen, et al.      Expires February 1, 2020                [Page 2]

Internet-Draft      MPLS Egress Protection Framework           July 2019


     14.1.  Normative References . . . . . . . . . . . . . . . . . .  28
     14.2.  Informative References . . . . . . . . . . . . . . . . .  28
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  29

1.  Introduction

   In MPLS networks, label switched paths (LSPs) 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, if the tunnel satisfies
   both individual and aggregate requirements (e.g., CoS, QoS) of these
   services.  The egress router of the tunnel hosts the service
   instances of the services.  An MPLS service instance forwards service
   packets via an egress link to the service destination, based on a
   service label.  An IP service instance does the same based on a
   service IP 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], and [RFC7812]) have been widely deployed to
   protect MPLS tunnels against transit link/node failures, with traffic
   restoration time in the order of tens of milliseconds.  Local repair
   refers to the scenario where the router upstream to an anticipated
   failure, a.k.a.  PLR (point of local repair), pre-establishes a
   bypass tunnel to the router downstream of the failure, a.k.a.  MP
   (merge point), pre-installs the forwarding state of the bypass tunnel
   in the data plane, and 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 specifies a fast reroute framework for egress node and
   egress link protection.  Similar to transit link/node protection,
   this framework also relies on a PLR to perform local failure
   detection and local repair.  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.  The framework further
   uses a so-called "protector" to serve as the tailend of a bypass
   tunnel.  The protector is a router that hosts "protection service
   instances" and has its own connectivity or paths to service
   destinations.  When a PLR does local repair, the protector performs
   "context label switching" for rerouted MPLS service packets and
   "context IP forwarding" for rerouted IP service packets, to allow the
   service packets to continue to reach the service destinations.





Yimin Shen, et al.      Expires February 1, 2020                [Page 3]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   This framework considers an egress node failure as a failure of a
   tunnel, and a failure of all the services carried by the tunnel, as
   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 the 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, via
   two MPLS edge routers.  One of the routers is the egress router of
   the service's transport tunnel, and the other is a backup egress
   router which hosts a "backup service instance".  In the "co-located"
   protector mode in this document, the backup egress router serves as
   the protector, and hence the backup service instance acts as the
   protection service instance.  In the "centralized" protector mode
   (Section 5.12), the protector and the backup egress router are
   decoupled, and the protection service instance and the backup service
   instance are hosted separately by the two routers.

   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, as the sub-LSPs of these tunnels can be viewed
   as P2P tunnels.

   The framework is a multi-service and multi-transport framework.  It
   assumes a generic model where each service is comprised of a common
   set of components, including a service instance, a service label, a
   service label distribution protocol, and an MPLS transport tunnel.
   The framework also assumes the service label to be downstream
   assigned, i.e., assigned by an egress router.  Therefore, the
   framework is generally applicable to most existing and future
   services.  However, there are services with certain modes, where a
   protector is unable to pre-establish forwarding state for egress
   protection, or a PLR is not allowed to reroute traffic to other
   routers in order to avoid traffic duplication, e.g., the broadcast,
   multicast, and unknown unicast traffic in VPLS and EVPN.  These cases
   are left for future study.  Services which use upstream-assigned
   service labels are also out of scope of this document and left for
   future study.

   The framework does not require extensions for the existing signaling
   and label distribution protocols (e.g., RSVP, LDP, BGP, etc.) of MPLS
   tunnels.  It assumes transport tunnels and bypass tunnels to be
   established by using the generic procedures provided by the
   protocols.  On the other hand, it does not preclude extensions to the



Yimin Shen, et al.      Expires February 1, 2020                [Page 4]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   protocols which may facilitate the procedures.  One example of such
   extension is [RFC8400].  The framework does see the need for
   extensions of IGPs and service label distribution protocols in some
   procedures, particularly for supporting protection establishment and
   context label switching.  This document provides guidelines for these
   extensions, but leaves the specific details to separate documents.

   The framework is intended to complement control-plane convergence and
   global repair.  Control-plane convergence relies on control protocols
   to react on the topology changes due to a failure.  Global repair
   relies an ingress router to remotely detect a failure and switch
   traffic to an alternative path.  An example of global repair is the
   BGP Prefix Independent Convergence mechanism [BGP-PIC] for BGP
   established services.  Compared with these mechanisms, this framework
   is considered as faster in traffic restoration, due to the nature of
   local failure detection and local repair.  It is RECOMMENDED that the
   framework be used in conjunction with control-plane convergence or
   global repair, in order to take the advantages of both approaches.
   That is, the framework provides fast and temporary repair, while
   control-plane convergence or global repair provides ultimate and
   permanent repair.

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] and
   [RFC8174].

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 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 a mechanism according to this framework.  The egress router is
   hence called a protected egress router.






Yimin Shen, et al.      Expires February 1, 2020                [Page 5]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   Egress-protected service - An IP or MPLS service which is carried by
   an egress-protected tunnel, and hence protected by a mechanism
   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.

   Backup service instance - A service instance which is hosted by a
   backup egress router, and corresponding to 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.  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, corresponding to the service instance of an egress-
   protected 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 the 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 of an egress-protected tunnel, and as the virtual
   location of 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 - A tunnel used to reroute service
   packets around an egress failure.

   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.




Yimin Shen, et al.      Expires February 1, 2020                [Page 6]

Internet-Draft      MPLS Egress Protection Framework           July 2019


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

   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 following as the design requirements of
   this egress protection framework.

   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 RSVP, 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 general solution for networks where
      different types of services and tunnels co-exist.

   o  The framework must consider minimizing disruption during
      deployment.  It should only involve routers close to egress, and
      be transparent to ingress routers and other transit routers.

   o  In egress node protection, for scalability and performance
      reasons, a PLR must be agnostic to services and service labels.
      It must maintain bypass tunnels and bypass forwarding state on a
      per-transport-tunnel basis, rather than on a 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 or TE topology to compute or resolve a path for a bypass
      tunnel.

   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.



Yimin Shen, et al.      Expires February 1, 2020                [Page 7]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   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.

5.  Egress node protection

5.1.  Reference topology

   This document refers to the following topology when describing the
   procedures of 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 and detection

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

   An egress node failure can be detected by an adjacent router (i.e.,
   PLR in this framework) through a node liveness detection mechanism,



Yimin Shen, et al.      Expires February 1, 2020                [Page 8]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   or a mechanism based on a collective failure of all the links to that
   node.  The mechanisms MUST be reasonably fast, i.e., faster than
   control plane failure detection and remote failure detection.
   Otherwise, local repair will not be able to provide much benefit
   compared to control plane convergence or global repair.  In general,
   the speed, accuracy, and reliability of a failure detection mechanism
   are the key factors to decide its applicability in egress node
   protection.  This document provides the following guidelines for
   network operators to choose a proper type of protection on a PLR.

   o  If the PLR has a mechanism to detect and differentiate a link
      failure (of the link between the PLR and the egress node) and an
      egress node failure, it SHOULD set up both link protection and
      egress node protection, and trigger one and only one protection
      upon a corresponding failure.

   o  If the PLR has a fast mechanism to detect a link failure and an
      egress node failure, but cannot distinguish them; or, if the PLR
      has a fast mechanism to detect a link failure only, but not an
      egress node failure, the PLR has two options:

      1.  It MAY set up link protection only, and leave the egress node
          failure to be handled by global repair and control plane
          convergence.

      2.  It MAY set up egress node protection only, and treat a link
          failure as a trigger for the egress node protection.  The
          assumption is that treating a link failure as an egress node
          failure MUST NOT have a negative impact on services.
          Otherwise, it SHOULD adopt the previous option.

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 is protected by only one protector.  Multiple tunnels to a
   given egress router may be protected by a common protector or
   different protectors.  A protector may protect multiple tunnels with
   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



Yimin Shen, et al.      Expires February 1, 2020                [Page 9]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   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 the service packets towards
   the ultimate service destinations.  Specifically, it performs context
   label switching for MPLS service packets, based on the 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 may serve as the protector.  Each protection
   service instance on the protector relies on such connectivity to set
   up forwarding state for context label switching and 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.  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}.

   A given egress router E may be the tailend of multiple tunnels.  In
   general, the tunnels may be protected by multiple protectors, e.g.,
   P1, P2, and so on, with each Pi protecting a subset of the tunnels.
   Thus, these routers form multiple protected egresses, 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 protected egress {E, Pi}.
   Conversely, a service associated with a protected egress {E, Pi} MUST
   be carried by a tunnel associated with the protected egress {E, Pi}.
   This mapping MUST be ensured by the ingress router of the tunnel and
   the service (Section 5.5).

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






Yimin Shen, et al.      Expires February 1, 2020               [Page 10]

Internet-Draft      MPLS Egress Protection Framework           July 2019


5.5.  Egress-protected tunnel and service

   A tunnel, which is associated with a protected egress {E, P}, is
   called an egress-protected tunnel.  It 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, or a common PLR (i.e., penultimate-hop
   router).

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

   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 of the service.

   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 be carried by a common egress-protected tunnel or a common
   ingress router.

   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
   introducing the notion of "context ID" for protected egress {E, P},
   as described in (Section 5.7).

5.6.  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}. Due to its bypass nature, it MUST be established with
   P as the physical tailend and E as the node to avoid.  The bypass
   tunnel MUST have the property that it MUST NOT be affected by the
   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 for multiple egress-protected tunnels associated with a
   common protected egress {E, P}.




Yimin Shen, et al.      Expires February 1, 2020               [Page 11]

Internet-Draft      MPLS Egress Protection Framework           July 2019


5.7.  Context ID, context label, and context-based forwarding

   In this framework, a globally unique IPv4 or IPv6 address is assigned
   to a protected egress {E, P} 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 router, 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 (Section 5.8), similar to an anycast
   address.

   The main purpose of a context ID is to coordinate ingress router,
   egress router, PLR and protector to establish egress protection.  The
   procedures are described below, given an egress-protected service
   associated with a protected egress {E, P} with context ID.

   o  If the service is an MPLS service, when E distributes a 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 attaches the context ID to the advertisement message.
      How the context ID is encoded in the messages is a choice of the
      service protocol.  A protocol extension of a "context ID" object
      may be needed, if there is no existing mechanism for this purpose.

   o  The ingress router uses the service's context ID as the
      destination to establish or resolve an egress-protected tunnel.
      The ingress router then maps the service to the tunnel for
      transportation.  The semantics of the context ID is transparent to
      the ingress router.  The ingress router only treats the context ID
      as an IP address of E, in the same manner as establishing or
      resolving a regular transport tunnel.

   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
      (i.e., OSPF or ISIS) or a topology-driven label distribution
      protocol (e.g., LDP).  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 and a dedicated IP address
      space for E.  They are referred to as "E's label space" and "E's
      IP address space", respectively.  P uses the context ID to
      identify the label space and IP address space.




Yimin Shen, et al.      Expires February 1, 2020               [Page 12]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   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, which includes
      the context ID.  Based on the context ID, P installs the service
      label in an MPLS forwarding table corresponding to E's label
      space.  If the service is an IP service, P installs an IP route in
      an IP forwarding table corresponding to E's IP address space.  In
      either case, the protection service instance on P constructs
      forwarding state for the label route or IP route based on P's own
      connectivity with the service's destination.

   o  P assigns a non-reserved label to the context ID.  In the data
      plane, this label represents the context ID and indicates 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 established by RSVP, the
      PLR signals the bypass tunnel with the context ID as destination,
      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 SID labels with the context
      label as the inner-most SID label (Section 5.9).  In any case, the
      bypass tunnel is a ultimate-hop-popping (UHP) tunnel whose
      incoming label on P is the context label.

   o  During local repair, all the service packets received by P on the
      bypass tunnel have the context label as the top label.  P first
      pops the context label.  For an MPLS service packet, P further
      looks up the service label in E's label space indicated by the
      context label.  Such kind of forwarding is called context label
      switching.  For an IP service packet, P looks up the IP
      destination address in E's IP address space indicated by the
      context label.  Such kind of forwarding is called context IP
      forwarding.

5.8.  Advertisement and path resolution for context ID

   Path resolution and computation for a context ID are done on ingress
   routers for egress-protected tunnels, and on PLRs for egress-
   protection bypass tunnels.  Given a protected egress {E, P} and its
   context ID, E and P MUST coordinate on the reachability of the
   context ID in the routing domain and the TE domain.  The context ID



Yimin Shen, et al.      Expires February 1, 2020               [Page 13]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   MUST be advertised in such a manner that all egress-protected tunnels
   MUST have E as tailend, and all egress-protection bypass tunnels MUST
   have P as tailend while avoiding E.

   This document suggests three approaches:

   1.  The first approach is called "proxy mode".  It requires E and P,
       but not the 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 will automatically follow the IGP 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 is actually be terminated by P.

   2.  The second approach is called "alias mode".  It requires P and
       the PLR, but not E, to have the knowledge of the egress
       protection schema.  E simply advertises the context ID as an IP
       address.  P advertises the context ID and the context label by
       using a "context ID label binding" advertisement.  In both
       routing domain and TE domain, the context ID is only reachable
       via E.  Therefore, all egress-protected tunnels destined for the
       context ID will 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.9).  The
       "context ID label binding" advertisement is defined as IGP
       mirroring context segment in [RFC8402] and [SR-ISIS].  These IGP
       extensions are generic in nature, and hence can be used for
       egress protection purposes.  It is RECOMMENDED that a similar
       advertisement be defined for OSPF as well.

   3.  The third approach is called "stub link mode".  In this mode,
       both E and P advertise the context ID as a link to a stub
       network, essentially modelling the context ID as an anycast IP
       address owned by the two routers.  E, P and the PLR do not need
       to have the knowledge of the egress protection schema.  The
       correctness of the egress-protected tunnels and the bypass
       tunnels relies on the path computations for the anycast IP
       address performed by the ingress routers and PLR.  Therefore,
       care MUST be taken for the applicability of this approach to a
       network.

   This framework considers the above approaches as technically equal,
   and the feasibility of each approach in a given network as dependent



Yimin Shen, et al.      Expires February 1, 2020               [Page 14]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   on the topology, manageability, and available protocols of the
   network.  For a given context ID, all relevant routers, including
   primary PE, protector, and PLR, MUST support and agree on the chosen
   approach.  The coordination between these routers can be achieved by
   configuration.

   In a scenario where an egress-protected tunnel is an inter-area or
   inter-AS tunnel, its associated context ID MUST be propagated by IGP
   or BGP from the original area or AS to the area or AS of the ingress
   router.  The propagation process of the context ID SHOULD be the same
   as that of an IP address in an inter-area or inter-AS environment.

5.9.  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 the
   egress-protected tunnel.  The PLR may or may not need to have the
   knowledge of the 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).  This is achievable by using a constraint-
   based computation algorithm similar to those commonly used for
   traffic engineering paths and loop-free alternate (LFA) paths.  Since
   the context ID is advertised in the routing domain and the TE domain
   by IGP according to Section 5.8, the PLR is able to resolve or
   establish such a bypass path with the protector as tailend.  In the
   case of 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 bypass tunnel.

   (2) It may be formed by a topology driven protocol (e.g., LDP with
   various LFA mechanisms).  The protector advertises the context ID as
   an IP prefix FEC, with the context label bound to it.

   (3) It may be constructed as a hierarchical tunnel.  When the
   protector uses the alias mode (Section 5.8), 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, segment routing, or another protocol.



Yimin Shen, et al.      Expires February 1, 2020               [Page 15]

Internet-Draft      MPLS Egress Protection Framework           July 2019


5.10.  Local repair on PLR

   In this framework, a PLR is agnostic to services and service labels.
   This obviates the need to maintain bypass forwarding state on a per-
   service basis, and allows bypass tunnel sharing between egress-
   protected tunnels.  The PLR may share an egress-protection bypass
   tunnel for multiple egress-protected tunnels associated with a common
   protected egress {E, P}. During local repair, the PLR reroutes all
   service packets received on the egress-protected tunnels to the
   egress-protection bypass tunnel.  Service labels remain intact in
   MPLS service packets.

   Label operation performed by the PLR 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 an 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 an 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 an egress-
   protected tunnel to a context label, and pushing the stack of SID
   labels of the bypass tunnel.

5.11.  Service label distribution from egress router to protector

   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 the labels of egress-protected
   services 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 service label distribution protocol session
   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 service's ingress router, which includes 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 then installs
   the service label with the forwarding state in the label space of the
   egress router, which is indicated by the context ID (i.e., context
   label).

   Different service protocols may use different mechanisms for such
   kind of label distribution.  Specific extensions may be needed on a
   per-protocol basis or per-service-type basis.  The details of the



Yimin Shen, et al.      Expires February 1, 2020               [Page 16]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   extensions should be specified in separate documents.  As an example,
   [RFC8104] specifies the LDP extensions for pseudowire services.

5.12.  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
   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 equal to 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 assume that a protector and a backup
   egress router are decoupled.





























Yimin Shen, et al.      Expires February 1, 2020               [Page 17]

Internet-Draft      MPLS Egress Protection Framework           July 2019


                  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 another
   transport tunnel to the corresponding backup service instance on a
   backup egress router.  The backup service instance in turn forwards
   the service packets to the service destination.  Specifically, if the
   service is 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 the 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 service label distribution protocol session between the backup
   egress router and the protector.  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



Yimin Shen, et al.      Expires February 1, 2020               [Page 18]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   egress router, and 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 the ingress router(s), if and only if the forwarding
   state of the label does not direct service packets towards the
   protected egress router.  Otherwise, the label MUST NOT be used for
   egress protection, because it would create a loop for the service
   packets.  In this case, the backup egress router MUST advertise a
   unique service label for egress protection, and set up the forwarding
   state of the label to use the backup egress router's own connectivity
   with the service destination.

6.  Egress link protection

   Egress link protection is achievable through procedures similar to
   that of egress node protection.  In normal situations, an egress
   router forwards service packets to a service destination based on a
   service label, whose forwarding state points to an egress link.  In
   egress link protection, the egress router acts as the PLR, and
   performs local failure detection and local repair.  Specifically, the
   egress router pre-establishes an egress-protection bypass tunnel to a
   protector, and sets up the bypass forwarding state for the service
   label to point 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, as shown in Figure 3),
   or forwards the packets to a backup egress router (in the centralized
   protector mode, as shown in Figure 4).





















Yimin Shen, et al.      Expires February 1, 2020               [Page 19]

Internet-Draft      MPLS Egress Protection Framework           July 2019


                        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 February 1, 2020               [Page 20]

Internet-Draft      MPLS Egress Protection Framework           July 2019


                        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 whether the egress router knows the
   service label allocated by the backup egress router.  The difference
   is that one approach requires the protector to perform context label
   switching, and the other one does not.  Both approaches are equally
   supported by this framework.

      (1) The first approach applies when the egress router does not
      know the service label allocated by the backup egress router.  In
      this case, the egress router sets 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, and the bypass tunnel MUST be destined
      for the context ID of the protected egress {E, P} and established
      as described in Section 5.9.  This approach is consistent with
      egress node protection.  Hence, a protector can serve in egress
      node protection and egress link protection in a consistent manner,
      and both the co-located protector mode and the centralized
      protector mode are supported (Figure 3 and Figure 4).




Yimin Shen, et al.      Expires February 1, 2020               [Page 21]

Internet-Draft      MPLS Egress Protection Framework           July 2019


      (2) The second approach applies when the egress router knows the
      service label allocated by the backup egress router, via a label
      distribution protocol session.  In this case, the backup egress
      router serves as the protector for egress link protection,
      regardless of the protector of egress node protection, which will
      be the same router in the co-located protector mode but a
      different router in the centralized protector mode.  The egress
      router sets up the bypass forwarding state as a label swap from
      the incoming service label to the service label of the backup
      egress router (i.e., protector), followed by a push with the
      outgoing label (or label stack) of the egress link protection
      bypass tunnel.  The bypass tunnel is a regular tunnel destined for
      an IP address of the protector, instead of the context ID of the
      protected egress {E, P}. The protector simply forwards rerouted
      service packets based on its own service label, rather than
      performing context label switching.  In this approach, only the
      co-located protector mode is applicable.

   Note that for a bidirectional service, the physical link of an egress
   link may carry service traffic bi-directionally.  Therefore, an
   egress link failure may simultaneously be an ingress link failure for
   the traffic in the opposite direction.  Protection for ingress link
   failure SHOULD be provided by a separate mechanism, and hence is out
   of the scope of this document.

7.  Global repair

   This framework provides a fast but temporary repair for egress node
   and egress link failures.  For permanent repair, the services
   affected by a failure SHOULD be moved to an alternative tunnel, or
   replaced by alternative services, which are fully functional.  This
   is referred to as global repair.  Possible triggers of global repair
   include control plane notifications of tunnel status and service
   status, end-to-end OAM and fault detection at tunnel and service
   level, and others.  The alternative tunnel and services may be pre-
   established in standby state, or dynamically established as a result
   of the triggers or network protocol convergence.

8.  Operational Considerations

   When a PLR performs local repair, the router SHOULD generate an alert
   for the event.  The alert may be logged locally for tracking
   purposes, or it may be sent to the operator at a management station.
   The communication channel and protocol between the PLR and the
   management station may vary depending on networks, and are out of the
   scope of this document.





Yimin Shen, et al.      Expires February 1, 2020               [Page 22]

Internet-Draft      MPLS Egress Protection Framework           July 2019


9.  General context-based forwarding

   So far, this document has been focusing on the cases where service
   packets are MPLS or IP packets and protectors perform context label
   switching or context IP forwarding.  Although this should cover most
   common services, it is worth mentioning that the framework is also
   applicable to services or sub-modes of services where service packets
   are layer-2 packets or encapsulated in non-IP/MPLS formats.  The only
   specific in these cases is that a protector MUST perform context-
   based forwarding based on the layer-2 table or corresponding lookup
   table which is indicated by a context ID (i.e., context label).

10.  Example: Layer-3 VPN egress protection

   This section shows an example of egress protection for layer-3 IPv4
   and IPv6 VPNs.



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


                                 Figure 5

   In this example, the core network is IPv4 and MPLS.  Both of the IPv4
   VPN and the IPv6 VPN consist of site 1 and site 2.  Site 1 is
   connected to PE1, and site 2 is dual-homed to PE2 and PE3.  Site 1
   includes an IPv4 subnet 203.0.113.64/26 and an IPv6 subnet
   2001:db8:1:1::/64.  Site 2 includes an IPv4 subnet 203.0.113.128/26
   and an IPv6 subnet 2001:db8:1:2::/64.  PE2 is the primary PE for site
   2, and PE3 is the backup PE.  Each of PE1, PE2 and PE3 hosts an IPv4
   VPN instance and an IPv6 VPN instance.  The PEs use BGP to exchange
   VPN prefixes and VPN labels between each other.  In the core network,
   R1 and R2 are transit routers, OSPF is used as the routing protocol,
   and RSVP-TE as the tunnel signaling protocol.

   Using the framework in this document, the network assigns PE3 to be
   the protector of PE2 to protect the VPN traffic in the direction from
   site 1 to site 2.  This is the co-located protector mode.  PE2 and



Yimin Shen, et al.      Expires February 1, 2020               [Page 23]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   PE3 form a protected egress {PE2, PE3}. A context ID 198.51.100.1 is
   assigned to the protected egress {PE2, PE3}. (If the core network is
   IPv6, the context ID would be an IPv6 address.)  The IPv4 and IPv6
   VPN instances on PE3 serve as protection instances for the
   corresponding VPN instances 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 label 100 in its 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 the routing domain and the TE domain.

   PE2 uses per-VRF label allocation mode for both of its IPv4 and IPv6
   VPN instances.  It assigns label 9000 to the IPv4 VRF, and label 9001
   to the IPv6 VRF.  For the IPv4 prefix 203.0.113.128/26 in site 2, PE2
   advertises it with label 9000 and NEXT_HOP 198.51.100.1 to PE1 and
   PE3 via BGP.  Likewise, for the IPv6 prefix 2001:db8:1:2::/64 in site
   2, PE2 advertises it with label 9001 and NEXT_HOP 198.51.100.1 to PE1
   and PE3 via BGP.

   PE3 also uses per-VRF VPN label allocation mode for both of its IPv4
   and IPv6 VPN instances.  It assigns label 10000 to the IPv4 VRF, and
   label 10001 to the IPv6 VRF.  For the prefix 203.0.113.128/26 in site
   2, PE3 advertises it with label 10000 and NEXT_HOP as itself to PE1
   and PE2 via BGP.  For the IPv6 prefix 2001:db8:1:2::/64 in site 2,
   PE3 advertises it with label 10001 and NEXT_HOP as itself to PE1 and
   PE2 via BGP.

   Upon receipt of the above BGP advertisements from PE2, PE1 uses the
   context ID 198.51.100.1 as destination to compute a path for an
   egress-protected tunnel.  The resultant path is PE1->R1->PE2.  PE1
   then uses RSVP to signal the tunnel, with the context ID 198.51.100.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 prefixes 203.0.113.128/26 and 2001:db8:1:2::/64
   to the tunnel, and installs a route for each prefix in the
   corresponding IPv4 or IPv6 VRF.  The nexthop of the route
   203.0.113.128/26 is a push of the VPN label 9000, followed by a push
   of the outgoing label of the egress-protected tunnel.  The nexthop of
   the route 2001:db8:1:2::/64 is a push of the VPN label 9001, followed
   by a push of the outgoing label of the egress-protected tunnel.

   Upon receipt of the above BGP advertisements from PE2, PE3 recognizes
   the context ID 198.51.100.1 in the NEXT_HOP attribute, and installs a
   route for label 9000 and a route for label 9001 in the label table
   pe2.mpls.  PE3 sets the nexthop of the route 9000 to the IPv4
   protection VRF, and the nexthop of the route 9001 to the IPv6
   protection VRF.  The IPv4 protection VRF contains the routes to the
   IPv4 prefixes in site 2.  The IPv6 protection VRF contains the routes



Yimin Shen, et al.      Expires February 1, 2020               [Page 24]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   to the IPv6 prefixes in site 2.  The nexthops of these routes must be
   based on PE3's connectivity with site 2, even if the connectivity may
   not have the best metrics (e.g., MED, local preference, etc.) to be
   used in PE3's own VRF.  The nexthops must not use any path traversing
   PE2.  Note that the protection VRFs are a logical concept, and they
   may simply be PE3's own VRFs if they satisfies the requirement.

10.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 198.51.100.1) of the tunnel, R1 computes a bypass path to
   198.51.100.1 while avoiding PE2.  The resultant bypass path is
   R1->R2->PE3.  R1 then signals the path (i.e., egress-protection
   bypass tunnel), with 198.51.100.1 as destination.

   Upon receipt of an RSVP Path message of the egress-protection bypass
   tunnel, PE3 recognizes the context ID 198.51.100.1 as the
   destination, and responds with the context label 100 in an 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 label 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 packets.  Each IPv4 VPN packet will have the
   label of the bypass tunnel as outer label, and the IPv4 VPN label
   9000 as inner label.  Each IPv6 VPN packets will have the label of
   the bypass tunnel as outer label, and the IPv6 VPN label 9001 as
   inner label.  When the packets arrive at PE3, they will have the
   context label 100 as outer label, and the VPN label 9000 or 9001 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 IPv4 and IPv6 packets
   to be forwarded to site 2 based on the IPv4 and IPv6 protection VRFs,
   respectively.

10.2.  Egress link protection

   PE2 serves as the PLR for egress link protection.  It has already
   learned PE3's IPv4 VPN label 10000 and IPv6 VPN label 10001.  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 the path PE2->R3->PE3, and PE3's IP address as
   destination.  After the bypass tunnel comes up, PE2 installs a bypass



Yimin Shen, et al.      Expires February 1, 2020               [Page 25]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   nexthop for the IPv4 VPN label 9000, and a bypass nexthop for the
   IPv6 VPN label 9001.  For label 9000, the bypass nexthop is a label
   swap to label 10000, followed by a label push with the outgoing label
   of the bypass tunnel.  For label 9001, the bypass nexthop is a label
   swap to label 10001, followed by a label push with the outgoing label
   of the bypass tunnel.

   When PE2 detects a failure of the egress link, it will invoke the
   above bypass nexthop to reroute VPN packets.  Each IPv4 VPN packet
   will have the label of the bypass tunnel as outer label, and label
   10000 as inner label.  Each IPv6 VPN packet will have the label of
   the bypass tunnel as outer label, and label 10001 as inner label.
   When the packets arrive at PE3, the VPN label 10000 or 10001 will be
   popped, and the exposed IPv4 and IPv6 packets will be forwarded based
   on PE3's IPv4 and IPv6 VRFs, respectively.

10.3.  Global repair

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

10.4.  Other modes of VPN label allocation

   It is also possible that PE2 may use per-route or per-interface VPN
   label allocation mode.  In either case, PE3 will have multiple VPN
   label routes in the pe2.mpls table, corresponding to the VPN labels
   advertised by PE2.  PE3 forwards rerouted packets by popping a VPN
   label and performing an IP lookup in the corresponding protection
   VRF.  PE3's forwarding behavior is consistent with the above case
   where PE2 uses per-VRF VPN label allocation mode.  PE3 does not need
   to know PE2's VPN label allocation mode, or construct a specific
   nexthop for each VPN label route in the pe2.mpls table.

11.  IANA Considerations

   This document has no request for new IANA allocation.

12.  Security Considerations

   The framework in this document involves rerouting traffic around an
   egress node or link failure, via a bypass path from a PLR to a
   protector, and ultimately to a backup egress router.  The forwarding
   performed by the routers in the data plane is anticipated, as part of
   the planning of egress protection.





Yimin Shen, et al.      Expires February 1, 2020               [Page 26]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   Control plane protocols MAY be used to facilitate the provisioning of
   the egress protection on the routers.  In particular, the framework
   requires a service label distribution protocol between an egress
   router and a protector over a secure session.  The security
   properties of this provisioning and label distribution depend
   entirely on the underlying protocol chosen to implement these
   activities . Their associated security considerations apply.  This
   framework introduces no new security requirements or guarantees
   relative to these activities.

   Also, the PLR, protector, and backup egress router are located close
   to the protected egress router, and normally in the same
   administrative domain.  If they are not in the same administrative
   domain, a certain level of trust MUST be established between them in
   order for the protocols to run securely across the domain boundary.
   The basis of this trust is the security model of the protocols (as
   described above), and further security considerations for inter-
   domain scenarios should be addressed by the protocols as a common
   requirement.

   Security attacks may sometimes come from a customer domain.  Such
   kind of attacks are not introduced by the framework in this document,
   and may occur regardless of the existence of egress protection.  In
   one possible case, the egress link between an egress router and a CE
   could become a point of attack.  An attacker that gains control of
   the CE might use it to simulate link failures and trigger constant
   and cascading activities in the network.  If egress link protection
   is in place, egress link protection activities may also be triggered.
   As a general solution to defeat the attack, a damping mechanism
   SHOULD be used by the egress router to promptly suppress the services
   associated with the link or CE.  The egress router would stop
   advertising the services, essentially detaching them from the network
   and eliminating the effect of the simulated link failures.

   From the above perspectives, this framework does not introduce any
   new security threat to networks.

13.  Acknowledgements

   This document leverages work done by Yakov Rekhter, Kevin Wang and
   Zhaohui Zhang on MPLS egress protection.  Thanks to Alexander
   Vainshtein, Rolf Winter, Lizhong Jin, Krzysztof Szarkowicz, Roman
   Danyliw, and Yuanlong Jiang for their valuable comments that helped
   to shape this document and improve its clarity.







Yimin Shen, et al.      Expires February 1, 2020               [Page 27]

Internet-Draft      MPLS Egress Protection Framework           July 2019


14.  References

14.1.  Normative References

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

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

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [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), 2017.

14.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,
              <https://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,
              <https://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,
              <https://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,
              <https://www.rfc-editor.org/info/rfc7812>.







Yimin Shen, et al.      Expires February 1, 2020               [Page 28]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   [RFC8104]  Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang,
              "Pseudowire (PW) Endpoint Fast Failure Protection",
              RFC 8104, DOI 10.17487/RFC8104, March 2017,
              <https://www.rfc-editor.org/info/rfc8104>.

   [RFC8400]  Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang,
              "Extensions to RSVP-TE for Label Switched Path (LSP)
              Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June
              2018, <https://www.rfc-editor.org/info/rfc8400>.

   [BGP-PIC]  Bashandy, P., Filsfils, C., and P. Mohapatra, "BGP Prefix
              Independent Convergence", draft-ietf-rtgwg-bgp-pic-09.txt
              (work in progress), 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





Yimin Shen, et al.      Expires February 1, 2020               [Page 29]

Internet-Draft      MPLS Egress Protection Framework           July 2019


   Carsten Michel
   Deutsche Telekom

   Email: c.michel@telekom.de


   Huaimo Chen
   Huawei Technologies Co., Ltd.

   Email: huaimo.chen@huawei.com









































Yimin Shen, et al.      Expires February 1, 2020               [Page 30]