Internet Engineering Task Force Yimin Shen Internet-Draft Minto Jeyananth Intended status: Informational Juniper Networks Expires: August 20, 2016 February 17, 2016 MPLS Egress Protection Framework draft-shen-mpls-egress-protection-framework-00 Abstract This document specifies a fast reroute framework for protecting MPLS tunnels and the IP/MPLS services carried by them against egress router failures. The framework relies on local detection and local repair to be performed by the router upstream adjacent to a failure. The router can restore traffic in the order of tens of milliseconds, by rerouting it to a protector through a pre-established bypass tunnel. Therefore, the mechanism can be used to reduce traffic loss before global repair reacts to the failure and control plane protocols converge on the topology changes due to the failure. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 20, 2016. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 1] Internet-Draft MPLS Egress Protection Framework February 2016 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 2. Specification of Requirements . . . . . . . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 5 5.1. Egress failure . . . . . . . . . . . . . . . . . . . . . 5 5.2. Protector and PLR . . . . . . . . . . . . . . . . . . . . 6 5.3. Protected egress . . . . . . . . . . . . . . . . . . . . 6 5.4. Egress-protected tunnel . . . . . . . . . . . . . . . . . 7 5.5. Egress-protected service . . . . . . . . . . . . . . . . 7 5.6. Egress-protected service to egress-protected tunnel mapping . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.7. Egress-protection bypass tunnel . . . . . . . . . . . . . 7 5.8. Context ID, context label, and context based forwarding . 8 5.9. IGP advertisement and path computation for context ID . . 9 5.10. Egress-protection bypass tunnel establishment . . . . . . 10 5.11. Local Repair on PLR . . . . . . . . . . . . . . . . . . . 11 5.12. Label distribution from egress router to protector . . . 11 6. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Example: Layer-3 VPN egress protection . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction In MPLS networks, LSPs (label switched paths) are widely use as transport tunnels to carry IP and MPLS services across MPLS domains. Examples of MPLS services are layer-2 VPNs, layer-3 VPNs, etc. Particularly, at the egress router of a tunnel, packets of an IP service are forwarded to service destination based on IP header, and packets of an MPLS service are forwarded to service destination based on a service label. Today, local repair based fast reroute mechanisms have been widely deployed to protect MPLS tunnels against transit link and node failures. They can achieve fast restoration in the order of tens of Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 2] Internet-Draft MPLS Egress Protection Framework February 2016 milliseconds. Local repair refers to the scenario where the router (aka. PLR, i.e. point of local repair) upstream adjacent to an anticipated failure pre-establishes a bypass tunnel around the failure to another router (aka. MP, i.e. merge point) on the tunnel and downstream of the failure, and pre-installs the forwarding state of the bypass tunnel in the data plane. The PLR also has a rapid mechanism to locally detect the failure in the data plane. When the failure occurs, the PLR reroutes traffic through the bypass tunnel to the MP. Thus, the traffic will continue to flow via the MP to the tunnel's egress router. This document describes a fast reroute framework for egress router protection. Similar to the transit link/node protection, this framework relies on local failure detection and local repair to be performed by a PLR, which is the penultimate hop router of a tunnel. However, there is no MP in this case, because the tunnel does not have other router downstream of the egress router. Instead, this framework relies on a so-called "protector" to serve as the tailend of a bypass tunnel. The protector is simply a backup router that has its own connectivity to service destinations. It performs context label switching for rerouted MPLS service packets based on service labels assigned by the protected egress router, and performs context IP forwarding for rerouted IP service packets. This framework considers an egress router failure as a failure of a tunnel and a failure of the service(s) carried by the tunnel. Hence, it addresses protection at both tunnel level and service level. This framework requires that the destination (a CE or site) of a protected service must be dual-homed or have dual paths to the MPLS network, normally via two PEs. 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, where each sub-LSP can be viewed as a P2P tunnel from traffic flow's perspective. The framework does not require extensions for signaling or label distribution protocols of MPLS tunnels. It may require extensions for IGPs and service label distribution protocols, to facilitate protection establishment and context label switching. This document provides guidelines for these extensions, but the details should be addressed in separate documents. Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 3] Internet-Draft MPLS Egress Protection Framework February 2016 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119. 3. Terminology EP - Egress protection. Egress-protected tunnel - A tunnel that desires egress protection. Protector - A router that acts as a backup for the egress router of an egress-protected tunnel. PLR - A router at point of local repair, which is the penultimate hop router on an egress-protected tunnel. Protected egress - A virtual node consisting of an ordered pair of {egress router, protector}. It serves as the virtual destination of an egress-protected tunnel. Context identifier (ID) - A globally unique IP address assigned to a protected egress {egress router, protector}, and owned by both routers. Context label - A non-reserved label assigned to a context ID by a protector. Egress-protection bypass tunnel - An tunnel established from a PLR to a protector, bypassing the egress router of an egress-protected tunnel. Context label switching - Label switching performed by a protector, in the label space (or label table) indicated by a context, i.e. a context label in this document. Context IP forwarding - IP forwarding performed by a protector, in the IP forwarding table indicated by a context, i.e. a context label in this document. 4. Requirements This document considers the followings as requirements of the egress protection framework. o The framework must be based on local failure detection and local repair, in a similar fashion to transit link and node protection. Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 4] Internet-Draft MPLS Egress Protection Framework February 2016 It must be able to achieve fast restoration in the order of tens of milliseconds. o The framework must support P2P tunnels. It should equally apply to P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P tunnel. o The framework must be independent of signaling and label- distribution protocols of tunnels and bypass tunnels, including RSPV, LDP, BGP, IGP, segment routing, etc. o The framework must be generic to support existing and future MPLS services, including layer-2 VPNs, layer-3 VPNs, etc. o A PLR must be agnostic on services and service labels. It must maintain bypass tunnels and bypass forwarding state on a per- transport-tunnel basis, rather than per-service or per-service- label basis. It must support bypass tunnel sharing between transport tunnels. o A PLR must be able to use its local routing and TE information database to compute or resolve path for a bypass tunnel. o A protector must be able to perform context label switching for rerouted MPLS service packets, based on a service label assigned by a protected egress router. o A protector must be able to perform context IP forwarding for rerouted IP service packets. o The framework must be able to work seamlessly with transit node protection mechanisms to achieve end-to-end node protection for MPLS tunnels. o The framework must be able to work in conjunction with global repair (aka. end-to-end repair) and control plane convergence. 5. Theory of Operation 5.1. Egress failure An egress failure refers to the node failure of a tunnel's egress router. As each MPLS service carried by the tunnel can be viewed as a one-hop LSP from the ingress router to the egress router, the failure is considered as an egress node failure of the service as well. Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 5] Internet-Draft MPLS Egress Protection Framework February 2016 Failure detection mechanisms that are used by PLRs in transit link and node protection are applicable to egress failure detection. In the case where a PLR does not have a fast and reliable mechanism to detect a node failure, it may treat a link failure as a node failure and trigger node protection. 5.2. Protector and PLR A router is assigned to protect a tunnel against egress failure. The router is called a protector. It protects the tunnel, as well as the services carried by the tunnel. A tunnel can be protected by only one protector, while a protector may protect multiple tunnels to one or multiple egress routers. Tunnels to a given egress router may be protected by different protectors. Hence, egress routers and protectors have a many-to-many relationship. The penultimate hop router of a tunnel acts as a PLR. It pre- establishes a bypass tunnel to the protector, and pre-installs bypass forwarding state in the data plane. Upon detection of an egress failure, the PLR reroutes all the packets received on the tunnel though the bypass tunnel to the protector, with service label intact for MPLS service packets. The protector in turn forwards the service packets towards the ultimate service destination(s). Specifically, for MPLS service packets, the protector performs context label switching based on service labels assigned by the egress router of the protected tunnel. For IP service packets, the protector performs context IP forwarding based on destination addresses. The protector has its own connectivity with the service destinations, which means that the destinations must be dual-homed or have dual paths to the egress router and the protector. 5.3. Protected egress This document introduces the notion of "protected egress" as a virtual node consisting of the egress router of a tunnel and a protector. It is denoted by an ordered pair of {egress router, protector}. It represents the relationship between the two routers in the egress protection schema. A given egress router E may be the tailend of multiple tunnels. At the same time, it may be protected by multiple protectors, i.e. P1, P2, etc, with each Pi protecting a subset of the tunnels. Hence, these routers will form multiple protected egress', i.e. {E, P1} , {E, P2}, etc. Each tunnel is associated with one and only one protected egress {E, Pi}. Every service carried by the tunnel is also automatically associated with the protected egress {E, Pi}. Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 6] Internet-Draft MPLS Egress Protection Framework February 2016 Two node X and Y may be protectors for each other's tunnels. In this case, they form two distinct protected egress', i.e. {X, Y} and {Y, X}. From another perspective, a service associated with a protected egress {E, Pi} must be carried by a tunnel associated with the same protected egress {E, Pi}. This is ensured by the ingress router (Section 5.6). 5.4. Egress-protected tunnel A tunnel, which is associated with a protected egress {E, P}, is called an egress-protected tunnel. The tunnel is viewed as logically "destined" for the protected egress, although it is physically destined for E. Each egress-protected tunnel is associated with one and only one protected egress {E, P}. Multiple of egress-protected tunnels may be associated with a given protected egress {E, P}. These tunnels share the common egress router and protector, but may not share a common ingress router. 5.5. Egress-protected service A service, which is associated with a protected egress {E, P}, is called an egress-protected service. Each 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}. These services share the common egress router and protector, but may not necessarily be transported by the same tunnel or share a common ingress router. 5.6. Egress-protected service to egress-protected tunnel mapping An ingress router must map an egress-protected service to an egress- protected tunnel based on common protected egress {E, P}. This is achieved by introducing the notion of "context ID" for protected egress, as described in (Section 5.8). 5.7. Egress-protection bypass tunnel An egress-protected tunnel destined for a protected egress {E, P} should have a bypass tunnel from its PLR to the protector P. This bypass tunnel is called an egress-protection bypass tunnel. An Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 7] Internet-Draft MPLS Egress Protection Framework February 2016 egress-protection bypass tunnel is associated with one and only one protected egress {E, P}. The bypass tunnel is viewed as logically "destined" for the protected egress {E, P}, although it is physically destined for P and bypassing E. A PLR may share an egress-protection bypass tunnel between multiple egress-protected tunnels, if they are destined for a common protected egress {E, P}. For a given protected egress {E, P}, there may exist one or multiple egress-protection bypass tunnel from multiple PLRs to the protector P. The PLRs belong to different egress-protected tunnels destined for the protected egress {E, P}. Establishments of egress-protected tunnel and egress-protection bypass tunnel are generally independent. In some cases, the former may trigger the latter, if a PLR cannot find an existing egress- protection bypass tunnel to use. An egress-protection bypass tunnel has the property that it is not affected by any topology change caused by an egress failure. 5.8. Context ID, context label, and context based forwarding A context ID is a globally unique IPv4/v6 address assigned to a protected egress {egress router, protector}. It is called context ID due to its usage in context label switching and context IP forwarding on the protector. It is an IP address owned by both the egress router and the protector. For the egress node, it indicates the protector. For the protector, it indicates the egress router. For other routers in the network, it is an address reachable via both the egress router and the protector in routing domain and TE domain (Section 5.9). Given an egress-protected service associated with a protected egress {E, P} which is assigned a context ID, the context ID is used as below: o If the service is an MPLS service, when the egress router distributes the label binding message of the service to the ingress router, the egress router attaches the context ID to the message. If the service is an IP service, when the egress router advertises the service destination address to the ingress router, the egress router attaches the context ID as a virtual next-hop to the advertisement. How the context ID is encoded in the messages is a choice of the related protocols, and may need protocol extensions. Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 8] Internet-Draft MPLS Egress Protection Framework February 2016 o The ingress router then uses the context ID as destination to establish or resolve an egress-protected tunnel. The ingress router maps the service to the tunnel for transportation. o The context ID is conveyed to the PLR by the signaling protocol of the egress-protected tunnel or by the IGP or topology-driven label distribution protocol of the network. The PLR uses the context ID as destination to establish or resolve an egress-protection bypass tunnel to the protector. Due to the context ID's reachability via the protector, the PLR can achieve this without the knowledge of egress protection schema. o On the protector, the context ID is used to indicate the egress router's label space and IP address space. The latter is the IP address space of the destinations of egress-protected IP services. o If the service is an MPLS service, the egress router uses a label distribution protocol to advertise the label binding of the service to the protector. The protector installs the label in a dedicated label space, identified by the context ID. o The protector assigns a non-reserved label to the context ID. In the data plane, this label serves as a context to indicate the egress router's label space and IP address space. Therefore, it is called a "context label". o The protector binds the context label to the egress-protection bypass tunnel, based on the destination. During local repair, all the service packets received on the bypass tunnel will have the context label as top label. The protector will first pop the context label. For MPLS service packets, the protector will further look up the service label in the label space indicated by the context label. This is called context label switching. For IP service packets, the protector will look up the IP destination address in the IP forwarding table indicated by the context label. This is called context IP forwarding. 5.9. IGP advertisement and path computation for context ID Given a protected egress {egress router, protector} and its context ID, coordination must be done between the two routers for IGP advertisement of the context ID in routing domain and TE domain. The context ID must be advertised in such a way that all the egress- protected tunnels destined for the context ID MUST be established with the egress router as tailend, and all the egress-protection bypass tunnels destined for the context ID MUST be established with the protector as tailend, while avoiding the egress router. Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 9] Internet-Draft MPLS Egress Protection Framework February 2016 This document suggests two approaches: 1. The first approach is called "proxy mode". It does not require an ingress router or a PLR to have knowledge of the egress protection schema. The egress router and the protector advertise the context ID as a virtual proxy node connected to the two routers, with the link between the proxy node and the egress router having more preferable IGP and TE metrics than the link between the proxy node and the protector. Therefore, all egress- protected tunnels destined for the context ID should automatically follow shortest IGP paths or TE paths to the egress router. Each PLR will no longer view itself as a penultimate hop, but rather two hops away from the proxy node, via the egress router. The PLR will be able to find a bypass path via the protector to the proxy node, while the bypass tunnel should actually be terminated by the protector. 2. The second approach is called "alias mode". It requires a PLR to have knowledge of the egress protection schema. The egress router advertises the context ID as a regular IP address. The protector advertises the context ID and the context label by using a special "context ID label binding" object. The object must be understood by the PLR. In both routing domain and TE domain, the context ID is only reachable via the egress router. This ensures that all egress-protected tunnel destined for the context ID are terminated by the egress router. Based on the "context ID label binding" advertisement, the PLR can establish an egress-protection bypass tunnel in a hierarchical fashion, i.e. with a the context label as a one-hop LSP over a regular bypass tunnel to the protector. The "context ID label binding" object may require IGP extensions, or in a network with segment routing, it may be an SID/Label Binding sub-TLV, treating a context ID as a type of segment. 5.10. Egress-protection bypass tunnel establishment In the control plane, an egress-protection bypass tunnel from a PLR to a protector and destined for a context ID may be established via several methods: [1] It may be established by a signaling protocol (e.g. RSVP), with the context ID as destination. The protector binds the context label to the tunnel. [2] It may be formed by a topology driven protocol (e.g. LDP). The protector binds the context label to the context ID as an IP prefix FEC. Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 10] Internet-Draft MPLS Egress Protection Framework February 2016 [3] It may be constructed by segment routing. In this case, the protector must use the alias mode (Section 5.9) to advertise the context ID and context label binding via IGP. The PLR can then construct the bypass tunnel as a label stack to the protector, with the context label as the inner-most label. [4] It may be constructed as a hierarchical tunnel. When the protector uses the alias mode (Section 5.9), 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 fashion, with the context label as a one-hop LSP over a regular bypass tunnel (signaled or topology-driven) to the protector. 5.11. Local Repair on PLR A PLR is agnostic on services and services labels carried by its egress-protected tunnel. During local repair, it simply reroutes all service packets received on the tunnel to an egress-protection bypass tunnel, and keeps service labels intact in the packets. In the simplest case, the rerouting involves swapping the in-label of the egress-protected tunnel to the out-label of the egress-protection bypass tunnel. In the case where the bypass tunnel is a hierarchical tunnel, the rerouting involves swapping the in-label of the egress- protected tunnel to a context label, and pushing the out-label of a regular bypass tunnel. In the case where the bypass tunnel is constructed by segment routing, the rerouting involves swapping the in-label of the egress-protected tunnel to a context label, and pushing the label stack of a regular bypass tunnel. Keeping service labels intact in the packets obviates the need for the PLR to maintain bypass tunnels and bypass forwarding state on per-service basis, and allows bypass sharing between egress-protected tunnels. 5.12. Label distribution from egress router to protector For rerouted MPLS service packets, a protector performs context label switching for service labels assigned by egress routers. From the protector's perspective, these service labels are "upstream assigned" labels. The protector maintains the labels in dedicated label spaces on a per protected egress basis, i.e. one label space for each egress router that it protects. There must be a label distribution protocol running between each egress router and the protector. Through this protocol, the protector learns the label bindings of egress-protected MPLS services. It recognizes each service FEC, and resolves forwarding Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 11] Internet-Draft MPLS Egress Protection Framework February 2016 state based on its own connectivity to the service destination. It installs the service label with the forwarding state in the label space of the egress router. Protocol extensions may be needed for the upstream label distribution between egress router and protector. 6. Global repair The framework in this document provides a fast but temporary reroute for traffic upon an egress failure. As a permanent solution, it is RECOMMENDED that the ingress router SHOULD move the traffic to another fully functional tunnel or other fully functional services. This is referred to as global repair. Possible triggers of global repair include service and tunnel status notifications, end-to-end OAM at service and tunnel levels, traffic marking in the reverse direction, etc. These replacement tunnel and services may be pre- established backups, or newly established as a result of the ingress router's retry mechanism or network protocol convergence. 7. Example: Layer-3 VPN egress protection This section shows an example of egress protection for a layer-3 VPN. ---------- R1 -------------- PE2 - / (PLR) \ ( site 1 ) / | ( site 2 ) ( ) / | ( ) ( subnet )-- PE1 < | ( subnet ) ( 8.0.0.0/8 ) \ | ( 9.0.0.0/8 ) ( ) \ | ( ) \ | / ---------- R2 -------------- PE3 - (protector) Figure 1 In this example, the site 1 of a given VPN is attached to PE1, and site 2 is dual-homed to PE2 and PE3. PE2 is the primary PE for site 2, and PE3 is the backup PE. R1 and R2 are core routers of the MPLS network. The network uses OSPF as routing protocol, and RSVP-TE as tunnel signaling protocol. The PEs use BGP to exchange VPN prefixes and VPN labels between each other. Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 12] Internet-Draft MPLS Egress Protection Framework February 2016 Using the framework in this document, the network assigns PE3 to be a protector for PE2 to protect the VPN traffic in the direction from site 1 to site 2. Hence, PE2 and PE3 form a protected egress {PE2, PE3}. A context ID 1.1.1.1 is assigned to the protected egress. On PE3, a context label 100 is assigned to the context ID, and a label table pe2.mpls is created to represent PE2's label space. PE3 installs the label 100 in its default MPLS forwarding table, with nexthop pointing to the label table pe2.mpls. PE2 and PE3 are coordinated to use the proxy mode to advertise the context ID in routing domain and TE domain. PE2 uses per-VRF VPN label allocation mode. In particular, it assigns a single label 9000 for the VRF of the VPN. For a given VPN prefix 9.0.0.0/8 in site 2, PE2 advertises it along with the label 9000 and other attributes (including route targets and route distinguisher) to PE1 and PE3 via BGP. In particular, PE2 sets the NEXT_HOP attribute to the context ID 1.1.1.1. Upon receipt of the BGP advertisement, PE1 uses the context ID 1.1.1.1 as destination to compute a TE path for an egress-protected tunnel. The resulted path is PE1->R1->PE2. PE1 then uses RSVP to signal the tunnel, with the context ID 1.1.1.1 as destination, and with the "node protection desired" flag set in the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes up, PE1 maps the VPN prefix 9.0.0.0/8 to the tunnel and installs a route for the prefix in the corresponding VRF. The route's nexthop is a push of the VPN label 9000, followed by a push of the out-label of the egress- protected tunnel. Upon receipt of the above BGP advertisement from PE2, PE3 (i.e. the protector) installs a route for label 9000 in the label table pe2.mpls, based on the context ID 1.1.1.1 in the NEXT_HOP attribute. The route's nexthop points to PE3's VRF of the VPN. R1, i.e. the penultimate hop router of the egress-protected tunnel, acts as PLR. Based on the "node protection desired" flag and the destination address (i.e. context ID 1.1.1.1) of the tunnel, R1 computes a bypass path to 1.1.1.1 while avoiding PE2. The resulted bypass path is R1->R2->PE3. R1 then signals the path as an egress- protection bypass tunnel, with 1.1.1.1 as destination. Upon receipt of RSVP Path message of the egress-protection bypass tunnel, PE3 recognizes the context ID 1.1.1.1 as the destination, and hence responds with the context label 100 in RSVP Resv message. Once the egress-protection bypass tunnel comes up, R1 installs a bypass nexthop for the egress-protected tunnel. The bypass nexthop Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 13] Internet-Draft MPLS Egress Protection Framework February 2016 is a swap from the in-label of the egress-protected tunnel to the out-label of the egress-protection bypass tunnel. When R1 detects a failure of PE2, it will invoke the above bypass nexthop to reroute VPN service packets. The packets will have the label of the bypass tunnel as outer label, and the VPN label 9000 as inner label. When the packets arrive at PE3, they will have the context label 100 as outer label, and the VPN label 9000 as inner label. The context label will first be popped, and then the VPN label will be looked up in the label table pe2.mpls. The lookup will cause the VPN label to be popped, and the IP packets will finally be forwarded to site 2 based on PE3's VRF of the VPN. Eventually, global repair will kick in, as control plane protocols converge on the new topology. PE1 will choose PE3 as new entrance to site 2. Before that happens, the VPN traffic has been protected by the above local repair. 8. IANA Considerations This document does not require any new IANA allocation. 9. Security Considerations This document does not introduce any security issues. Note that the framework requires a label distribution protocol to run between an egress router and a protector, which is achievable in a secured fashion. 10. Acknowledgements This document leverages work done by Hannes Gredler, Yakov Rekhter, Kevin Wang and several on MPLS egress protection. 11. References 11.1. Normative References [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, . [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, DOI 10.17487/RFC2205, September 1997, . Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 14] Internet-Draft MPLS Egress Protection Framework February 2016 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, . [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, . [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, . [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC 5714, DOI 10.17487/RFC5714, January 2010, . [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream Label Assignment and Context-Specific Label Space", RFC 5331, DOI 10.17487/RFC5331, August 2008, . [RFC6389] Aggarwal, R. and JL. Le Roux, "MPLS Upstream Label Assignment for LDP", RFC 6389, DOI 10.17487/RFC6389, November 2011, . [SEGMENT-ROUTING-MPLS] Filsfils, C., Previdi, S., and S. Previdi, "Segment routing with MPLS data plane", draft-ietf-spring-segment- routing-mpls (work in progress), 2016. [IP-LDP-FRR-MRT] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant Trees", draft-ietf-rtgwg-mrt-frr-architecture (work in progress), 2016. 11.2. Informative References [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 15] Internet-Draft MPLS Egress Protection Framework February 2016 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010, . 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 Yimin Shen & Minto JeyanaExpires August 20, 2016 [Page 16]