doc: Add RFC documents

1 files changed, 1348 insertions, 0 deletions

diff --git a/doc/rfc/rfc8679.txt b/doc/rfc/rfc8679.txt
new file mode 100644
index 0000000..4402bec
--- /dev/null
+++ b/doc/rfc/rfc8679.txt
@@ -0,0 +1,1348 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                           Y. Shen
+Request for Comments: 8679                                  M. Jeyananth
+Category: Standards Track                               Juniper Networks
+ISSN: 2070-1721                                              B. Decraene
+                                                                  Orange
+                                                              H. Gredler
+                                                            RtBrick Inc.
+                                                               C. Michel
+                                                        Deutsche Telekom
+                                                                 H. Chen
+                                                               Futurewei
+                                                           December 2019
+
+
+                    MPLS Egress Protection Framework
+
+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 is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8679.
+
+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
+   2.  Specification of Requirements
+   3.  Terminology
+   4.  Requirements
+   5.  Egress Node Protection
+     5.1.  Reference Topology
+     5.2.  Egress Node Failure and Detection
+     5.3.  Protector and PLR
+     5.4.  Protected Egress
+     5.5.  Egress-Protected Tunnel and Service
+     5.6.  Egress-Protection Bypass Tunnel
+     5.7.  Context ID, Context Label, and Context-Based Forwarding
+     5.8.  Advertisement and Path Resolution for Context ID
+     5.9.  Egress-Protection Bypass Tunnel Establishment
+     5.10. Local Repair on PLR
+     5.11. Service Label Distribution from Egress Router to Protector
+     5.12. Centralized Protector Mode
+   6.  Egress Link Protection
+   7.  Global Repair
+   8.  Operational Considerations
+   9.  General Context-Based Forwarding
+   10. Example: Layer 3 VPN Egress Protection
+     10.1.  Egress Node Protection
+     10.2.  Egress Link Protection
+     10.3.  Global Repair
+     10.4.  Other Modes of VPN Label Allocation
+   11. IANA Considerations
+   12. Security Considerations
+   13. References
+     13.1.  Normative References
+     13.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+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., Class of Service
+   (CoS) and 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 an IP service address.  The egress link is often
+   called a Provider Edge - Customer Edge (PE-CE) link or Attachment
+   Circuit (AC).
+
+   Today, local-repair-based fast reroute mechanisms (see [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, pre-establishes a bypass tunnel to the router
+   downstream of the failure, a.k.a., Merge Point (MP), pre-installs the
+   forwarding state of the bypass tunnel in the data plane, and uses a
+   rapid mechanism (e.g., link-layer Operations, Administration, and
+   Maintenance (OAM), Bidirectional Forwarding Detection (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 tail end 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.
+
+   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 that can no longer reach the service instances on the
+   egress router.  Therefore, the framework addresses egress node
+   protection at both the 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 that hosts a "backup service instance".  In the "co-located"
+   protector mode in this document, the backup egress router serves as
+   the protector; 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 point-to-point
+   (P2P) tunnels.  However, it is equally applicable to point-to-
+   multipoint (P2MP), multipoint-to-point (MP2P), and multipoint-to-
+   multipoint (MP2MP) 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 that the service label is 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 the 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 Virtual Private LAN Service
+   (VPLS) and Ethernet VPN (EVPN).  These cases are left for future
+   study.  Services that 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 that transport tunnels and bypass tunnels are to
+   be established by using the generic procedures provided by the
+   protocols.  On the other hand, it does not preclude extensions to the
+   protocols that 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 it 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 on 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 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", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+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.
+
+   Egress-protected service:
+      An IP or MPLS service that 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 that 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 that is hosted by a backup egress router and
+      corresponds 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 that corresponds 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; hence, each backup service instance serves
+      as a protection service instance.
+
+   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.
+
+   *  The framework must support P2P tunnels.  It should equally support
+      P2MP, MP2P, and MP2MP tunnels, by treating each sub-LSP as a P2P
+      tunnel.
+
+   *  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.
+
+   *  The framework must consider minimizing disruption during
+      deployment.  It should only involve routers close to the egress
+      and be transparent to ingress routers and other transit routers.
+
+   *  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.
+
+   *  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.
+
+   *  A protector must be able to perform context label switching for
+      rerouted MPLS service packets, based on a 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.
+
+   *  The framework must be able to work seamlessly with transit link/
+      node protection mechanisms to achieve end-to-end coverage.
+
+   *  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 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.
+
+   *  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.
+
+   *  If the PLR has a fast mechanism to detect a link failure and an
+      egress node failure, but it 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 tail end 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
+   egress node failure, the PLR reroutes all the service packets
+   received on the tunnel through the bypass tunnel to the protector.
+   For MPLS service packets, the PLR keeps service labels intact in the
+   packets.  In turn, the protector 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 that 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 tail end 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).
+
+   The 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}.
+
+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 they 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 tail end.
+
+   A service, which is associated with a protected egress {E, P}, is
+   called an egress-protected service.  Egress router E hosts the
+   primary instance of the service, and 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 they 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 a "context ID" for a 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 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 tail end and E as the node to avoid.  The bypass tunnel
+   MUST NOT be affected by the topology change caused by an egress node
+   failure; thus, it MUST contain a property that protects it from this
+   scenario.
+
+   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}.
+
+5.7.  Context ID, Context Label, and Context-Based Forwarding
+
+   In this framework, a globally unique IPv4 or IPv6 address is assigned
+   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 the 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 a context ID.
+
+   *  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.
+      The service protocol chooses how the context ID is encoded in the
+      messages.  A protocol extension of a "context ID" object may be
+      needed, if there is no existing mechanism for this purpose.
+
+   *  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.
+
+   *  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 IS-IS) or a topology-driven label distribution
+      protocol (e.g., LDP).  The PLR uses the context ID as the
+      destination to establish or resolve an egress-protection bypass
+      tunnel to P while avoiding E.
+
+   *  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.
+
+   *  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 the
+      forwarding state for the label route or IP route based on P's own
+      connectivity with the service's destination.
+
+   *  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".
+
+   *  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 the
+      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 Forwarding
+      Equivalence Class (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 Segment Identifier (SID) labels with the
+      context label as the inner-most SID label (Section 5.9).  In any
+      case, the bypass tunnel is an ultimate hop-popping (UHP) tunnel
+      whose incoming label on P is the context label.
+
+   *  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 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
+   MUST be advertised in such a manner that all egress-protected tunnels
+   MUST have E as the tail end, and all egress-protection bypass tunnels
+   MUST have P as the tail end 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 as 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
+          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
+          the 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 the tail end.
+          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 the IGP Mirroring Context segment
+          in [RFC8402] and [RFC8667].  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 modeling 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
+   on the topology, manageability, and available protocols of the
+   network.  For a given context ID, all relevant routers, including the
+   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-Autonomous-System (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 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 in 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 the tail end.  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 the 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.
+
+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 or per-service-type basis.  The details of the
+   extensions should be specified in separate documents.  As an example,
+   the LDP extensions for pseudowire services are specified in
+   [RFC8104].
+
+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 focus
+   of discussion has been 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.
+
+                  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
+   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 that the backup egress router advertises to the
+   protector can be the same as the label that 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).
+
+                        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
+
+                        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 for setting 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 (see Figures 3 and 4).
+
+      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 bidirectionally.  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 the 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.
+
+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 and non-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
+   and IPv6 VPNs consist of sites 1 and 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 is
+   used 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
+   PE3 form a protected egress {PE2, PE3}. 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, 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 the next hop 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 the label allocation mode per Virtual Routing and Forwarding
+   (VRF) 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 the 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 the destination, with the "node protection desired" flag set in
+   the SESSION_ATTRIBUTE of the 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 next hop of 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 next hop
+   of 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 next hop of route 9000 to the IPv4 protection
+   VRF and the next hop of 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 to the IPv6 prefixes
+   in site 2.  The next hops 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., Multi-Exit Discriminator (MED), local preference,
+   etc.) to be used in PE3's own VRF.  The next hops 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 satisfy 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 the 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 context label 100 in an RSVP Resv message.
+
+   After the egress-protection bypass tunnel comes up, R1 installs a
+   bypass next hop for the egress-protected tunnel.  The bypass next hop
+   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
+   next hop 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 packet will have the label of the
+   bypass tunnel as the outer label and the IPv6 VPN label 9001 as the
+   inner label.  When the packets arrive at PE3, they will have the
+   context label 100 as the outer label and the VPN label 9000 or 9001
+   as the 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 approach (2) as described in Section 6 to set up the 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 the
+   destination.  After the bypass tunnel comes up, PE2 installs a bypass
+   next hop for the IPv4 VPN label 9000 and a bypass next hop for the
+   IPv6 VPN label 9001.  For label 9000, the bypass next hop 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 next hop 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 next hop to reroute VPN packets.  Each IPv4 VPN packet
+   will have the label of the bypass tunnel as the outer label and label
+   10000 as the inner label.  Each IPv6 VPN packet will have the label
+   of the bypass tunnel as the outer label and label 10001 as the 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 next
+   hop for each VPN label route in the pe2.mpls table.
+
+11.  IANA Considerations
+
+   This document has no IANA actions.
+
+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.
+
+   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, which is 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
+   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.  References
+
+13.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>.
+
+   [RFC8667]  Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
+              Gredler, H., and B. Decraene, "IS-IS Extensions for
+              Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December
+              2019, <https://www.rfc-editor.org/info/rfc8667>.
+
+13.2.  Informative References
+
+   [BGP-PIC]  Bashandy, A., Filsfils, C., and P. Mohapatra, "BGP Prefix
+              Independent Convergence", Work in Progress, Internet-
+              Draft, draft-ietf-rtgwg-bgp-pic-10, 2 October 2019,
+              <https://tools.ietf.org/html/draft-ietf-rtgwg-bgp-pic-10>.
+
+   [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>.
+
+   [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>.
+
+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.
+
+Authors' Addresses
+
+   Yimin Shen
+   Juniper Networks
+   10 Technology Park Drive
+   Westford, MA 01886
+   United States of America
+
+   Phone: +1 978 589 0722
+   Email: yshen@juniper.net
+
+
+   Minto Jeyananth
+   Juniper Networks
+   1133 Innovation Way
+   Sunnyvale, CA 94089
+   United States of America
+
+   Phone: +1 408 936 7563
+   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
+
+
+   Huaimo Chen
+   Futurewei
+   Boston, MA
+   United States of America
+
+   Email: Huaimo.chen@futurewei.com