draft-ietf-mpls-egress-protection-framework-07.txt   rfc8679.txt 
Internet Engineering Task Force Yimin Shen Internet Engineering Task Force (IETF) Y. Shen
Internet-Draft Minto Jeyananth Request for Comments: 8679 M. Jeyananth
Intended status: Standards Track Juniper Networks Category: Standards Track Juniper Networks
Expires: February 1, 2020 Bruno Decraene ISSN: 2070-1721 B. Decraene
Orange Orange
Hannes Gredler H. Gredler
RtBrick Inc RtBrick Inc.
Carsten Michel C. Michel
Deutsche Telekom Deutsche Telekom
Huaimo Chen H. Chen
Huawei Technologies Co., Ltd. Futurewei
July 31, 2019 December 2019
MPLS Egress Protection Framework MPLS Egress Protection Framework
draft-ietf-mpls-egress-protection-framework-07
Abstract Abstract
This document specifies a fast reroute framework for protecting IP/ This document specifies a fast reroute framework for protecting IP/
MPLS services and MPLS transport tunnels against egress node and MPLS services and MPLS transport tunnels against egress node and
egress link failures. For each type of egress failure, it defines egress link failures. For each type of egress failure, it defines
the roles of point of local repair (PLR), protector, and backup the roles of Point of Local Repair (PLR), protector, and backup
egress router, and the procedures of establishing a bypass tunnel egress router and the procedures of establishing a bypass tunnel from
from a PLR to a protector. It describes the behaviors of these a PLR to a protector. It describes the behaviors of these routers in
routers in handling an egress failure, including local repair on the handling an egress failure, including local repair on the PLR and
PLR, and context-based forwarding on the protector. The framework context-based forwarding on the protector. The framework can be used
can be used to develop egress protection mechanisms to reduce traffic to develop egress protection mechanisms to reduce traffic loss before
loss before global repair reacts to an egress failure and control global repair reacts to an egress failure and control-plane protocols
plane protocols converge on the topology changes due to the egress converge on the topology changes due to the egress failure.
failure.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on February 1, 2020. 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
2. Specification of Requirements . . . . . . . . . . . . . . . . 5 2. Specification of Requirements
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements
5. Egress node protection . . . . . . . . . . . . . . . . . . . 8 5. Egress Node Protection
5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8 5.1. Reference Topology
5.2. Egress node failure and detection . . . . . . . . . . . . 8 5.2. Egress Node Failure and Detection
5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9 5.3. Protector and PLR
5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 10 5.4. Protected Egress
5.5. Egress-protected tunnel and service . . . . . . . . . . . 11 5.5. Egress-Protected Tunnel and Service
5.6. Egress-protection bypass tunnel . . . . . . . . . . . . . 11 5.6. Egress-Protection Bypass Tunnel
5.7. Context ID, context label, and context-based forwarding . 12 5.7. Context ID, Context Label, and Context-Based Forwarding
5.8. Advertisement and path resolution for context ID . . . . 13 5.8. Advertisement and Path Resolution for Context ID
5.9. Egress-protection bypass tunnel establishment . . . . . . 15 5.9. Egress-Protection Bypass Tunnel Establishment
5.10. Local repair on PLR . . . . . . . . . . . . . . . . . . . 16 5.10. Local Repair on PLR
5.11. Service label distribution from egress router to 5.11. Service Label Distribution from Egress Router to Protector
protector . . . . . . . . . . . . . . . . . . . . . . . . 16 5.12. Centralized Protector Mode
5.12. Centralized protector mode . . . . . . . . . . . . . . . 17 6. Egress Link Protection
6. Egress link protection . . . . . . . . . . . . . . . . . . . 19 7. Global Repair
7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 22 8. Operational Considerations
8. Operational Considerations . . . . . . . . . . . . . . . . . 22 9. General Context-Based Forwarding
9. General context-based forwarding . . . . . . . . . . . . . . 23 10. Example: Layer 3 VPN Egress Protection
10. Example: Layer-3 VPN egress protection . . . . . . . . . . . 23 10.1. Egress Node Protection
10.1. Egress node protection . . . . . . . . . . . . . . . . . 25 10.2. Egress Link Protection
10.2. Egress link protection . . . . . . . . . . . . . . . . . 25 10.3. Global Repair
10.3. Global repair . . . . . . . . . . . . . . . . . . . . . 26 10.4. Other Modes of VPN Label Allocation
10.4. Other modes of VPN label allocation . . . . . . . . . . 26 11. IANA Considerations
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 12. Security Considerations
12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 13. References
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 13.2. Informative References
14.1. Normative References . . . . . . . . . . . . . . . . . . 28 Acknowledgements
14.2. Informative References . . . . . . . . . . . . . . . . . 28 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
In MPLS networks, label switched paths (LSPs) are widely used as In MPLS networks, Label Switched Paths (LSPs) are widely used as
transport tunnels to carry IP and MPLS services across MPLS domains. transport tunnels to carry IP and MPLS services across MPLS domains.
Examples of MPLS services are layer-2 VPNs, layer-3 VPNs, Examples of MPLS services are Layer 2 VPNs, Layer 3 VPNs,
hierarchical LSPs, and others. In general, a tunnel may carry hierarchical LSPs, and others. In general, a tunnel may carry
multiple services of one or multiple types, if the tunnel satisfies multiple services of one or multiple types, if the tunnel satisfies
both individual and aggregate requirements (e.g., CoS, QoS) of these both individual and aggregate requirements (e.g., Class of Service
services. The egress router of the tunnel hosts the service (CoS) and QoS) of these services. The egress router of the tunnel
instances of the services. An MPLS service instance forwards service hosts the service instances of the services. An MPLS service
packets via an egress link to the service destination, based on a instance forwards service packets via an egress link to the service
service label. An IP service instance does the same based on a destination, based on a service label. An IP service instance does
service IP address. The egress link is often called a PE-CE the same, based on an IP service address. The egress link is often
(provider edge - customer edge) link or attachment circuit (AC). called a Provider Edge - Customer Edge (PE-CE) link or Attachment
Circuit (AC).
Today, local-repair-based fast reroute mechanisms ([RFC4090], Today, local-repair-based fast reroute mechanisms (see [RFC4090],
[RFC5286], [RFC7490], and [RFC7812]) have been widely deployed to [RFC5286], [RFC7490], and [RFC7812]) have been widely deployed to
protect MPLS tunnels against transit link/node failures, with traffic protect MPLS tunnels against transit link/node failures, with traffic
restoration time in the order of tens of milliseconds. Local repair restoration time in the order of tens of milliseconds. Local repair
refers to the scenario where the router upstream to an anticipated refers to the scenario where the router upstream to an anticipated
failure, a.k.a. PLR (point of local repair), pre-establishes a failure, a.k.a., PLR, pre-establishes a bypass tunnel to the router
bypass tunnel to the router downstream of the failure, a.k.a. MP downstream of the failure, a.k.a., Merge Point (MP), pre-installs the
(merge point), pre-installs the forwarding state of the bypass tunnel forwarding state of the bypass tunnel in the data plane, and uses a
in the data plane, and uses a rapid mechanism (e.g., link layer OAM, rapid mechanism (e.g., link-layer Operations, Administration, and
BFD, and others) to locally detect the failure in the data plane. Maintenance (OAM), Bidirectional Forwarding Detection (BFD), and
When the failure occurs, the PLR reroutes traffic through the bypass others) to locally detect the failure in the data plane. When the
tunnel to the MP, allowing the traffic to continue to flow to the failure occurs, the PLR reroutes traffic through the bypass tunnel to
tunnel's egress router. 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 This document specifies a fast reroute framework for egress node and
egress link protection. Similar to transit link/node protection, egress link protection. Similar to transit link/node protection,
this framework also relies on a PLR to perform local failure this framework also relies on a PLR to perform local failure
detection and local repair. In egress node protection, the PLR is detection and local repair. In egress node protection, the PLR is
the penultimate-hop router of a tunnel. In egress link protection, the penultimate hop router of a tunnel. In egress link protection,
the PLR is the egress router of the tunnel. The framework further the PLR is the egress router of the tunnel. The framework further
uses a so-called "protector" to serve as the tailend of a bypass uses a so-called "protector" to serve as the tail end of a bypass
tunnel. The protector is a router that hosts "protection service tunnel. The protector is a router that hosts "protection service
instances" and has its own connectivity or paths to service instances" and has its own connectivity or paths to service
destinations. When a PLR does local repair, the protector performs destinations. When a PLR does local repair, the protector performs
"context label switching" for rerouted MPLS service packets and "context label switching" for rerouted MPLS service packets and
"context IP forwarding" for rerouted IP service packets, to allow the "context IP forwarding" for rerouted IP service packets, to allow the
service packets to continue to reach the service destinations. service packets to continue to reach the service destinations.
This framework considers an egress node failure as a failure of a 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 tunnel and a failure of all the services carried by the tunnel as
service packets can no longer reach the service instances on the service packets that can no longer reach the service instances on the
egress router. Therefore, the framework addresses egress node egress router. Therefore, the framework addresses egress node
protection at both tunnel level and service level simultaneously. protection at both the tunnel level and service level,
Likewise, the framework considers an egress link failure as a failure simultaneously. Likewise, the framework considers an egress link
of all the services traversing the link, and addresses egress link failure as a failure of all the services traversing the link and
protection at the service level. addresses egress link protection at the service level.
This framework requires that the destination (a CE or site) of a 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 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 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 the service's transport tunnel, and the other is a backup egress
router which hosts a "backup service instance". In the "co-located" router that hosts a "backup service instance". In the "co-located"
protector mode in this document, the backup egress router serves as protector mode in this document, the backup egress router serves as
the protector, and hence the backup service instance acts as the the protector; hence, the backup service instance acts as the
protection service instance. In the "centralized" protector mode protection service instance. In the "centralized" protector mode
(Section 5.12), the protector and the backup egress router are (Section 5.12), the protector and the backup egress router are
decoupled, and the protection service instance and the backup service decoupled, and the protection service instance and the backup service
instance are hosted separately by the two routers. instance are hosted separately by the two routers.
The framework is described by mainly referring to P2P (point-to- The framework is described by mainly referring to point-to-point
point) tunnels. However, it is equally applicable to P2MP (point-to- (P2P) tunnels. However, it is equally applicable to point-to-
multipoint), MP2P (multipoint-to-point), and MP2MP (multipoint-to- multipoint (P2MP), multipoint-to-point (MP2P), and multipoint-to-
multipoint) tunnels, as the sub-LSPs of these tunnels can be viewed multipoint (MP2MP) tunnels, as the sub-LSPs of these tunnels can be
as P2P tunnels. viewed as P2P tunnels.
The framework is a multi-service and multi-transport framework. It The framework is a multi-service and multi-transport framework. It
assumes a generic model where each service is comprised of a common assumes a generic model where each service is comprised of a common
set of components, including a service instance, a service label, a set of components, including a service instance, a service label, a
service label distribution protocol, and an MPLS transport tunnel. service label distribution protocol, and an MPLS transport tunnel.
The framework also assumes the service label to be downstream The framework also assumes that the service label is downstream
assigned, i.e., assigned by an egress router. Therefore, the assigned, i.e., assigned by an egress router. Therefore, the
framework is generally applicable to most existing and future framework is generally applicable to most existing and future
services. However, there are services with certain modes, where a services. However, there are services with certain modes, where a
protector is unable to pre-establish forwarding state for egress protector is unable to pre-establish the forwarding state for egress
protection, or a PLR is not allowed to reroute traffic to other protection, or a PLR is not allowed to reroute traffic to other
routers in order to avoid traffic duplication, e.g., the broadcast, routers in order to avoid traffic duplication, e.g., the broadcast,
multicast, and unknown unicast traffic in VPLS and EVPN. These cases multicast, and unknown unicast traffic in Virtual Private LAN Service
are left for future study. Services which use upstream-assigned (VPLS) and Ethernet VPN (EVPN). These cases are left for future
service labels are also out of scope of this document and left for study. Services that use upstream-assigned service labels are also
future study. out of scope of this document and left for future study.
The framework does not require extensions for the existing signaling The framework does not require extensions for the existing signaling
and label distribution protocols (e.g., RSVP, LDP, BGP, etc.) of MPLS and label distribution protocols (e.g., RSVP, LDP, BGP, etc.) of MPLS
tunnels. It assumes transport tunnels and bypass tunnels to be tunnels. It assumes that transport tunnels and bypass tunnels are to
established by using the generic procedures provided by the be established by using the generic procedures provided by the
protocols. On the other hand, it does not preclude extensions to the protocols. On the other hand, it does not preclude extensions to the
protocols which may facilitate the procedures. One example of such protocols that may facilitate the procedures. One example of such
extension is [RFC8400]. The framework does see the need for extension is [RFC8400]. The framework does see the need for
extensions of IGPs and service label distribution protocols in some extensions of IGPs and service label distribution protocols in some
procedures, particularly for supporting protection establishment and procedures, particularly for supporting protection establishment and
context label switching. This document provides guidelines for these context label switching. This document provides guidelines for these
extensions, but leaves the specific details to separate documents. extensions, but it leaves the specific details to separate documents.
The framework is intended to complement control-plane convergence and The framework is intended to complement control-plane convergence and
global repair. Control-plane convergence relies on control protocols global repair. Control-plane convergence relies on control protocols
to react on the topology changes due to a failure. Global repair to react on the topology changes due to a failure. Global repair
relies an ingress router to remotely detect a failure and switch relies on an ingress router to remotely detect a failure and switch
traffic to an alternative path. An example of global repair is the traffic to an alternative path. An example of global repair is the
BGP Prefix Independent Convergence mechanism [BGP-PIC] for BGP BGP prefix independent convergence mechanism [BGP-PIC] for BGP-
established services. Compared with these mechanisms, this framework established services. Compared with these mechanisms, this framework
is considered as faster in traffic restoration, due to the nature of is considered faster in traffic restoration, due to the nature of
local failure detection and local repair. It is RECOMMENDED that the local failure detection and local repair. It is RECOMMENDED that the
framework be used in conjunction with control-plane convergence or framework be used in conjunction with control-plane convergence or
global repair, in order to take the advantages of both approaches. global repair, in order to take the advantages of both approaches.
That is, the framework provides fast and temporary repair, while That is, the framework provides fast and temporary repair, while
control-plane convergence or global repair provides ultimate and control-plane convergence or global repair provides ultimate and
permanent repair. permanent repair.
2. Specification of Requirements 2. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119] and "OPTIONAL" in this document are to be interpreted as described in
[RFC8174]. BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology 3. Terminology
Egress router - A router at the egress endpoint of a tunnel. It Egress router:
hosts service instances for all the services carried by the tunnel, A router at the egress endpoint of a tunnel. It hosts service
and has connectivity with the destinations of the services. 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 node failure:
A failure of an egress router.
Egress link failure - A failure of the egress link (e.g., PE-CE link, Egress link failure:
attachment circuit) of a service. 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 failure:
An egress node failure or an egress link failure.
Egress-protected tunnel - A tunnel whose egress router is protected Egress-protected tunnel:
by a mechanism according to this framework. The egress router is A tunnel whose egress router is protected by a mechanism according
hence called a protected egress router. to this framework. The egress router is hence called a protected
egress router.
Egress-protected service - An IP or MPLS service which is carried by Egress-protected service:
an egress-protected tunnel, and hence protected by a mechanism An IP or MPLS service that is carried by an egress-protected
according to this framework. tunnel and hence protected by a mechanism according to this
framework.
Backup egress router - Given an egress-protected tunnel and its Backup egress router:
egress router, this is another router which has connectivity with all Given an egress-protected tunnel and its egress router, this is
or a subset of the destinations of the egress-protected services another router that has connectivity with all or a subset of the
carried by the egress-protected tunnel. destinations of the egress-protected services carried by the
egress-protected tunnel.
Backup service instance - A service instance which is hosted by a Backup service instance:
backup egress router, and corresponding to an egress-protected A service instance that is hosted by a backup egress router and
service on a protected egress router. corresponds to an egress-protected service on a protected egress
router.
Protector - A role acted by a router as an alternate of a protected Protector:
egress router, to handle service packets in the event of an egress A role acted by a router as an alternate of a protected egress
failure. A protector may be physically co-located with or decoupled router, to handle service packets in the event of an egress
from a backup egress router, depending on the co-located or failure. A protector may be physically co-located with or
centralized protector mode. decoupled from a backup egress router, depending on the co-located
or centralized protector mode.
Protection service instance - A service instance hosted by a Protection service instance:
protector, corresponding to the service instance of an egress- A service instance hosted by a protector that corresponds to the
protected service on a protected egress router. A protection service service instance of an egress-protected service on a protected
instance is a backup service instance, if the protector is co-located egress router. A protection service instance is a backup service
with a backup egress router. instance, if the protector is co-located with a backup egress
router.
PLR - A router at the point of local repair. In egress node PLR:
protection, it is the penultimate-hop router on an egress-protected A router at the point of local repair. In egress node protection,
tunnel. In egress link protection, it is the egress router of the it is the penultimate hop router on an egress-protected tunnel.
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 Protected egress {E, P}:
pair of egress router E and protector P. It serves as the virtual A virtual node consisting of an ordered pair of egress router E
destination of an egress-protected tunnel, and as the virtual and protector P. It serves as the virtual destination of an
location of the egress-protected services carried by the tunnel. 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 Context identifier (ID):
protected egress {E, P}. 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 Context label:
protector. A non-reserved label assigned to a context ID by a protector.
Egress-protection bypass tunnel - A tunnel used to reroute service Egress-protection bypass tunnel:
packets around an egress failure. A tunnel used to reroute service packets around an egress failure.
Co-located protector mode - The scenario where a protector and a Co-located protector mode:
backup egress router are co-located as one router, and hence each The scenario where a protector and a backup egress router are co-
backup service instance serves as a protection service instance. 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 Centralized protector mode:
dedicated router, and is decoupled from backup egress routers. 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, Context label switching:
in the label space of an egress router indicated by a context label. 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 Context IP forwarding:
the IP address space of an egress router indicated by a context IP forwarding performed by a protector in the IP address space of
label. an egress router indicated by a context label.
4. Requirements 4. Requirements
This document considers the following as the design requirements of This document considers the following as the design requirements of
this egress protection framework. this egress protection framework.
o The framework must support P2P tunnels. It should equally support * The framework must support P2P tunnels. It should equally support
P2MP, MP2P and MP2MP tunnels, by treating each sub-LSP as a P2P P2MP, MP2P, and MP2MP tunnels, by treating each sub-LSP as a P2P
tunnel. tunnel.
o The framework must support multi-service and multi-transport * The framework must support multi-service and multi-transport
networks. It must accommodate existing and future signaling and networks. It must accommodate existing and future signaling and
label-distribution protocols of tunnels and bypass tunnels, label-distribution protocols of tunnels and bypass tunnels,
including RSVP, LDP, BGP, IGP, segment routing, and others. It including RSVP, LDP, BGP, IGP, Segment Routing, and others. It
must also accommodate existing and future IP/MPLS services, must also accommodate existing and future IP/MPLS services,
including layer-2 VPNs, layer-3 VPNs, hierarchical LSP, and including Layer 2 VPNs, Layer 3 VPNs, hierarchical LSP, and
others. It MUST provide a general solution for networks where others. It MUST provide a general solution for networks where
different types of services and tunnels co-exist. different types of services and tunnels co-exist.
o The framework must consider minimizing disruption during * The framework must consider minimizing disruption during
deployment. It should only involve routers close to egress, and deployment. It should only involve routers close to the egress
be transparent to ingress routers and other transit routers. and be transparent to ingress routers and other transit routers.
o In egress node protection, for scalability and performance * In egress node protection, for scalability and performance
reasons, a PLR must be agnostic to services and service labels. reasons, a PLR must be agnostic to services and service labels.
It must maintain bypass tunnels and bypass forwarding state on a It must maintain bypass tunnels and bypass forwarding state on a
per-transport-tunnel basis, rather than on a per-service- per-transport-tunnel basis rather than on a per-service-
destination or per-service-label basis. It should also support destination or per-service-label basis. It should also support
bypass tunnel sharing between transport tunnels. bypass tunnel sharing between transport tunnels.
o A PLR must be able to use its local visibility or information of * 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 routing or TE topology to compute or resolve a path for a bypass
tunnel. tunnel.
o A protector must be able to perform context label switching for * A protector must be able to perform context label switching for
rerouted MPLS service packets, based on service label(s) assigned rerouted MPLS service packets, based on a service label(s)
by an egress router. It must be able to perform context IP assigned by an egress router. It must be able to perform context
forwarding for rerouted IP service packets, in the public or IP forwarding for rerouted IP service packets, in the public or
private IP address space used by an egress router. private IP address space used by an egress router.
o The framework must be able to work seamlessly with transit link/ * The framework must be able to work seamlessly with transit link/
node protection mechanisms to achieve end-to-end coverage. node protection mechanisms to achieve end-to-end coverage.
o The framework must be able to work in conjunction with global * The framework must be able to work in conjunction with global
repair and control plane convergence. repair and control-plane convergence.
5. Egress node protection 5. Egress Node Protection
5.1. Reference topology 5.1. Reference Topology
This document refers to the following topology when describing the This document refers to the following topology when describing the
procedures of egress node protection. procedures of egress node protection.
services 1, ..., N services 1, ..., N
=====================================> tunnel =====================================> tunnel
I ------ R1 ------- PLR --------------- E ---- I ------ R1 ------- PLR --------------- E ----
ingress penultimate-hop egress \ ingress penultimate hop egress \
| . (primary \ | . (primary \
| . service \ | . service \
| . instances) \ | . instances ) \
| . \ | . \
| . \ service | . \ service
| . destinations | . destinations
| . / (CEs, sites) | . / (CEs, sites)
| . / | . /
| . bypass / | . bypass /
| . tunnel / | . tunnel /
| . / | . /
| ............... / | ............... /
R2 --------------- P ---- R2 --------------- P ----
protector protector
(protection (protection
service service
instances) instances)
Figure 1 Figure 1
5.2. Egress node failure and detection 5.2. Egress Node Failure and Detection
An egress node failure refers to the failure of an MPLS tunnel's 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 egress router. At the service level, it is also a service instance
failure for each IP/MPLS service carried by the tunnel. failure for each IP/MPLS service carried by the tunnel.
An egress node failure can be detected by an adjacent router (i.e., An egress node failure can be detected by an adjacent router (i.e.,
PLR in this framework) through a node liveness detection mechanism, PLR in this framework) through a node liveness detection mechanism or
or a mechanism based on a collective failure of all the links to that a mechanism based on a collective failure of all the links to that
node. The mechanisms MUST be reasonably fast, i.e., faster than node. The mechanisms MUST be reasonably fast, i.e., faster than
control plane failure detection and remote failure detection. control-plane failure detection and remote failure detection.
Otherwise, local repair will not be able to provide much benefit Otherwise, local repair will not be able to provide much benefit
compared to control plane convergence or global repair. In general, compared to control-plane convergence or global repair. In general,
the speed, accuracy, and reliability of a failure detection mechanism the speed, accuracy, and reliability of a failure detection mechanism
are the key factors to decide its applicability in egress node are the key factors to decide its applicability in egress node
protection. This document provides the following guidelines for protection. This document provides the following guidelines for
network operators to choose a proper type of protection on a PLR. network operators to choose a proper type of protection on a PLR.
o If the PLR has a mechanism to detect and differentiate a link * 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 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 failure, it SHOULD set up both link protection and
egress node protection, and trigger one and only one protection egress node protection and trigger one and only one protection
upon a corresponding failure. upon a corresponding failure.
o If the PLR has a fast mechanism to detect a link failure and an * If the PLR has a fast mechanism to detect a link failure and an
egress node failure, but cannot distinguish them; or, if the PLR 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 has a fast mechanism to detect a link failure only, but not an
egress node failure, the PLR has two options: egress node failure, the PLR has two options:
1. It MAY set up link protection only, and leave the egress node 1. It MAY set up link protection only and leave the egress node
failure to be handled by global repair and control plane failure to be handled by global repair and control-plane
convergence. convergence.
2. It MAY set up egress node protection only, and treat a link 2. It MAY set up egress node protection only and treat a link
failure as a trigger for the egress node protection. The failure as a trigger for the egress node protection. The
assumption is that treating a link failure as an egress node assumption is that treating a link failure as an egress node
failure MUST NOT have a negative impact on services. failure MUST NOT have a negative impact on services.
Otherwise, it SHOULD adopt the previous option. Otherwise, it SHOULD adopt the previous option.
5.3. Protector and PLR 5.3. Protector and PLR
A router is assigned to the "protector" role to protect a tunnel and 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 services carried by the tunnel against an egress node failure.
The protector is responsible for hosting a protection service The protector is responsible for hosting a protection service
instance for each protected service, serving as the tailend of a instance for each protected service, serving as the tail end of a
bypass tunnel, and performing context label switching and/or context bypass tunnel, and performing context label switching and/or context
IP forwarding for rerouted service packets. IP forwarding for rerouted service packets.
A tunnel is protected by only one protector. Multiple tunnels to a A tunnel is protected by only one protector. Multiple tunnels to a
given egress router may be protected by a common protector or given egress router may be protected by a common protector or
different protectors. A protector may protect multiple tunnels with different protectors. A protector may protect multiple tunnels with
a common egress router or different egress routers. a common egress router or different egress routers.
For each tunnel, its penultimate-hop router acts as a PLR. The PLR For each tunnel, its penultimate hop router acts as a PLR. The PLR
pre-establishes a bypass tunnel to the protector, and pre-installs pre-establishes a bypass tunnel to the protector and pre-installs
bypass forwarding state in the data plane. Upon detection of an bypass forwarding state in the data plane. Upon detection of an
egress node failure, the PLR reroutes all the service packets egress node failure, the PLR reroutes all the service packets
received on the tunnel though the bypass tunnel to the protector. received on the tunnel through the bypass tunnel to the protector.
For MPLS service packets, the PLR keeps service labels intact in the For MPLS service packets, the PLR keeps service labels intact in the
packets. The protector in turn forwards the service packets towards packets. In turn, the protector forwards the service packets towards
the ultimate service destinations. Specifically, it performs context the ultimate service destinations. Specifically, it performs context
label switching for MPLS service packets, based on the service labels label switching for MPLS service packets, based on the service labels
assigned by the protected egress router; it performs context IP assigned by the protected egress router; it performs context IP
forwarding for IP service packets, based on their destination forwarding for IP service packets, based on their destination
addresses. addresses.
The protector MUST have its own connectivity with each service The protector MUST have its own connectivity with each service
destination, via a direct link or a multi-hop path, which MUST NOT destination, via a direct link or a multi-hop path, which MUST NOT
traverse the protected egress router or be affected by the egress traverse the protected egress router or be affected by the egress
node failure. This also means that each service destination MUST be node failure. This also means that each service destination MUST be
dual-homed or have dual paths to the egress router and a backup dual-homed or have dual paths to the egress router and a backup
egress router which may serve as the protector. Each protection egress router that may serve as the protector. Each protection
service instance on the protector relies on such connectivity to set service instance on the protector relies on such connectivity to set
up forwarding state for context label switching and context IP up forwarding state for context label switching and context IP
forwarding. forwarding.
5.4. Protected egress 5.4. Protected Egress
This document introduces the notion of "protected egress" as a This document introduces the notion of "protected egress" as a
virtual node consisting of the egress router E of a tunnel and 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 protector P. It is denoted by an ordered pair of {E, P}, indicating
the primary-and-protector relationship between the two routers. It the primary-and-protector relationship between the two routers. It
serves as the virtual destination of the tunnel, and the virtual serves as the virtual destination of the tunnel and the virtual
location of service instances for the services carried by the tunnel. location of service instances for the services carried by the tunnel.
The tunnel and services are considered as being "associated" with the The tunnel and services are considered as being "associated" with the
protected egress {E, P}. protected egress {E, P}.
A given egress router E may be the tailend of multiple tunnels. In 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., 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. 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}, 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 {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 protected egress {E, Pi}. All the services carried by the tunnel are
then automatically associated with the protected egress {E, Pi}. then automatically associated with the protected egress {E, Pi}.
Conversely, a service associated with a protected egress {E, Pi} MUST Conversely, a service associated with a protected egress {E, Pi} MUST
be carried by a tunnel associated with the protected egress {E, Pi}. 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 This mapping MUST be ensured by the ingress router of the tunnel and
the service (Section 5.5). the service (Section 5.5).
Two routers X and Y may be protectors for each other. In this case, The two routers X and Y may be protectors for each other. In this
they form two distinct protected egresses {X, Y} and {Y, X}. case, they form two distinct protected egresses: {X, Y} and {Y, X}.
5.5. Egress-protected tunnel and service 5.5. Egress-Protected Tunnel and Service
A tunnel, which is associated with a protected egress {E, P}, is A tunnel, which is associated with a protected egress {E, P}, is
called an egress-protected tunnel. It is associated with one and called an egress-protected tunnel. It is associated with one and
only one protected egress {E, P}. Multiple egress-protected tunnels only one protected egress {E, P}. Multiple egress-protected tunnels
may be associated with a given protected egress {E, P}. In this case, may be associated with a given protected egress {E, P}. In this
they share the common egress router and protector, but may or may not case, they share the common egress router and protector, but they may
share a common ingress router, or a common PLR (i.e., penultimate-hop or may not share a common ingress router or a common PLR (i.e.,
router). penultimate hop router).
An egress-protected tunnel is considered as logically "destined" for An egress-protected tunnel is considered as logically "destined" for
its protected egress {E, P}. Its path MUST be resolved and its protected egress {E, P}. Its path MUST be resolved and
established with E as the physical tailend. established with E as the physical tail end.
A service, which is associated with a protected egress {E, P}, is A service, which is associated with a protected egress {E, P}, is
called an egress-protected service. The egress router E hosts the called an egress-protected service. Egress router E hosts the
primary instance of the service, and the protector P hosts the primary instance of the service, and protector P hosts the protection
protection instance of the service. instance of the service.
An egress-protected service is associated with one and only one An egress-protected service is associated with one and only one
protected egress {E, P}. Multiple egress-protected services may be protected egress {E, P}. Multiple egress-protected services may be
associated with a given protected egress {E, P}. In this case, these associated with a given protected egress {E, P}. In this case, these
services share the common egress router and protector, but may or may services share the common egress router and protector, but they may
not be carried by a common egress-protected tunnel or a common or may not be carried by a common egress-protected tunnel or a common
ingress router. ingress router.
An egress-protected service MUST be mapped to an egress-protected An egress-protected service MUST be mapped to an egress-protected
tunnel by its ingress router, based on the common protected egress tunnel by its ingress router, based on the common protected egress
{E, P} of the service and the tunnel. This is achieved by {E, P} of the service and the tunnel. This is achieved by
introducing the notion of "context ID" for protected egress {E, P}, introducing the notion of a "context ID" for a protected egress {E,
as described in (Section 5.7). P}, as described in Section 5.7.
5.6. Egress-protection bypass tunnel 5.6. Egress-Protection Bypass Tunnel
An egress-protected tunnel destined for a protected egress {E, P} An egress-protected tunnel destined for a protected egress {E, P}
MUST have a bypass tunnel from its PLR to the protector P. This MUST have a bypass tunnel from its PLR to protector P. This bypass
bypass tunnel is called an egress-protection bypass tunnel. The tunnel is called an egress-protection bypass tunnel. The bypass
bypass tunnel is considered as logically "destined" for the protected tunnel is considered as logically "destined" for the protected egress
egress {E, P}. Due to its bypass nature, it MUST be established with {E, P}. Due to its bypass nature, it MUST be established with P as
P as the physical tailend and E as the node to avoid. The bypass the physical tail end and E as the node to avoid. The bypass tunnel
tunnel MUST have the property that it MUST NOT be affected by the MUST NOT be affected by the topology change caused by an egress node
topology change caused by an egress node failure. failure; thus, it MUST contain a property that protects it from this
scenario.
An egress-protection bypass tunnel is associated with one and only An egress-protection bypass tunnel is associated with one and only
one protected egress {E, P}. A PLR may share an egress-protection one protected egress {E, P}. A PLR may share an egress-protection
bypass tunnel for multiple egress-protected tunnels associated with a bypass tunnel for multiple egress-protected tunnels associated with a
common protected egress {E, P}. common protected egress {E, P}.
5.7. Context ID, context label, and context-based forwarding 5.7. Context ID, Context Label, and Context-Based Forwarding
In this framework, a globally unique IPv4 or IPv6 address is assigned In this framework, a globally unique IPv4 or IPv6 address is assigned
to a protected egress {E, P} as the identifier of the protected as the identifier of the protected egress {E, P}. It is called a
egress {E, P}. It is called a "context ID" due to its specific usage "context ID" due to its specific usage in context label switching and
in context label switching and context IP forwarding on the context IP forwarding on the protector. It is an IP address that is
protector. It is an IP address that is logically owned by both the logically owned by both the egress router and the protector. For the
egress router and the protector. For the egress router, it indicates egress router, it indicates the protector. For the protector, it
the protector. For the protector, it indicates the egress router, indicates the egress router, particularly the egress router's
particularly the egress router's forwarding context. For other forwarding context. For other routers in the network, it is an
routers in the network, it is an address reachable via both the address reachable via both the egress router and the protector
egress router and the protector (Section 5.8), similar to an anycast (Section 5.8), similar to an anycast address.
address.
The main purpose of a context ID is to coordinate ingress router, The main purpose of a context ID is to coordinate the ingress router,
egress router, PLR and protector to establish egress protection. The egress router, PLR, and protector to establish egress protection.
procedures are described below, given an egress-protected service The procedures are described below, given an egress-protected service
associated with a protected egress {E, P} with context ID. associated with a protected egress {E, P} with a context ID.
o If the service is an MPLS service, when E distributes a service * If the service is an MPLS service, when E distributes a service
label binding message to the ingress router, E attaches the label binding message to the ingress router, E attaches the
context ID to the message. If the service is an IP service, when context ID to the message. If the service is an IP service, when
E advertises the service destination address to the ingress E advertises the service destination address to the ingress
router, E attaches the context ID to the advertisement message. router, E attaches the context ID to the advertisement message.
How the context ID is encoded in the messages is a choice of the The service protocol chooses how the context ID is encoded in the
service protocol. A protocol extension of a "context ID" object messages. A protocol extension of a "context ID" object may be
may be needed, if there is no existing mechanism for this purpose. needed, if there is no existing mechanism for this purpose.
o The ingress router uses the service's context ID as the * The ingress router uses the service's context ID as the
destination to establish or resolve an egress-protected tunnel. destination to establish or resolve an egress-protected tunnel.
The ingress router then maps the service to the tunnel for The ingress router then maps the service to the tunnel for
transportation. The semantics of the context ID is transparent to transportation. The semantics of the context ID is transparent to
the ingress router. The ingress router only treats the context ID the ingress router. The ingress router only treats the context ID
as an IP address of E, in the same manner as establishing or as an IP address of E, in the same manner as establishing or
resolving a regular transport tunnel. resolving a regular transport tunnel.
o The context ID is conveyed to the PLR by the signaling protocol of * 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 the egress-protected tunnel or learned by the PLR via an IGP
(i.e., OSPF or ISIS) or a topology-driven label distribution (i.e., OSPF or IS-IS) or a topology-driven label distribution
protocol (e.g., LDP). The PLR uses the context ID as destination protocol (e.g., LDP). The PLR uses the context ID as the
to establish or resolve an egress-protection bypass tunnel to P destination to establish or resolve an egress-protection bypass
while avoiding E. tunnel to P while avoiding E.
o P maintains a dedicated label space and a dedicated IP address * 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 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 IP address space", respectively. P uses the context ID to
identify the label space and IP address space. identify the label space and IP address space.
o If the service is an MPLS service, E also distributes the service * If the service is an MPLS service, E also distributes the service
label binding message to P. This is the same label binding label binding message to P. This is the same label binding
message that E advertises to the ingress router, which includes message that E advertises to the ingress router, which includes
the context ID. Based on the context ID, P installs the service the context ID. Based on the context ID, P installs the service
label in an MPLS forwarding table corresponding to E's label 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 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 an IP forwarding table corresponding to E's IP address space. In
either case, the protection service instance on P constructs either case, the protection service instance on P constructs the
forwarding state for the label route or IP route based on P's own forwarding state for the label route or IP route based on P's own
connectivity with the service's destination. connectivity with the service's destination.
o P assigns a non-reserved label to the context ID. In the data * P assigns a non-reserved label to the context ID. In the data
plane, this label represents the context ID and indicates E's plane, this label represents the context ID and indicates E's
label space and IP address space. Therefore, it is called a label space and IP address space. Therefore, it is called a
"context label". "context label".
o The PLR may establish the egress-protection bypass tunnel to P in * The PLR may establish the egress-protection bypass tunnel to P in
several manners. If the bypass tunnel is established by RSVP, the several manners. If the bypass tunnel is established by RSVP, the
PLR signals the bypass tunnel with the context ID as destination, PLR signals the bypass tunnel with the context ID as the
and P binds the context label to the bypass tunnel. If the bypass destination, and P binds the context label to the bypass tunnel.
tunnel is established by LDP, P advertises the context label for If the bypass tunnel is established by LDP, P advertises the
the context ID as an IP prefix FEC. If the bypass tunnel is context label for the context ID as an IP prefix Forwarding
established by the PLR in a hierarchical manner, the PLR treats Equivalence Class (FEC). If the bypass tunnel is established by
the context label as a one-hop LSP over a regular bypass tunnel to the PLR in a hierarchical manner, the PLR treats the context label
P (e.g., a bypass tunnel to P's loopback IP address). If the as a one-hop LSP over a regular bypass tunnel to P (e.g., a bypass
bypass tunnel is constructed by using segment routing, the bypass tunnel to P's loopback IP address). If the bypass tunnel is
tunnel is represented by a stack of SID labels with the context constructed by using Segment Routing, the bypass tunnel is
label as the inner-most SID label (Section 5.9). In any case, the represented by a stack of Segment Identifier (SID) labels with the
bypass tunnel is a ultimate-hop-popping (UHP) tunnel whose context label as the inner-most SID label (Section 5.9). In any
incoming label on P is the context label. case, the bypass tunnel is an ultimate hop-popping (UHP) tunnel
whose incoming label on P is the context label.
o During local repair, all the service packets received by P on the * During local repair, all the service packets received by P on the
bypass tunnel have the context label as the top label. P first bypass tunnel have the context label as the top label. P first
pops the context label. For an MPLS service packet, P further pops the context label. For an MPLS service packet, P looks up
looks up the service label in E's label space indicated by the the service label in E's label space indicated by the context
context label. Such kind of forwarding is called context label label. Such kind of forwarding is called context label switching.
switching. For an IP service packet, P looks up the IP For an IP service packet, P looks up the IP destination address in
destination address in E's IP address space indicated by the E's IP address space indicated by the context label. Such kind of
context label. Such kind of forwarding is called context IP forwarding is called context IP forwarding.
forwarding.
5.8. Advertisement and path resolution for context ID 5.8. Advertisement and Path Resolution for Context ID
Path resolution and computation for a context ID are done on ingress Path resolution and computation for a context ID are done on ingress
routers for egress-protected tunnels, and on PLRs for egress- routers for egress-protected tunnels and on PLRs for egress-
protection bypass tunnels. Given a protected egress {E, P} and its 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, E and P MUST coordinate on the reachability of the
context ID in the routing domain and the TE domain. The context ID 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 be advertised in such a manner that all egress-protected tunnels
MUST have E as tailend, and all egress-protection bypass tunnels MUST MUST have E as the tail end, and all egress-protection bypass tunnels
have P as tailend while avoiding E. MUST have P as the tail end while avoiding E.
This document suggests three approaches: This document suggests three approaches:
1. The first approach is called "proxy mode". It requires E and P, 1. The first approach is called "proxy mode". It requires E and
but not the PLR, to have the knowledge of the egress protection P, but not the PLR, to have the knowledge of the egress
schema. E and P advertise the context ID as a virtual proxy node protection schema. E and P advertise the context ID as a
(i.e., a logical node) connected to the two routers, with the virtual proxy node (i.e., a logical node) connected to the two
link between the proxy node and E having more preferable IGP and routers, with the link between the proxy node and E having
TE metrics than the link between the proxy node and P. more preferable IGP and TE metrics than the link between the
Therefore, all egress-protected tunnels destined for the context proxy node and P. Therefore, all egress-protected tunnels
ID will automatically follow the IGP or TE paths to E. Each PLR destined for the context ID will automatically follow the IGP
will no longer view itself as a penultimate-hop, but rather two or TE paths to E. Each PLR will no longer view itself as a
hops away from the proxy node, via E. The PLR will be able to penultimate hop but rather as two hops away from the proxy
find a bypass path via P to the proxy node, while the bypass node, via E. The PLR will be able to find a bypass path via P
tunnel is actually be terminated by 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 2. The second approach is called "alias mode". It requires P and
the PLR, but not E, to have the knowledge of the egress the PLR, but not E, to have the knowledge of the egress
protection schema. E simply advertises the context ID as an IP protection schema. E simply advertises the context ID as an
address. P advertises the context ID and the context label by IP address. P advertises the context ID and the context label
using a "context ID label binding" advertisement. In both by using a "context ID label binding" advertisement. In both
routing domain and TE domain, the context ID is only reachable the routing domain and TE domain, the context ID is only
via E. Therefore, all egress-protected tunnels destined for the reachable via E. Therefore, all egress-protected tunnels
context ID will have E as tailend. Based on the "context ID destined for the context ID will have E as the tail end.
label binding" advertisement, the PLR can establish an egress- Based on the "context ID label binding" advertisement, the PLR
protection bypass tunnel in several manners (Section 5.9). The can establish an egress-protection bypass tunnel in several
"context ID label binding" advertisement is defined as IGP manners (Section 5.9). The "context ID label binding"
mirroring context segment in [RFC8402] and [SR-ISIS]. These IGP advertisement is defined as the IGP Mirroring Context segment
extensions are generic in nature, and hence can be used for in [RFC8402] and [RFC8667]. These IGP extensions are generic
egress protection purposes. It is RECOMMENDED that a similar in nature and hence can be used for egress protection
advertisement be defined for OSPF as well. 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, 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 both E and P advertise the context ID as a link to a stub
network, essentially modelling the context ID as an anycast IP network, essentially modeling the context ID as an anycast IP
address owned by the two routers. E, P and the PLR do not need address owned by the two routers. E, P, and the PLR do not
to have the knowledge of the egress protection schema. The need to have the knowledge of the egress protection schema.
correctness of the egress-protected tunnels and the bypass The correctness of the egress-protected tunnels and the bypass
tunnels relies on the path computations for the anycast IP tunnels relies on the path computations for the anycast IP
address performed by the ingress routers and PLR. Therefore, address performed by the ingress routers and PLR. Therefore,
care MUST be taken for the applicability of this approach to a care MUST be taken for the applicability of this approach to a
network. network.
This framework considers the above approaches as technically equal, This framework considers the above approaches as technically equal
and the feasibility of each approach in a given network as dependent and the feasibility of each approach in a given network as dependent
on the topology, manageability, and available protocols of the on the topology, manageability, and available protocols of the
network. For a given context ID, all relevant routers, including network. For a given context ID, all relevant routers, including the
primary PE, protector, and PLR, MUST support and agree on the chosen primary PE, protector, and PLR, MUST support and agree on the chosen
approach. The coordination between these routers can be achieved by approach. The coordination between these routers can be achieved by
configuration. configuration.
In a scenario where an egress-protected tunnel is an inter-area or In a scenario where an egress-protected tunnel is an inter-area or
inter-AS tunnel, its associated context ID MUST be propagated by IGP inter-Autonomous-System (inter-AS) tunnel, its associated context ID
or BGP from the original area or AS to the area or AS of the ingress MUST be propagated by IGP or BGP from the original area or AS to the
router. The propagation process of the context ID SHOULD be the same area or AS of the ingress router. The propagation process of the
as that of an IP address in an inter-area or inter-AS environment. 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 5.9. Egress-Protection Bypass Tunnel Establishment
A PLR MUST know the context ID of a protected egress {E, P} in order 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 to establish an egress-protection bypass tunnel. The information is
obtained from the signaling or label distribution protocol of the obtained from the signaling or label distribution protocol of the
egress-protected tunnel. The PLR may or may not need to have the egress-protected tunnel. The PLR may or may not need to have the
knowledge of the egress protection schema. All it does is to set up knowledge of the egress-protection schema. All it does is set up a
a bypass tunnel to a context ID while avoiding the next-hop router bypass tunnel to a context ID while avoiding the next-hop router
(i.e., egress router). This is achievable by using a constraint- (i.e., egress router). This is achievable by using a constraint-
based computation algorithm similar to those commonly used for based computation algorithm similar to those commonly used for
traffic engineering paths and loop-free alternate (LFA) paths. Since traffic engineering paths and Loop-Free Alternate (LFA) paths. Since
the context ID is advertised in the routing domain and the TE domain the context ID is advertised in the routing domain and in the TE
by IGP according to Section 5.8, the PLR is able to resolve or domain by IGP according to Section 5.8, the PLR is able to resolve or
establish such a bypass path with the protector as tailend. In the establish such a bypass path with the protector as the tail end. In
case of proxy mode, the PLR may do so in the same manner as transit the case of proxy mode, the PLR may do so in the same manner as
node protection. transit node protection.
An egress-protection bypass tunnel may be established via several An egress-protection bypass tunnel may be established via several
methods: methods:
(1) It may be established by a signaling protocol (e.g., RSVP), with 1. It may be established by a signaling protocol (e.g., RSVP),
the context ID as destination. The protector binds the context label with the context ID as the destination. The protector binds
to the bypass tunnel. the context label to the bypass tunnel.
(2) It may be formed by a topology driven protocol (e.g., LDP with 2. It may be formed by a topology-driven protocol (e.g., LDP with
various LFA mechanisms). The protector advertises the context ID as various LFA mechanisms). The protector advertises the context
an IP prefix FEC, with the context label bound to it. ID as an IP prefix FEC, with the context label bound to it.
(3) It may be constructed as a hierarchical tunnel. When the 3. It may be constructed as a hierarchical tunnel. When the
protector uses the alias mode (Section 5.8), the PLR will have the protector uses the alias mode (Section 5.8), the PLR will have
knowledge of the context ID, context label, and protector (i.e., the the knowledge of the context ID, context label, and protector
advertiser). The PLR can then establish the bypass tunnel in a (i.e., the advertiser). The PLR can then establish the bypass
hierarchical manner, with the context label as a one-hop LSP over a tunnel in a hierarchical manner, with the context label as a
regular bypass tunnel to the protector's IP address (e.g., loopback one-hop LSP over a regular bypass tunnel to the protector's IP
address). This regular bypass tunnel may be established by RSVP, address (e.g., loopback address). This regular bypass tunnel
LDP, segment routing, or another protocol. may be established by RSVP, LDP, Segment Routing, or another
protocol.
5.10. Local repair on PLR 5.10. Local Repair on PLR
In this framework, a PLR is agnostic to services and service labels. In this framework, a PLR is agnostic to services and service labels.
This obviates the need to maintain bypass forwarding state on a per- This obviates the need to maintain bypass forwarding state on a per-
service basis, and allows bypass tunnel sharing between egress- service basis and allows bypass tunnel sharing between egress-
protected tunnels. The PLR may share an egress-protection bypass protected tunnels. The PLR may share an egress-protection bypass
tunnel for multiple egress-protected tunnels associated with a common tunnel for multiple egress-protected tunnels associated with a common
protected egress {E, P}. During local repair, the PLR reroutes all protected egress {E, P}. During local repair, the PLR reroutes all
service packets received on the egress-protected tunnels to the service packets received on the egress-protected tunnels to the
egress-protection bypass tunnel. Service labels remain intact in egress-protection bypass tunnel. Service labels remain intact in
MPLS service packets. MPLS service packets.
Label operation performed by the PLR depends on the bypass tunnel's Label operation performed by the PLR depends on the bypass tunnel's
characteristics. If the bypass tunnel is a single level tunnel, the characteristics. If the bypass tunnel is a single level tunnel, the
rerouting will involve swapping the incoming label of an egress- rerouting will involve swapping the incoming label of an egress-
protected tunnel to the outgoing label of the bypass tunnel. If the protected tunnel to the outgoing label of the bypass tunnel. If the
bypass tunnel is a hierarchical tunnel, the rerouting will involve bypass tunnel is a hierarchical tunnel, the rerouting will involve
swapping the incoming label of an egress-protected tunnel to a swapping the incoming label of an egress-protected tunnel to a
context label, and pushing the outgoing label of a regular bypass context label and pushing the outgoing label of a regular bypass
tunnel. If the bypass tunnel is constructed by segment routing, the tunnel. If the bypass tunnel is constructed by Segment Routing, the
rerouting will involve swapping the incoming label of an egress- rerouting will involve swapping the incoming label of an egress-
protected tunnel to a context label, and pushing the stack of SID protected tunnel to a context label and pushing the stack of SID
labels of the bypass tunnel. labels of the bypass tunnel.
5.11. Service label distribution from egress router to protector 5.11. Service Label Distribution from Egress Router to Protector
When a protector receives a rerouted MPLS service packet, it performs When a protector receives a rerouted MPLS service packet, it performs
context label switching based on the packet's service label which is context label switching based on the packet's service label, which is
assigned by the corresponding egress router. In order to achieve assigned by the corresponding egress router. In order to achieve
this, the protector MUST maintain the labels of egress-protected this, the protector MUST maintain the labels of egress-protected
services in dedicated label spaces on a per protected egress {E, P} 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. basis, i.e., one label space for each egress router that it protects.
Also, there MUST be a service label distribution protocol session Also, there MUST be a service label distribution protocol session
between each egress router and the protector. Through this protocol, between each egress router and the protector. Through this protocol,
the protector learns the label binding of each egress-protected the protector learns the label binding of each egress-protected
service. This is the same label binding that the egress router service. This is the same label binding that the egress router
advertises to the service's ingress router, which includes a context advertises to the service's ingress router, which includes a context
ID. The corresponding protection service instance on the protector ID. The corresponding protection service instance on the protector
recognizes the service, and resolves forwarding state based on its recognizes the service and resolves forwarding state based on its own
own connectivity with the service's destination. It then installs connectivity with the service's destination. It then installs the
the service label with the forwarding state in the label space of 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 egress router, which is indicated by the context ID (i.e., context
label). label).
Different service protocols may use different mechanisms for such Different service protocols may use different mechanisms for such
kind of label distribution. Specific extensions may be needed on a kind of label distribution. Specific extensions may be needed on a
per-protocol basis or per-service-type basis. The details of the per-protocol or per-service-type basis. The details of the
extensions should be specified in separate documents. As an example, extensions should be specified in separate documents. As an example,
[RFC8104] specifies the LDP extensions for pseudowire services. the LDP extensions for pseudowire services are specified in
[RFC8104].
5.12. Centralized protector mode 5.12. Centralized Protector Mode
In this framework, it is assumed that the service destination of an 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 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 MPLS network. One of them is the protected egress router, and the
other is a backup egress router. So far in this document, the other is a backup egress router. So far in this document, the focus
discussion has been focusing on the scenario where a protector and a of discussion has been on the scenario where a protector and a backup
backup egress router are co-located as one router. Therefore, the egress router are co-located as one router. Therefore, the number of
number of protectors in a network is equal to the number of backup protectors in a network is equal to the number of backup egress
egress routers. As another scenario, a network may assign a small routers. As another scenario, a network may assign a small number of
number of routers to serve as dedicated protectors, each protecting a routers to serve as dedicated protectors, each protecting a subset of
subset of egress routers. These protectors are called centralized egress routers. These protectors are called centralized protectors.
protectors.
Topologically, a centralized protector may be decoupled from all Topologically, a centralized protector may be decoupled from all
backup egress routers, or it may be co-located with one backup egress backup egress routers, or it may be co-located with one backup egress
router while decoupled from the other backup egress routers. The router while decoupled from the other backup egress routers. The
procedures in this section assume that a protector and a backup procedures in this section assume that a protector and a backup
egress router are decoupled. egress router are decoupled.
services 1, ..., N services 1, ..., N
=====================================> tunnel =====================================> tunnel
I ------ R1 ------- PLR --------------- E ---- I ------ R1 ------- PLR --------------- E ----
ingress penultimate-hop egress \ ingress penultimate hop egress \
| . (primary \ | . (primary \
| . service \ | . service \
| . instances) \ | . instances) \
| . \ | . \
| . bypass \ service | . bypass \ service
R2 . tunnel destinations R2 . tunnel destinations
| . / (CEs, sites) | . / (CEs, sites)
| . / | . /
| . / | . /
| . / | . /
| . tunnel / | . tunnel /
| =============> / | =============> /
P ---------------- E' --- P ---------------- E' ---
protector backup egress protector backup egress
(protection (backup (protection (backup
service service service service
instances) instances) instances) instances)
Figure 2 Figure 2
Like a co-located protector, a centralized protector hosts protection Like a co-located protector, a centralized protector hosts protection
service instances, receives rerouted service packets from PLRs, and service instances, receives rerouted service packets from PLRs, and
performs context label switching and/or context IP forwarding. For performs context label switching and/or context IP forwarding. For
each service, instead of sending service packets directly to the each service, instead of sending service packets directly to the
service destination, the protector MUST send them via another service destination, the protector MUST send them via another
transport tunnel to the corresponding backup service instance on a transport tunnel to the corresponding backup service instance on a
backup egress router. The backup service instance in turn forwards backup egress router. The backup service instance in turn forwards
the service packets to the service destination. Specifically, if the the service packets to the service destination. Specifically, if the
service is an MPLS service, the protector MUST swap the service label service is an MPLS service, the protector MUST swap the service label
skipping to change at page 19, line 7 skipping to change at line 855
a service label distribution protocol session between the backup a service label distribution protocol session between the backup
egress router and the protector. Through this session, the backup egress router and the protector. Through this session, the backup
egress router advertises the service label of the backup service, egress router advertises the service label of the backup service,
attached with the FEC of the egress-protected service and the context attached with the FEC of the egress-protected service and the context
ID of the protected egress {E, P}. Based on this information, the ID of the protected egress {E, P}. Based on this information, the
protector associates the egress-protected service with the backup protector associates the egress-protected service with the backup
service, resolves or establishes a transport tunnel to 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 router, and sets up forwarding state for the label of the
egress-protected service in the label space of the egress router. egress-protected service in the label space of the egress router.
The service label which the backup egress router advertises to the The service label that the backup egress router advertises to the
protector can be the same as the label which the backup egress router 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 advertises to the ingress router(s), if and only if the forwarding
state of the label does not direct service packets towards the state of the label does not direct service packets towards the
protected egress router. Otherwise, the label MUST NOT be used for protected egress router. Otherwise, the label MUST NOT be used for
egress protection, because it would create a loop for the service egress protection, because it would create a loop for the service
packets. In this case, the backup egress router MUST advertise a packets. In this case, the backup egress router MUST advertise a
unique service label for egress protection, and set up the forwarding unique service label for egress protection and set up the forwarding
state of the label to use the backup egress router's own connectivity state of the label to use the backup egress router's own connectivity
with the service destination. with the service destination.
6. Egress link protection 6. Egress Link Protection
Egress link protection is achievable through procedures similar to Egress link protection is achievable through procedures similar to
that of egress node protection. In normal situations, an egress that of egress node protection. In normal situations, an egress
router forwards service packets to a service destination based on a router forwards service packets to a service destination based on a
service label, whose forwarding state points to an egress link. In service label, whose forwarding state points to an egress link. In
egress link protection, the egress router acts as the PLR, and egress link protection, the egress router acts as the PLR and
performs local failure detection and local repair. Specifically, the performs local failure detection and local repair. Specifically, the
egress router pre-establishes an egress-protection bypass tunnel to a egress router pre-establishes an egress-protection bypass tunnel to a
protector, and sets up the bypass forwarding state for the service protector and sets up the bypass forwarding state for the service
label to point to the bypass tunnel. During local repair, the egress label to point to the bypass tunnel. During local repair, the egress
router reroutes service packets via the bypass tunnel to the router reroutes service packets via the bypass tunnel to the
protector. The protector in turn forwards the packets to the service protector. The protector in turn forwards the packets to the service
destination (in the co-located protector mode, as shown in Figure 3), destination (in the co-located protector mode, as shown in Figure 3)
or forwards the packets to a backup egress router (in the centralized or forwards the packets to a backup egress router (in the centralized
protector mode, as shown in Figure 4). protector mode, as shown in Figure 4).
service service
=====================================> tunnel =====================================> tunnel
I ------ R1 ------- R2 --------------- E ---- I ------ R1 ------- R2 --------------- E ----
ingress | ............. egress \ ingress | ............. egress \
| . PLR \ | . PLR \
| . (primary \ | . (primary \
| . service \ | . service \
| . instance) \ | . instance) \
| . \ | . \
| . bypass service | . bypass service
| . tunnel destination | . tunnel destination
| . / (CE, site) | . / (CE, site)
| . / | . /
| . / | . /
| . / | . /
| . / | . /
| ............... / | ............... /
R3 --------------- P ---- R3 --------------- P ----
protector protector
(protection (protection
service service
instance) instance)
Figure 3 Figure 3
service service
=====================================> tunnel =====================================> tunnel
I ------ R1 ------- R2 --------------- E ---- I ------ R1 ------- R2 --------------- E ----
ingress | ............. egress \ ingress | ............. egress \
| . PLR \ | . PLR \
| . (primary \ | . (primary \
| . service \ | . service \
| . instance) \ | . instance) \
| . \ | . \
| . bypass service | . bypass service
| . tunnel destination | . tunnel destination
| . / (CE, site) | . / (CE, site)
| . / | . /
| . / | . /
| . / | . /
| . tunnel / | . tunnel /
| =============> / | =============> /
R3 --------------- P ---- R3 --------------- P ----
protector backup egress protector backup egress
(protection (backup (protection (backup
service service service service
instance) instance) instance) instance)
Figure 4 Figure 4
There are two approaches to set up the bypass forwarding state on the There are two approaches for setting up the bypass forwarding state
egress router, depending on whether the egress router knows the on the egress router, depending on whether the egress router knows
service label allocated by the backup egress router. The difference the service label allocated by the backup egress router. The
is that one approach requires the protector to perform context label difference is that one approach requires the protector to perform
switching, and the other one does not. Both approaches are equally context label switching, and the other one does not. Both approaches
supported by this framework. are equally supported by this framework.
(1) The first approach applies when the egress router does not 1. The first approach applies when the egress router does not
know the service label allocated by the backup egress router. In know the service label allocated by the backup egress router.
this case, the egress router sets up the bypass forwarding state In this case, the egress router sets up the bypass forwarding
as a label push with the outgoing label of the egress-protection state as a label push with the outgoing label of the egress-
bypass tunnel. Rerouted packets will have the egress router's protection bypass tunnel. Rerouted packets will have the
service label intact. Therefore, the protector MUST perform egress router's service label intact. Therefore, the
context label switching, and the bypass tunnel MUST be destined protector MUST perform context label switching, and the bypass
for the context ID of the protected egress {E, P} and established tunnel MUST be destined for the context ID of the protected
as described in Section 5.9. This approach is consistent with egress {E, P} and established as described in Section 5.9.
egress node protection. Hence, a protector can serve in egress This approach is consistent with egress node protection.
node protection and egress link protection in a consistent manner, Hence, a protector can serve in egress node protection and
and both the co-located protector mode and the centralized egress link protection in a consistent manner, and both the
protector mode are supported (Figure 3 and Figure 4). 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 2. The second approach applies when the egress router knows the
service label allocated by the backup egress router, via a label service label allocated by the backup egress router, via a
distribution protocol session. In this case, the backup egress label distribution protocol session. In this case, the backup
router serves as the protector for egress link protection, egress router serves as the protector for egress link
regardless of the protector of egress node protection, which will protection, regardless of the protector of egress node
be the same router in the co-located protector mode but a protection, which will be the same router in the co-located
different router in the centralized protector mode. The egress protector mode but a different router in the centralized
router sets up the bypass forwarding state as a label swap from protector mode. The egress router sets up the bypass
the incoming service label to the service label of the backup forwarding state as a label swap from the incoming service
egress router (i.e., protector), followed by a push with the label to the service label of the backup egress router (i.e.,
outgoing label (or label stack) of the egress link protection protector), followed by a push with the outgoing label (or
bypass tunnel. The bypass tunnel is a regular tunnel destined for label stack) of the egress link protection bypass tunnel. The
an IP address of the protector, instead of the context ID of the bypass tunnel is a regular tunnel destined for an IP address
protected egress {E, P}. The protector simply forwards rerouted of the protector, instead of the context ID of the protected
service packets based on its own service label, rather than egress {E, P}. The protector simply forwards rerouted service
performing context label switching. In this approach, only the packets based on its own service label rather than performing
co-located protector mode is applicable. 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 Note that for a bidirectional service, the physical link of an egress
link may carry service traffic bi-directionally. Therefore, an link may carry service traffic bidirectionally. Therefore, an egress
egress link failure may simultaneously be an ingress link failure for link failure may simultaneously be an ingress link failure for the
the traffic in the opposite direction. Protection for ingress link traffic in the opposite direction. Protection for ingress link
failure SHOULD be provided by a separate mechanism, and hence is out failure SHOULD be provided by a separate mechanism and hence is out
of the scope of this document. of the scope of this document.
7. Global repair 7. Global Repair
This framework provides a fast but temporary repair for egress node This framework provides a fast but temporary repair for egress node
and egress link failures. For permanent repair, the services and egress link failures. For permanent repair, the services
affected by a failure SHOULD be moved to an alternative tunnel, or affected by a failure SHOULD be moved to an alternative tunnel, or
replaced by alternative services, which are fully functional. This replaced by alternative services, which are fully functional. This
is referred to as global repair. Possible triggers of global repair is referred to as global repair. Possible triggers of global repair
include control plane notifications of tunnel status and service include control-plane notifications of tunnel status and service
status, end-to-end OAM and fault detection at tunnel 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- level, and others. The alternative tunnel and services may be pre-
established in standby state, or dynamically established as a result established in standby state or dynamically established as a result
of the triggers or network protocol convergence. of the triggers or network protocol convergence.
8. Operational Considerations 8. Operational Considerations
When a PLR performs local repair, the router SHOULD generate an alert When a PLR performs local repair, the router SHOULD generate an alert
for the event. The alert may be logged locally for tracking for the event. The alert may be logged locally for tracking
purposes, or it may be sent to the operator at a management station. purposes, or it may be sent to the operator at a management station.
The communication channel and protocol between the PLR and the The communication channel and protocol between the PLR and the
management station may vary depending on networks, and are out of the management station may vary depending on networks and are out of the
scope of this document. scope of this document.
9. General context-based forwarding 9. General Context-Based Forwarding
So far, this document has been focusing on the cases where service So far, this document has been focusing on the cases where service
packets are MPLS or IP packets and protectors perform context label packets are MPLS or IP packets, and protectors perform context label
switching or context IP forwarding. Although this should cover most switching or context IP forwarding. Although this should cover most
common services, it is worth mentioning that the framework is also common services, it is worth mentioning that the framework is also
applicable to services or sub-modes of services where service packets applicable to services or sub-modes of services where service packets
are layer-2 packets or encapsulated in non-IP/MPLS formats. The only are Layer 2 packets or encapsulated in non-IP and non-MPLS formats.
specific in these cases is that a protector MUST perform context- The only specific in these cases is that a protector MUST perform
based forwarding based on the layer-2 table or corresponding lookup context-based forwarding based on the Layer 2 table or corresponding
table which is indicated by a context ID (i.e., context label). lookup table, which is indicated by a context ID (i.e., context
label).
10. Example: Layer-3 VPN egress protection 10. Example: Layer 3 VPN Egress Protection
This section shows an example of egress protection for layer-3 IPv4 This section shows an example of egress protection for Layer 3 IPv4
and IPv6 VPNs. and IPv6 VPNs.
---------- R1 ----------- PE2 - ---------- R1 ----------- PE2 -
/ (PLR) (PLR) \ / (PLR) (PLR) \
( ) / | | ( ) ( ) / | | ( )
( ) / | | ( ) ( ) / | | ( )
( site 1 )-- PE1 < | R3 ( site 2 ) ( site 1 )-- PE1 < | R3 ( site 2 )
( ) \ | | ( ) ( ) \ | | ( )
( ) \ | | ( ) ( ) \ | | ( )
\ | | / \ | | /
---------- R2 ----------- PE3 - ---------- R2 ----------- PE3 -
(protector) (protector)
Figure 5 Figure 5
In this example, the core network is IPv4 and MPLS. Both of the IPv4 In this example, the core network is IPv4 and MPLS. Both of the IPv4
VPN and the IPv6 VPN consist of site 1 and site 2. Site 1 is and IPv6 VPNs consist of sites 1 and 2. Site 1 is connected to PE1,
connected to PE1, and site 2 is dual-homed to PE2 and PE3. Site 1 and site 2 is dual-homed to PE2 and PE3. Site 1 includes an IPv4
includes an IPv4 subnet 203.0.113.64/26 and an IPv6 subnet subnet 203.0.113.64/26 and an IPv6 subnet 2001:db8:1:1::/64. Site 2
2001:db8:1:1::/64. Site 2 includes an IPv4 subnet 203.0.113.128/26 includes an IPv4 subnet 203.0.113.128/26 and an IPv6 subnet
and an IPv6 subnet 2001:db8:1:2::/64. PE2 is the primary PE for site 2001:db8:1:2::/64. PE2 is the primary PE for site 2, and PE3 is the
2, and PE3 is the backup PE. Each of PE1, PE2 and PE3 hosts an IPv4 backup PE. Each of PE1, PE2, and PE3 hosts an IPv4 VPN instance and
VPN instance and an IPv6 VPN instance. The PEs use BGP to exchange an IPv6 VPN instance. The PEs use BGP to exchange VPN prefixes and
VPN prefixes and VPN labels between each other. In the core network, VPN labels between each other. In the core network, R1 and R2 are
R1 and R2 are transit routers, OSPF is used as the routing protocol, transit routers, OSPF is used as the routing protocol, and RSVP-TE is
and RSVP-TE as the tunnel signaling protocol. used as the tunnel signaling protocol.
Using the framework in this document, the network assigns PE3 to be 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 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 site 1 to site 2. This is the co-located protector mode. PE2 and
PE3 form a protected egress {PE2, PE3}. A context ID 198.51.100.1 is 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 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 IPv6, the context ID would be an IPv6 address.) The IPv4 and IPv6
VPN instances on PE3 serve as protection instances for the VPN instances on PE3 serve as protection instances for the
corresponding VPN instances on PE2. On PE3, a context label 100 is 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 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 represent PE2's label space. PE3 installs label 100 in its MPLS
forwarding table, with nexthop pointing to the label table pe2.mpls. forwarding table, with the next hop pointing to the label table
PE2 and PE3 are coordinated to use the proxy mode to advertise the pe2.mpls. PE2 and PE3 are coordinated to use the proxy mode to
context ID in the routing domain and the TE domain. advertise the context ID in the routing domain and the TE domain.
PE2 uses per-VRF label allocation mode for both of its IPv4 and IPv6 PE2 uses the label allocation mode per Virtual Routing and Forwarding
VPN instances. It assigns label 9000 to the IPv4 VRF, and label 9001 (VRF) for both of its IPv4 and IPv6 VPN instances. It assigns label
to the IPv6 VRF. For the IPv4 prefix 203.0.113.128/26 in site 2, PE2 9000 to the IPv4 VRF, and label 9001 to the IPv6 VRF. For the IPv4
advertises it with label 9000 and NEXT_HOP 198.51.100.1 to PE1 and prefix 203.0.113.128/26 in site 2, PE2 advertises it with label 9000
PE3 via BGP. Likewise, for the IPv6 prefix 2001:db8:1:2::/64 in site and NEXT_HOP 198.51.100.1 to PE1 and PE3 via BGP. Likewise, for the
2, PE2 advertises it with label 9001 and NEXT_HOP 198.51.100.1 to PE1 IPv6 prefix 2001:db8:1:2::/64 in site 2, PE2 advertises it with label
and PE3 via BGP. 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 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 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 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 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, 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 PE3 advertises it with label 10001 and NEXT_HOP as itself to PE1 and
PE2 via BGP. PE2 via BGP.
Upon receipt of the above BGP advertisements from PE2, PE1 uses the Upon receipt of the above BGP advertisements from PE2, PE1 uses the
context ID 198.51.100.1 as destination to compute a path for an 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 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 then uses RSVP to signal the tunnel, with the context ID 198.51.100.1
as destination, and with the "node protection desired" flag set in as the destination, with the "node protection desired" flag set in
the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes the SESSION_ATTRIBUTE of the RSVP Path message. Once the tunnel
up, PE1 maps the VPN prefixes 203.0.113.128/26 and 2001:db8:1:2::/64 comes up, PE1 maps the VPN prefixes 203.0.113.128/26 and
to the tunnel, and installs a route for each prefix in the 2001:db8:1:2::/64 to the tunnel and installs a route for each prefix
corresponding IPv4 or IPv6 VRF. The nexthop of the route 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 203.0.113.128/26 is a push of the VPN label 9000, followed by a push
of the outgoing label of the egress-protected tunnel. The nexthop of of the outgoing label of the egress-protected tunnel. The next hop
the route 2001:db8:1:2::/64 is a push of the VPN label 9001, followed 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. by a push of the outgoing label of the egress-protected tunnel.
Upon receipt of the above BGP advertisements from PE2, PE3 recognizes 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 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 route for label 9000 and a route for label 9001 in the label table
pe2.mpls. PE3 sets the nexthop of the route 9000 to the IPv4 pe2.mpls. PE3 sets the next hop of route 9000 to the IPv4 protection
protection VRF, and the nexthop of the route 9001 to the IPv6 VRF and the next hop of route 9001 to the IPv6 protection VRF. The
protection VRF. The IPv4 protection VRF contains the routes to the IPv4 protection VRF contains the routes to the IPv4 prefixes in site
IPv4 prefixes in site 2. The IPv6 protection VRF contains the routes 2. The IPv6 protection VRF contains the routes to the IPv6 prefixes
to the IPv6 prefixes in site 2. The nexthops of these routes must be in site 2. The next hops of these routes must be based on PE3's
based on PE3's connectivity with site 2, even if the connectivity may connectivity with site 2, even if the connectivity may not have the
not have the best metrics (e.g., MED, local preference, etc.) to be best metrics (e.g., Multi-Exit Discriminator (MED), local preference,
used in PE3's own VRF. The nexthops must not use any path traversing etc.) to be used in PE3's own VRF. The next hops must not use any
PE2. Note that the protection VRFs are a logical concept, and they path traversing PE2. Note that the protection VRFs are a logical
may simply be PE3's own VRFs if they satisfies the requirement. concept, and they may simply be PE3's own VRFs if they satisfy the
requirement.
10.1. Egress node protection 10.1. Egress Node Protection
R1, i.e., the penultimate-hop router of the egress-protected tunnel, R1, i.e., the penultimate hop router of the egress-protected tunnel,
serves as the PLR for egress node protection. Based on the "node serves as the PLR for egress node protection. Based on the "node
protection desired" flag and the destination address (i.e., context protection desired" flag and the destination address (i.e., context
ID 198.51.100.1) of the tunnel, R1 computes a bypass path to 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 198.51.100.1 while avoiding PE2. The resultant bypass path is
R1->R2->PE3. R1 then signals the path (i.e., egress-protection R1->R2->PE3. R1 then signals the path (i.e., egress-protection
bypass tunnel), with 198.51.100.1 as destination. bypass tunnel), with 198.51.100.1 as the destination.
Upon receipt of an RSVP Path message of the egress-protection bypass Upon receipt of an RSVP Path message of the egress-protection bypass
tunnel, PE3 recognizes the context ID 198.51.100.1 as the tunnel, PE3 recognizes the context ID 198.51.100.1 as the destination
destination, and responds with the context label 100 in an RSVP Resv and responds with context label 100 in an RSVP Resv message.
message.
After the egress-protection bypass tunnel comes up, R1 installs a After the egress-protection bypass tunnel comes up, R1 installs a
bypass nexthop for the egress-protected tunnel. The bypass nexthop bypass next hop for the egress-protected tunnel. The bypass next hop
is a label swap from the incoming label of the egress-protected is a label swap from the incoming label of the egress-protected
tunnel to the outgoing label of the egress-protection bypass tunnel. tunnel to the outgoing label of the egress-protection bypass tunnel.
When R1 detects a failure of PE2, it will invoke the above bypass When R1 detects a failure of PE2, it will invoke the above bypass
nexthop to reroute VPN packets. Each IPv4 VPN packet will have the 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 label of the bypass tunnel as outer label, and the IPv4 VPN label
9000 as inner label. Each IPv6 VPN packets will have the label of 9000 as inner label. Each IPv6 VPN packet will have the label of the
the bypass tunnel as outer label, and the IPv6 VPN label 9001 as 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 inner label. When the packets arrive at PE3, they will have the
context label 100 as outer label, and the VPN label 9000 or 9001 as context label 100 as the outer label and the VPN label 9000 or 9001
inner label. The context label will first be popped, and then the as the inner label. The context label will first be popped, and then
VPN label will be looked up in the label table pe2.mpls. The lookup the VPN label will be looked up in the label table pe2.mpls. The
will cause the VPN label to be popped, and the IPv4 and IPv6 packets lookup will cause the VPN label to be popped and the IPv4 and IPv6
to be forwarded to site 2 based on the IPv4 and IPv6 protection VRFs, packets to be forwarded to site 2 based on the IPv4 and IPv6
respectively. protection VRFs, respectively.
10.2. Egress link protection 10.2. Egress Link Protection
PE2 serves as the PLR for egress link protection. It has already 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 learned PE3's IPv4 VPN label 10000 and IPv6 VPN label 10001. Hence,
it uses the approach (2) described in Section 6 to set up bypass it uses approach (2) as described in Section 6 to set up the bypass
forwarding state. It signals an egress-protection bypass tunnel to forwarding state. It signals an egress-protection bypass tunnel to
PE3, by using the path PE2->R3->PE3, and PE3's IP address as 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 destination. After the bypass tunnel comes up, PE2 installs a bypass
nexthop for the IPv4 VPN label 9000, and a bypass nexthop for the next hop for the IPv4 VPN label 9000 and a bypass next hop for the
IPv6 VPN label 9001. For label 9000, the bypass nexthop is a label 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 swap to label 10000, followed by a label push with the outgoing label
of the bypass tunnel. For label 9001, the bypass nexthop is a label 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 swap to label 10001, followed by a label push with the outgoing label
of the bypass tunnel. of the bypass tunnel.
When PE2 detects a failure of the egress link, it will invoke the When PE2 detects a failure of the egress link, it will invoke the
above bypass nexthop to reroute VPN packets. Each IPv4 VPN packet above bypass next hop to reroute VPN packets. Each IPv4 VPN packet
will have the label of the bypass tunnel as outer label, and label will have the label of the bypass tunnel as the outer label and label
10000 as inner label. Each IPv6 VPN packet will have the label of 10000 as the inner label. Each IPv6 VPN packet will have the label
the bypass tunnel as outer label, and label 10001 as inner label. of the bypass tunnel as the outer label and label 10001 as the inner
When the packets arrive at PE3, the VPN label 10000 or 10001 will be label. When the packets arrive at PE3, the VPN label 10000 or 10001
popped, and the exposed IPv4 and IPv6 packets will be forwarded based will be popped, and the exposed IPv4 and IPv6 packets will be
on PE3's IPv4 and IPv6 VRFs, respectively. forwarded based on PE3's IPv4 and IPv6 VRFs, respectively.
10.3. Global repair 10.3. Global Repair
Eventually, global repair will take effect, as control plane Eventually, global repair will take effect, as control-plane
protocols converge on the new topology. PE1 will choose PE3 as a new 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 entrance to site 2. Before that happens, the VPN traffic has been
protected by the above local repair. protected by the above local repair.
10.4. Other modes of VPN label allocation 10.4. Other Modes of VPN Label Allocation
It is also possible that PE2 may use per-route or per-interface VPN 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 allocation mode. In either case, PE3 will have multiple VPN
label routes in the pe2.mpls table, corresponding to the VPN labels label routes in the pe2.mpls table, corresponding to the VPN labels
advertised by PE2. PE3 forwards rerouted packets by popping a VPN advertised by PE2. PE3 forwards rerouted packets by popping a VPN
label and performing an IP lookup in the corresponding protection label and performing an IP lookup in the corresponding protection
VRF. PE3's forwarding behavior is consistent with the above case VRF. PE3's forwarding behavior is consistent with the above case
where PE2 uses per-VRF VPN label allocation mode. PE3 does not need 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 to know PE2's VPN label allocation mode or construct a specific next
nexthop for each VPN label route in the pe2.mpls table. hop for each VPN label route in the pe2.mpls table.
11. IANA Considerations 11. IANA Considerations
This document has no request for new IANA allocation. This document has no IANA actions.
12. Security Considerations 12. Security Considerations
The framework in this document involves rerouting traffic around an The framework in this document involves rerouting traffic around an
egress node or link failure, via a bypass path from a PLR to a egress node or link failure, via a bypass path from a PLR to a
protector, and ultimately to a backup egress router. The forwarding protector, and ultimately to a backup egress router. The forwarding
performed by the routers in the data plane is anticipated, as part of performed by the routers in the data plane is anticipated, as part of
the planning of egress protection. the planning of egress protection.
Control plane protocols MAY be used to facilitate the provisioning of Control-plane protocols MAY be used to facilitate the provisioning of
the egress protection on the routers. In particular, the framework the egress protection on the routers. In particular, the framework
requires a service label distribution protocol between an egress requires a service label distribution protocol between an egress
router and a protector over a secure session. The security router and a protector over a secure session. The security
properties of this provisioning and label distribution depend properties of this provisioning and label distribution depend
entirely on the underlying protocol chosen to implement these entirely on the underlying protocol chosen to implement these
activities . Their associated security considerations apply. This activities. Their associated security considerations apply. This
framework introduces no new security requirements or guarantees framework introduces no new security requirements or guarantees
relative to these activities. relative to these activities.
Also, the PLR, protector, and backup egress router are located close Also, the PLR, protector, and backup egress router are located close
to the protected egress router, and normally in the same to the protected egress router, which is normally in the same
administrative domain. If they are not in the same administrative administrative domain. If they are not in the same administrative
domain, a certain level of trust MUST be established between them in domain, a certain level of trust MUST be established between them in
order for the protocols to run securely across the domain boundary. order for the protocols to run securely across the domain boundary.
The basis of this trust is the security model of the protocols (as The basis of this trust is the security model of the protocols (as
described above), and further security considerations for inter- described above), and further security considerations for inter-
domain scenarios should be addressed by the protocols as a common domain scenarios should be addressed by the protocols as a common
requirement. requirement.
Security attacks may sometimes come from a customer domain. Such Security attacks may sometimes come from a customer domain. Such
kind of attacks are not introduced by the framework in this document, attacks are not introduced by the framework in this document and may
and may occur regardless of the existence of egress protection. In occur regardless of the existence of egress protection. In one
one possible case, the egress link between an egress router and a CE possible case, the egress link between an egress router and a CE
could become a point of attack. An attacker that gains control of could become a point of attack. An attacker that gains control of
the CE might use it to simulate link failures and trigger constant the CE might use it to simulate link failures and trigger constant
and cascading activities in the network. If egress link protection and cascading activities in the network. If egress link protection
is in place, egress link protection activities may also be triggered. is in place, egress link protection activities may also be triggered.
As a general solution to defeat the attack, a damping mechanism As a general solution to defeat the attack, a damping mechanism
SHOULD be used by the egress router to promptly suppress the services SHOULD be used by the egress router to promptly suppress the services
associated with the link or CE. The egress router would stop associated with the link or CE. The egress router would stop
advertising the services, essentially detaching them from the network advertising the services, essentially detaching them from the network
and eliminating the effect of the simulated link failures. and eliminating the effect of the simulated link failures.
From the above perspectives, this framework does not introduce any From the above perspectives, this framework does not introduce any
new security threat to networks. new security threat to networks.
13. Acknowledgements 13. References
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.
14. References
14.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[SR-ISIS] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., [RFC8667] Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Gredler, H., and B. Decraene, "IS-IS Extensions for
Extensions for Segment Routing", draft-ietf-isis-segment- Segment Routing", RFC 8667, DOI 10.17487/RFC8667, December
routing-extensions (work in progress), 2017. 2019, <https://www.rfc-editor.org/info/rfc8667>.
14.2. Informative References 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 [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005, DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>. <https://www.rfc-editor.org/info/rfc4090>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286, IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008, DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>. <https://www.rfc-editor.org/info/rfc5286>.
skipping to change at page 29, line 15 skipping to change at line 1291
[RFC8104] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, [RFC8104] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang,
"Pseudowire (PW) Endpoint Fast Failure Protection", "Pseudowire (PW) Endpoint Fast Failure Protection",
RFC 8104, DOI 10.17487/RFC8104, March 2017, RFC 8104, DOI 10.17487/RFC8104, March 2017,
<https://www.rfc-editor.org/info/rfc8104>. <https://www.rfc-editor.org/info/rfc8104>.
[RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang,
"Extensions to RSVP-TE for Label Switched Path (LSP) "Extensions to RSVP-TE for Label Switched Path (LSP)
Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June
2018, <https://www.rfc-editor.org/info/rfc8400>. 2018, <https://www.rfc-editor.org/info/rfc8400>.
[BGP-PIC] Bashandy, P., Filsfils, C., and P. Mohapatra, "BGP Prefix Acknowledgements
Independent Convergence", draft-ietf-rtgwg-bgp-pic-09.txt
(work in progress), 2017. 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 Authors' Addresses
Yimin Shen Yimin Shen
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA United States of America
Phone: +1 9785890722 Phone: +1 978 589 0722
Email: yshen@juniper.net Email: yshen@juniper.net
Minto Jeyananth Minto Jeyananth
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale, CA 94089 Sunnyvale, CA 94089
USA United States of America
Phone: +1 4089367563 Phone: +1 408 936 7563
Email: minto@juniper.net Email: minto@juniper.net
Bruno Decraene Bruno Decraene
Orange Orange
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Hannes Gredler Hannes Gredler
RtBrick Inc RtBrick Inc.
Email: hannes@rtbrick.com Email: hannes@rtbrick.com
Carsten Michel Carsten Michel
Deutsche Telekom Deutsche Telekom
Email: c.michel@telekom.de Email: c.michel@telekom.de
Huaimo Chen Huaimo Chen
Huawei Technologies Co., Ltd. Futurewei
Boston, MA
United States of America
Email: huaimo.chen@huawei.com Email: Huaimo.chen@futurewei.com
 End of changes. 210 change blocks. 
571 lines changed or deleted 595 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/