draft-ietf-mpls-egress-protection-framework-05.txt   draft-ietf-mpls-egress-protection-framework-06.txt 
Internet Engineering Task Force Yimin Shen Internet Engineering Task Force Yimin Shen
Internet-Draft Minto Jeyananth Internet-Draft Minto Jeyananth
Intended status: Standards Track Juniper Networks Intended status: Standards Track Juniper Networks
Expires: November 29, 2019 Bruno Decraene Expires: December 29, 2019 Bruno Decraene
Orange Orange
Hannes Gredler Hannes Gredler
RtBrick Inc RtBrick Inc
Carsten Michel Carsten Michel
Deutsche Telekom Deutsche Telekom
Huaimo Chen Huaimo Chen
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
May 28, 2019 June 27, 2019
MPLS Egress Protection Framework MPLS Egress Protection Framework
draft-ietf-mpls-egress-protection-framework-05 draft-ietf-mpls-egress-protection-framework-06
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 a PLR to a protector. It describes the behaviors of these from a PLR to a protector. It describes the behaviors of these
routers in handling an egress failure, including local repair on the routers in handling an egress failure, including local repair on the
PLR, and context based forwarding on the protector. The framework PLR, and context-based forwarding on the protector. The framework
can be used to develop egress protection mechanisms to reduce traffic can be used to develop egress protection mechanisms to reduce traffic
loss before global repair reacts to an egress failure and control loss before global repair reacts to an egress failure and control
plane protocols converge on the topology changes due to the egress plane protocols 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 29, 2019. This Internet-Draft will expire on December 29, 2019.
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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 5 2. Specification of Requirements . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Egress node protection . . . . . . . . . . . . . . . . . . . 8 5. Egress node protection . . . . . . . . . . . . . . . . . . . 8
5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8 5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8
5.2. Egress node failure and detection . . . . . . . . . . . . 8 5.2. Egress node failure and detection . . . . . . . . . . . . 8
5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9 5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9
5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 10 5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 10
5.5. Egress-protected tunnel and service . . . . . . . . . . . 10 5.5. Egress-protected tunnel and service . . . . . . . . . . . 11
5.6. Egress-protection bypass tunnel . . . . . . . . . . . . . 11 5.6. Egress-protection bypass tunnel . . . . . . . . . . . . . 11
5.7. Context ID, context label, and context based forwarding . 11 5.7. Context ID, context label, and context-based forwarding . 12
5.8. Advertisement and path resolution for context ID . . . . 13 5.8. Advertisement and path resolution for context ID . . . . 13
5.9. Egress-protection bypass tunnel establishment . . . . . . 15 5.9. Egress-protection bypass tunnel establishment . . . . . . 15
5.10. Local repair on PLR . . . . . . . . . . . . . . . . . . . 15 5.10. Local repair on PLR . . . . . . . . . . . . . . . . . . . 16
5.11. Service label distribution from egress router to 5.11. Service label distribution from egress router to
protector . . . . . . . . . . . . . . . . . . . . . . . . 16 protector . . . . . . . . . . . . . . . . . . . . . . . . 16
5.12. Centralized protector mode . . . . . . . . . . . . . . . 17 5.12. Centralized protector mode . . . . . . . . . . . . . . . 17
6. Egress link protection . . . . . . . . . . . . . . . . . . . 18 6. Egress link protection . . . . . . . . . . . . . . . . . . . 19
7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 22
8. General context-based forwarding . . . . . . . . . . . . . . 21 8. Operational Considerations . . . . . . . . . . . . . . . . . 22
9. Example: Layer-3 VPN egress protection . . . . . . . . . . . 22 9. General context-based forwarding . . . . . . . . . . . . . . 23
9.1. Egress node protection . . . . . . . . . . . . . . . . . 23 10. Example: Layer-3 VPN egress protection . . . . . . . . . . . 23
9.2. Egress link protection . . . . . . . . . . . . . . . . . 24 10.1. Egress node protection . . . . . . . . . . . . . . . . . 24
9.3. Global repair . . . . . . . . . . . . . . . . . . . . . . 24 10.2. Egress link protection . . . . . . . . . . . . . . . . . 25
9.4. Other modes of VPN label allocation . . . . . . . . . . . 24 10.3. Global repair . . . . . . . . . . . . . . . . . . . . . 25
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 10.4. Other modes of VPN label allocation . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
13.1. Normative References . . . . . . . . . . . . . . . . . . 26 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.2. Informative References . . . . . . . . . . . . . . . . . 26 14.1. Normative References . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 14.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
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., CoS, QoS) of these
services. The egress router of the tunnel hosts the service services. The egress router of the tunnel hosts the service
instances of the services. An MPLS service instance forwards service instances of the services. An MPLS service instance forwards service
packets via an egress link to the service destination, based on a packets via an egress link to the service destination, based on a
service label. An IP service instance does the same based on a service label. An IP service instance does the same based on a
service IP address. The egress link is often called a PE-CE service IP address. The egress link is often called a PE-CE
(provider edge - customer edge) link or attachment circuit (AC). (provider edge - customer edge) link or attachment circuit (AC).
Today, local repair based fast reroute mechanisms [RFC4090], Today, local-repair-based fast reroute mechanisms ([RFC4090],
[RFC5286], [RFC7490], [RFC7812] have been widely deployed to protect [RFC5286], [RFC7490], and [RFC7812]) have been widely deployed to
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 (aka. PLR, i.e. point of local repair) pre-establishes a failure, a.k.a. PLR (point of local repair), pre-establishes a
bypass tunnel to the router downstream of the failure (aka. MP, i.e. bypass tunnel to the router downstream of the failure, a.k.a. MP
merge point), pre-installs the forwarding state of the bypass tunnel (merge point), pre-installs the forwarding state of the bypass tunnel
in the data plane, and uses a rapid mechanism (e.g. link layer OAM, in the data plane, and uses a rapid mechanism (e.g., link layer OAM,
BFD, and others) to locally detect the failure in the data plane. BFD, and others) to locally detect the failure in the data plane.
When the failure occurs, the PLR reroutes traffic through the bypass When the failure occurs, the PLR reroutes traffic through the bypass
tunnel to the MP, allowing the traffic to continue to flow to the tunnel to the MP, allowing the traffic to continue to flow to the
tunnel's egress router. 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,
skipping to change at page 4, line 25 skipping to change at page 4, line 28
router which hosts a "backup service instance". In the "co-located" router which 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, and 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 P2P (point-to-
point) tunnels. However, it is equally applicable to P2MP (point-to- point) tunnels. However, it is equally applicable to P2MP (point-to-
multipoint), MP2P (multipoint-to-point) and MP2MP (multipoint-to- multipoint), MP2P (multipoint-to-point), and MP2MP (multipoint-to-
multipoint) tunnels, if the sub-LSPs of these tunnels can be viewed multipoint) tunnels, if the sub-LSPs of these tunnels can be viewed
as P2P tunnels. 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 the service label to be 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 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 VPLS and EVPN. These cases
are left for future study. Services which use upstream-assigned are left for future study. Services which use upstream-assigned
service labels are also out of scope of this document and left for service labels are also out of scope of this document and left for
future study. 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 transport tunnels and bypass tunnels to be
established by using the generic procedures provided by the 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 which 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 leaves the specific details to separate documents.
skipping to change at page 5, line 39 skipping to change at page 5, line 41
[RFC8174]. [RFC8174].
3. Terminology 3. Terminology
Egress router - A router at the egress endpoint of a tunnel. It Egress router - A router at the egress endpoint of a tunnel. It
hosts service instances for all the services carried by the tunnel, hosts service instances for all the services carried by the tunnel,
and has connectivity with the destinations of the services. 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 - A failure of the egress link (e.g., PE-CE link,
attachment circuit) of a service. 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 - A tunnel whose egress router is protected
by a mechanism according to this framework. The egress router is by a mechanism according to this framework. The egress router is
hence called a protected egress router. hence called a protected egress router.
Egress-protected service - An IP or MPLS service which is carried by Egress-protected service - An IP or MPLS service which is carried by
an egress-protected tunnel, and hence protected by a mechanism an egress-protected tunnel, and hence protected by a mechanism
skipping to change at page 7, line 37 skipping to change at page 7, line 40
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 o 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 egress, and
be transparent to ingress routers and other transit routers. be transparent to ingress routers and other transit routers.
o In egress node protection, for scalability and performance o 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 per-service-destination or per-transport-tunnel basis, rather than on a per-service-
per-service-label basis. It SHOULD also support bypass tunnel destination or per-service-label basis. It SHOULD also support
sharing between transport tunnels. bypass tunnel sharing between transport tunnels.
o A PLR MUST be able to use its local visibility or information of o A PLR MUST be able to use its local visibility or information of
routing or TE topology to compute or resolve a path for a bypass 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 o 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 service label(s) assigned
by an egress router. It MUST be able to perform context IP by an egress router. It MUST be able to perform context IP
forwarding for rerouted IP service packets, in the public or 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.
skipping to change at page 8, line 46 skipping to change at page 8, line 49
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 a mechanism based on a collective failure of all the links to that or a mechanism based on a collective failure of all the links to that
node. The mechanisms SHOULD be reasonably fast, i.e. faster than node. The mechanisms SHOULD 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 in this protection. This document provides the following guidelines in this
regard. regard.
o If the PLR has a reasonably fast mechanism to detect and o If the PLR has a reasonably fast mechanism to detect and
differentiate a link failure (of the link between the PLR and the differentiate a link failure (of the link between the PLR and the
egress node) and an egress node failure, it SHOULD set up both egress node) and an egress node failure, it SHOULD set up both
skipping to change at page 9, line 19 skipping to change at page 9, line 21
protection. This document provides the following guidelines in this protection. This document provides the following guidelines in this
regard. regard.
o If the PLR has a reasonably fast mechanism to detect and o If the PLR has a reasonably fast mechanism to detect and
differentiate a link failure (of the link between the PLR and the differentiate a link failure (of the link between the PLR and the
egress node) and an egress node failure, it SHOULD set up both egress node) and an egress node failure, it SHOULD set up both
link protection and egress node protection, and trigger one and link protection and egress node protection, and trigger one and
only one protection upon a corresponding failure. only one protection upon a corresponding failure.
o If the PLR has a fast mechanism to detect a link failure and an o If the PLR has a fast mechanism to detect a link failure and an
egress node failure, but cannot distinguish them; Or, if the PLR egress node failure, but 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
skipping to change at page 10, line 7 skipping to change at page 10, line 10
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 though 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. The protector in turn 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 serves as the protector. Each protection service egress router which serves as the protector. Each protection service
instance on the protector relies on such connectivity to set up instance on the protector relies on such connectivity to set up
skipping to change at page 10, line 33 skipping to change at page 10, line 36
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 tailend 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, Two routers X and Y MAY be protectors for each other. In this case,
they form two distinct protected egresses {X, Y} and {Y, X}. 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 case,
they share the common egress router and protector, but MAY or MAY NOT they share the common egress router and protector, but MAY or MAY not
share a common ingress router, or a common PLR (i.e. penultimate-hop share a common ingress router, or a common PLR (i.e., penultimate-hop
router). 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 tailend.
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. The egress router E hosts the
primary instance of the service, and the protector P hosts the primary instance of the service, and the protector P hosts the
protection instance of the service. protection 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 MAY or MAY
NOT be carried by a common egress-protected tunnel or a common 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 "context ID" for protected egress {E, P},
as described in (Section 5.7). as described in (Section 5.7).
5.6. Egress-protection bypass tunnel 5.6. Egress-protection bypass tunnel
skipping to change at page 11, line 47 skipping to change at page 12, line 5
egress {E, P}. Due to its bypass nature, it MUST be established with egress {E, P}. Due to its bypass nature, it MUST be established with
P as the physical tailend and E as the node to avoid. The bypass P as the physical tailend and E as the node to avoid. The bypass
tunnel MUST have the property that it MUST NOT be affected by the tunnel MUST have the property that it MUST NOT be affected by the
topology change caused by an egress node failure. topology change caused by an egress node failure.
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/v6 address is assigned to a In this framework, a globally unique IPv4/v6 address is assigned to a
protected egress {E, P} as the identifier of the protected egress {E, protected egress {E, P} as the identifier of the protected egress {E,
P}. It is called a "context ID" due to its specific usage in context P}. It is called a "context ID" due to its specific usage in context
label switching and context IP forwarding on the protector. It is an label switching and context IP forwarding on the protector. It is an
IP address that is logically owned by both the egress router and the IP address that is logically owned by both the egress router and the
protector. For the egress router, it indicates the protector. For protector. For the egress router, it indicates the protector. For
the protector, it indicates the egress router, particularly the the protector, it indicates the egress router, particularly the
egress router's forwarding context. For other routers in the egress router's forwarding context. For other routers in the
network, it is an address reachable via both the egress router and network, it is an address reachable via both the egress router and
skipping to change at page 12, line 36 skipping to change at page 12, line 42
o The ingress router uses the service's context ID as the o 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 o The context ID is conveyed to the PLR by the signaling protocol of
the egress-protected tunnel, or learned by the PLR via an IGP 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 ISIS) 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 destination
to establish or resolve an egress-protection bypass tunnel to P to establish or resolve an egress-protection bypass tunnel to P
while avoiding E. while avoiding E.
o P maintains a dedicated label space and a dedicated IP address o P maintains a dedicated label space and a dedicated IP address
space for E. They are referred to as "E's label space" and "E's 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 o 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
skipping to change at page 13, line 22 skipping to change at page 13, line 29
"context label". "context label".
o The PLR MAY establish the egress-protection bypass tunnel to P in o 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 destination,
and P binds the context label to the bypass tunnel. If the bypass and P binds the context label to the bypass tunnel. If the bypass
tunnel is established by LDP, P advertises the context label for tunnel is established by LDP, P advertises the context label for
the context ID as an IP prefix FEC. If the bypass tunnel is the context ID as an IP prefix FEC. If the bypass tunnel is
established by the PLR in a hierarchical manner, the PLR treats established by the PLR in a hierarchical manner, the PLR treats
the context label as a one-hop LSP over a regular bypass tunnel to the context label as a one-hop LSP over a regular bypass tunnel to
P (e.g. a bypass tunnel to P's loopback IP address). If the P (e.g., a bypass tunnel to P's loopback IP address). If the
bypass tunnel is constructed by using segment routing, the bypass bypass tunnel is constructed by using segment routing, the bypass
tunnel is represented by a stack of SID labels with the context tunnel is represented by a stack of SID labels with the context
label as the inner-most SID label (Section 5.9). In any case, the label as the inner-most SID label (Section 5.9). In any case, the
bypass tunnel is a UHP tunnel whose incoming label on P is the bypass tunnel is a UHP tunnel whose incoming label on P is the
context label. context label.
o During local repair, all the service packets received by P on the o During local repair, all the service packets received by P on the
bypass tunnel have the context label as the top label. P first 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 further
looks up the service label in E's label space indicated by the looks up the service label in E's label space indicated by the
skipping to change at page 14, line 8 skipping to change at page 14, line 13
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 tailend, and all egress-protection bypass tunnels MUST
have P as tailend while avoiding E. have P as tailend 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 P,
but not the PLR, to have the knowledge of the egress protection but not the PLR, to have the knowledge of the egress protection
schema. E and P advertise the context ID as a virtual proxy node schema. E and P advertise the context ID as a virtual proxy node
(i.e. a logical node) connected to the two routers, with the link (i.e., a logical node) connected to the two routers, with the
between the proxy node and E having more preferable IGP and TE link between the proxy node and E having more preferable IGP and
metrics than the link between the proxy node and P. Therefore, TE metrics than the link between the proxy node and P.
all egress-protected tunnels destined for the context ID will Therefore, all egress-protected tunnels destined for the context
automatically follow the IGP or TE paths to E. Each PLR will no ID will automatically follow the IGP or TE paths to E. Each PLR
longer view itself as a penultimate-hop, but rather two hops away will no longer view itself as a penultimate-hop, but rather two
from the proxy node, via E. The PLR will be able to find a hops away from the proxy node, via E. The PLR will be able to
bypass path via P to the proxy node, while the bypass tunnel is find a bypass path via P to the proxy node, while the bypass
actually be terminated by P. tunnel is actually be 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 IP
address. P advertises the context ID and the context label by address. P advertises the context ID and the context label by
using a "context ID label binding" advertisement. The using a "context ID label binding" advertisement. The
advertisement MUST be understood by the PLR. In both routing advertisement MUST be understood by the PLR. In both routing
domain and TE domain, the context ID is only reachable via E. domain and TE domain, the context ID is only reachable via E.
Therefore, all egress-protected tunnels destined for the context Therefore, all egress-protected tunnels destined for the context
ID will have E as tailend. Based on the "context ID label ID will have E as tailend. Based on the "context ID label
binding" advertisement, the PLR can establish an egress- binding" advertisement, the PLR can establish an egress-
protection bypass tunnel in several manners (Section 5.9). The protection bypass tunnel in several manners (Section 5.9). The
"context ID label binding" advertisement is defined as IGP "context ID label binding" advertisement is defined as IGP
mirroring context segment in [RFC8402], [SR-OSPF] and [SR-ISIS]. mirroring context segment in [RFC8402], [SR-OSPF] and [SR-ISIS].
These IGP extensions are generic in nature, and hence can be used These IGP extensions are generic in nature, and hence can be used
for egress protection purposes. for egress protection purposes.
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 any-cast IP network, essentially modelling 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 need
to have the knowledge of the egress protection schema. The to have the knowledge of the egress protection schema. The
correctness of the egress-protected tunnels and the bypass correctness of the egress-protected tunnels and the bypass
tunnels relies on the path computations for the any-cast 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 in 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
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-AS tunnel, its associated context ID MUST be propagated by IGP
or BGP from the original area/AS to the areas/AS' the ingress router. or BGP from the original area or AS to the area or AS of the ingress
The propagation process of the context ID SHOULD be the same as that router. The propagation process of the context ID SHOULD be the same
of an IP address in an inter-area/AS environment. 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 to set up
a bypass tunnel to a context ID while avoiding the next-hop router a bypass tunnel to a context ID while avoiding the next-hop router
(i.e. egress router). This is achievable by using a constraint-based (i.e., egress router). This is achievable by using a constraint-
computation algorithm similar to those commonly used for traffic based computation algorithm similar to those commonly used for
engineering paths and loop-free alternate (LFA) paths. Since the traffic engineering paths and loop-free alternate (LFA) paths. Since
context ID is advertised in the routing domain and the TE domain by the context ID is advertised in the routing domain and the TE domain
IGP according to Section 5.8, the PLR is able to resolve or establish by IGP according to Section 5.8, the PLR is able to resolve or
such a bypass path with the protector as tailend. In the case of establish such a bypass path with the protector as tailend. In the
proxy mode, the PLR MAY do so in the same manner as transit node case of proxy mode, the PLR MAY do so in the same manner as transit
protection. 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), with
the context ID as destination. The protector binds the context label the context ID as destination. The protector binds the context label
to the bypass tunnel. 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 ID as
an IP prefix FEC, with the context label bound to it. 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 the
knowledge of the context ID, context label, and protector (i.e. the knowledge of the context ID, context label, and protector (i.e., the
advertiser). The PLR can then establish the bypass tunnel in a advertiser). The PLR can then establish the bypass tunnel in a
hierarchical manner, with the context label as a one-hop LSP over a hierarchical manner, with the context label as a one-hop LSP over a
regular bypass tunnel to the protector's IP address (e.g. loopback regular bypass tunnel to the protector's IP address (e.g., loopback
address). This regular bypass tunnel MAY be established by RSVP, address). This regular bypass tunnel MAY be established by RSVP,
LDP, segment routing, or another protocol. 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 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 connectivity with the service's destination. It then installs own connectivity with the service's destination. It then installs
the service label with the forwarding state in the label space of the 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 basis 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. [RFC8104] specifies the LDP extensions for pseudowire services.
5.12. Centralized protector mode 5.12. Centralized protector mode
skipping to change at page 18, line 12 skipping to change at page 18, line 37
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, in 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
in each received service packet to the label of the backup service in each received service packet to the label of the backup service
advertised by the backup egress router, and then push the label (or advertised by the backup egress router, and then push the label (or
label stack) of the transport tunnel. label stack) of the transport tunnel.
In order for a centralized protector to map an egress-protected MPLS In order for a centralized protector to map an egress-protected MPLS
service to a service hosted on a backup egress router, there MUST be service to a service hosted on a backup egress router, there MUST be
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,
skipping to change at page 19, line 5 skipping to change at page 19, line 31
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) \
skipping to change at page 20, line 50 skipping to change at page 21, line 50
this case, the egress router sets up the bypass forwarding state this case, the egress router sets up the bypass forwarding state
as a label push with the outgoing label of the egress-protection as a label push with the outgoing label of the egress-protection
bypass tunnel. Rerouted packets will have the egress router's bypass tunnel. Rerouted packets will have the egress router's
service label intact. Therefore, the protector MUST perform service label intact. Therefore, the protector MUST perform
context label switching, and the bypass tunnel MUST be destined context label switching, and the bypass tunnel MUST be destined
for the context ID of the protected egress {E, P} and established for the context ID of the protected egress {E, P} and established
as described in Section 5.9. This approach is consistent with as described in Section 5.9. This approach is consistent with
egress node protection. Hence, a protector can serve in egress egress node protection. Hence, a protector can serve in egress
node protection and egress link protection in a consistent manner, node protection and egress link protection in a consistent manner,
and both the co-located protector mode and the centralized and both the co-located protector mode and the centralized
protector mode are supported (Figure-3 and Figure-4). protector mode are supported (Figure 3 and Figure 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 label
distribution protocol session. In this case, the backup egress distribution protocol session. In this case, the backup egress
router serves as the protector for egress link protection, router serves as the protector for egress link protection,
regardless of the protector of egress node protection, which will regardless of the protector of egress node protection, which will
be the same router in the co-located protector mode but a be the same router in the co-located protector mode but a
different router in the centralized protector mode. The egress different router in the centralized protector mode. The egress
router sets up the bypass forwarding state as a label swap from router sets up the bypass forwarding state as a label swap from
the incoming service label to the service label of the backup the incoming service label to the service label of the backup
egress router (i.e. protector), followed by a push with the egress router (i.e., protector), followed by a push with the
outgoing label (or label stack) of the egress link protection outgoing label (or label stack) of the egress link protection
bypass tunnel. The bypass tunnel is a regular tunnel destined for bypass tunnel. The bypass tunnel is a regular tunnel destined for
an IP address of the protector, instead of the context ID of the an IP address of the protector, instead of the context ID of the
protected egress {E, P}. The protector simply forwards rerouted protected egress {E, P}. The protector simply forwards rerouted
service packets based on its own service label, rather than service packets based on its own service label, rather than
performing context label switching. In this approach, only the performing context label switching. In this approach, only the
co-located protector mode is applicable. 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 bi-directionally. Therefore, an
skipping to change at page 21, line 44 skipping to change at page 22, line 44
that the services affected by a failure SHOULD be moved to an that the services affected by a failure SHOULD be moved to an
alternative tunnel, or replaced by alternative services, which are alternative tunnel, or replaced by alternative services, which are
fully functional. This is referred to as global repair. Possible fully functional. This is referred to as global repair. Possible
triggers of global repair include control plane notifications of triggers of global repair include control plane notifications of
tunnel status and service status, end-to-end OAM and fault detection tunnel status and service status, end-to-end OAM and fault detection
at tunnel and service level, and others. The alternative tunnel and at tunnel and service level, and others. The alternative tunnel and
services MAY be pre-established in standby state, or dynamically services MAY be pre-established in standby state, or dynamically
established as a result of the triggers or network protocol established as a result of the triggers or network protocol
convergence. convergence.
8. General context-based forwarding 8. Operational Considerations
So far this document has been focusing on the cases where service When a PLR performs local repair, it is RECOMMENDED that the router
SHOULD generate an alert for the event. The alert MAY be logged
locally for tracking purposes, or it MAY be sent to the operator at a
management station. The communication channel and protocol between
the PLR and the management station may vary depending on networks,
and are out of the scope of this document.
9. General context-based forwarding
So far, this document has been focusing on the cases where service
packets are MPLS or IP packets and protectors perform context label 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/MPLS formats. The only
specific in these cases is that a protector MUST perform context- specific in these cases is that a protector MUST perform context-
based forwarding based on the layer-2 table or corresponding lookup based forwarding based on the layer-2 table or corresponding lookup
table which is indicated by a context ID (i.e. context label). table which is indicated by a context ID (i.e., context label).
9. Example: Layer-3 VPN egress protection 10. Example: Layer-3 VPN egress protection
This section shows an example of egress protection for a layer-3 VPN. This section shows an example of egress protection for a layer-3 VPN.
---------- R1 ----------- PE2 - ---------- R1 ----------- PE2 -
/ (PLR) (PLR) \ / (PLR) (PLR) \
( ) / | | ( ) ( ) / | | ( )
( ) / | | ( ) ( ) / | | ( )
( site 1 )-- PE1 < | R3 ( site 2 ) ( site 1 )-- PE1 < | R3 ( site 2 )
( ) \ | | ( ) ( ) \ | | ( )
( ) \ | | ( ) ( ) \ | | ( )
skipping to change at page 23, line 31 skipping to change at page 24, line 39
route's nexthop is a push of the VPN label 9000, followed by a push route's nexthop is a push of the VPN label 9000, followed by a push
of the outgoing label of the egress-protected tunnel. of the outgoing label of the egress-protected tunnel.
Upon receipt of the above BGP advertisement from PE2, PE3 recognizes Upon receipt of the above BGP advertisement 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 in the label table pe2.mpls. PE3 sets the route for label 9000 in the label table pe2.mpls. PE3 sets the
route's nexthop to a "protection VRF". This protection VRF contains route's nexthop to a "protection VRF". This protection VRF contains
IP routes of the IP prefixes in the dual-homed site 2, including IP routes of the IP prefixes in the dual-homed site 2, including
203.0.113.128/26. The nexthops of these routes MUST be based on 203.0.113.128/26. The nexthops of these routes MUST be based on
PE3's connectivity with site 2, even if this connectivity may not PE3's connectivity with site 2, even if this connectivity may not
have the best metrics (e.g. MED, local preference, etc.) for PE3 to have the best metrics (e.g., MED, local preference, etc.) for PE3 to
use in its own VRF. The nexthops MUST NOT use any path traversing use in its own VRF. The nexthops MUST NOT use any path traversing
PE2. Note that the protection VRF is a logical concept, and it may PE2. Note that the protection VRF is a logical concept, and it may
simply be PE3's own VRF if the VRF satisfies the requirement. simply be PE3's own VRF if the VRF satisfies the requirement.
9.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 ID protection desired" flag and the destination address (i.e., context
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 bypass R1->R2->PE3. R1 then signals the path (i.e., egress-protection
tunnel), with 198.51.100.1 as destination. bypass tunnel), with 198.51.100.1 as 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, and hence responds with the context label 100 in an RSVP destination, and hence responds with the context label 100 in an RSVP
Resv message. Resv 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 nexthop for the egress-protected tunnel. The bypass nexthop
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.
skipping to change at page 24, line 20 skipping to change at page 25, line 27
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 service packets. The packets will have the nexthop to reroute VPN service packets. The packets will have the
label of the bypass tunnel as outer label, and the VPN label 9000 as label of the bypass tunnel as outer label, and the VPN label 9000 as
inner label. When the packets arrive at PE3, they will have the inner label. When the packets arrive at PE3, they will have the
context label 100 as outer label, and the VPN label 9000 as inner context label 100 as outer label, and the VPN label 9000 as inner
label. The context label will first be popped, and then the VPN label. The context label will first be popped, and then the VPN
label will be looked up in the label table pe2.mpls. The lookup will label will be looked up in the label table pe2.mpls. The lookup will
cause the VPN label to be popped, and the IP packets to be forwarded cause the VPN label to be popped, and the IP packets to be forwarded
to site 2 based on the protection VRF. to site 2 based on the protection VRF.
9.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 the VPN label 10000 from PE3, and hence it uses the approach learned the VPN label 10000 from PE3, and hence it uses the approach
(2) described in Section 6 to set up bypass forwarding state. It (2) described in Section 6 to set up bypass forwarding state. It
signals an egress-protection bypass tunnel to PE3, by using the path signals an egress-protection bypass tunnel to PE3, by using the path
PE2->R3->PE3, and PE3's IP address as destination. After the bypass PE2->R3->PE3, and PE3's IP address as destination. After the bypass
tunnel comes up, PE2 installs a bypass nexthop for the VPN label tunnel comes up, PE2 installs a bypass nexthop for the VPN label
9000. The bypass nexthop is a label swap from the incoming label 9000. The bypass nexthop is a label swap from the incoming label
9000 to the VPN label 10000 of PE3, followed by a label push with the 9000 to the VPN label 10000 of PE3, followed by a label push with the
outgoing label of the bypass tunnel. outgoing label 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 service packets. The packets above bypass nexthop to reroute VPN service packets. The packets
will have the label of the bypass tunnel as outer label, and the VPN will have the label of the bypass tunnel as outer label, and the VPN
label 10000 as inner label. When the packets arrive at PE3, the VPN label 10000 as inner label. When the packets arrive at PE3, the VPN
label 10000 will be popped, and the IP packets to be forwarded based label 10000 will be popped, and the IP packets to be forwarded based
on the VRF indicated by on the VPN label 10000. on the VRF indicated by on the VPN label 10000.
9.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.
9.4. Other modes of VPN label allocation 10.4. Other modes of VPN label allocation
In the above example, PE2 uses per-VRF VPN label allocation mode, and In the above example, PE2 uses per-VRF VPN label allocation mode, and
binds a common VPN label to all the VPN prefixes which it advertises. binds a common VPN label to all the VPN prefixes which it advertises.
When PE3 processes the VPN label in the redirected packets, it When PE3 processes the VPN label in the redirected packets, it
follows the nexthop of the label route in the pe2.mpls table, by follows the nexthop of the label route in the pe2.mpls table, by
popping the VPN label and performing an IP lookup in the protection popping the VPN label and performing an IP lookup in the protection
VRF. VRF.
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 label label allocation mode. In either case, PE3 will have multiple label
routes in the pe2.mpls table, corresponding to the VPN labels routes in the pe2.mpls table, corresponding to the VPN labels
advertised by PE2. PE3 may use the same nexthop as the above for all advertised by PE2. PE3 may use the same nexthop as the above for all
the label routes, to process redirected packets by popping a VPN the label routes, to process redirected packets by popping a VPN
label and performing an IP lookup in the protection VRF. Therefore, label and performing an IP lookup in the protection VRF. Therefore,
PE3 does not need to learn PE2's VPN label allocation mode or PE3 does not need to learn PE2's VPN label allocation mode or
construct a specific nexthop for each label route in the pe2.mpls construct a specific nexthop for each label route in the pe2.mpls
table. table.
10. IANA Considerations 11. IANA Considerations
This document has no request for new IANA allocation. This document has no request for new IANA allocation.
11. 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. Some control protector, and ultimately to a backup egress router. Some control
plane protocols MAY be used between these routers to facilitate the plane protocols MAY be used between these routers to facilitate the
establishment of egress protection. The general security measures of establishment of egress protection. The general security measures of
the protocols SHOULD be used whenever applicable. In particular, the the protocols SHOULD be used whenever applicable. In particular, the
framework requires a service label distribution protocol to run framework requires a service label distribution protocol between an
between an egress router and a protector. The available security egress router and a protector. The security measures of the chosen
measures of the chosen protocol SHOULD be used to achieve a secured protocol SHOULD be used to achieve a secured session between the two
session between the two routers. routers.
PLR, protector, and backup egress router are located close to the Also, the PLR, protector, and backup egress router are located close
protected egress router, and normally in the same administrative to the protected egress router, and normally in the same
domain. In the case where the routers are not in the same administrative domain. If they are not in the same administrative
administrative domain, a certain level trust MUST be established domain, a certain level of trust MUST be established between them in
between the routers in order for the protocols to run securely. The order for the protocols to run securely. The forwarding performed by
forwarding performed by the routers in the data plane is also the routers in the data plane is also anticipated, as part of the
anticipated, as part of egress protection planning. Therefore, the planning of egress protection.
framework should not introduce any new security threat to the
network.
12. Acknowledgements In one possible case, the egress link between an egress router and a
CE could become a point of attack. An attacker that gains control of
the CE might use it to simulate link failures and trigger constant
and cascading activities in the network. Such attack could occur
regardless of the existence of egress protection. If egress link
protection is in place, the attack might also trigger egress link
protection activities. As a general solution to defeat the attack, a
damping mechanism SHOULD be used by the egress router to promptly
suppress the services associated with the link or CE. The egress
router would stop advertising the services, essentially detaching
them from the network and eliminating the effect of the simulated
link failures.
From the above perspectives, this framework does not introduce any
new security threat to networks.
13. Acknowledgements
This document leverages work done by Yakov Rekhter, Kevin Wang and This document leverages work done by Yakov Rekhter, Kevin Wang and
Zhaohui Zhang on MPLS egress protection. Thanks to Alexander Zhaohui Zhang on MPLS egress protection. Thanks to Alexander
Vainshtein, Rolf Winter, Lizhong Jin, Krzysztof Szarkowicz, and Vainshtein, Rolf Winter, Lizhong Jin, Krzysztof Szarkowicz, and
Yuanlong Jiang for their valuable comments that helped to shape this Yuanlong Jiang for their valuable comments that helped to shape this
document and improve its clarity. document and improve its clarity.
13. References 14. References
13.1. Normative References 14.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>.
skipping to change at page 26, line 33 skipping to change at page 28, line 5
[SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., [SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions (work in progress), 2017. routing-extensions (work in progress), 2017.
[SR-ISIS] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., [SR-ISIS] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
Extensions for Segment Routing", draft-ietf-isis-segment- Extensions for Segment Routing", draft-ietf-isis-segment-
routing-extensions (work in progress), 2017. routing-extensions (work in progress), 2017.
13.2. Informative References 14.2. Informative References
[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 27, line 21 skipping to change at page 28, line 38
"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 [BGP-PIC] Bashandy, P., Filsfils, C., and P. Mohapatra, "BGP Prefix
Independent Convergence", draft-ietf-rtgwg-bgp-pic-08.txt Independent Convergence", draft-ietf-rtgwg-bgp-pic-09.txt
(work in progress), 2017. (work in progress), 2017.
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 USA
 End of changes. 70 change blocks. 
123 lines changed or deleted 146 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/