draft-ietf-mpls-egress-protection-framework-06.txt   draft-ietf-mpls-egress-protection-framework-07.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: December 29, 2019 Bruno Decraene Expires: February 1, 2020 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.
June 27, 2019 July 31, 2019
MPLS Egress Protection Framework MPLS Egress Protection Framework
draft-ietf-mpls-egress-protection-framework-06 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 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
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 December 29, 2019. This Internet-Draft will expire on February 1, 2020.
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 45 skipping to change at page 2, line 45
5.9. Egress-protection bypass tunnel establishment . . . . . . 15 5.9. Egress-protection bypass tunnel establishment . . . . . . 15
5.10. Local repair on PLR . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . 19 6. Egress link protection . . . . . . . . . . . . . . . . . . . 19
7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 22 7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Operational Considerations . . . . . . . . . . . . . . . . . 22 8. Operational Considerations . . . . . . . . . . . . . . . . . 22
9. General context-based forwarding . . . . . . . . . . . . . . 23 9. General context-based forwarding . . . . . . . . . . . . . . 23
10. Example: Layer-3 VPN egress protection . . . . . . . . . . . 23 10. Example: Layer-3 VPN egress protection . . . . . . . . . . . 23
10.1. Egress node protection . . . . . . . . . . . . . . . . . 24 10.1. Egress node protection . . . . . . . . . . . . . . . . . 25
10.2. Egress link protection . . . . . . . . . . . . . . . . . 25 10.2. Egress link protection . . . . . . . . . . . . . . . . . 25
10.3. Global repair . . . . . . . . . . . . . . . . . . . . . 25 10.3. Global repair . . . . . . . . . . . . . . . . . . . . . 26
10.4. Other modes of VPN label allocation . . . . . . . . . . 26 10.4. Other modes of VPN label allocation . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
12. Security Considerations . . . . . . . . . . . . . . . . . . . 26 12. Security Considerations . . . . . . . . . . . . . . . . . . . 26
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. Normative References . . . . . . . . . . . . . . . . . . 27 14.1. Normative References . . . . . . . . . . . . . . . . . . 28
14.2. Informative References . . . . . . . . . . . . . . . . . 28 14.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 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., CoS, QoS) of these
services. The egress router of the tunnel hosts the service services. The egress router of the tunnel hosts the service
skipping to change at page 4, line 29 skipping to change at page 4, line 29
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, as 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
skipping to change at page 5, line 20 skipping to change at page 5, line 20
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 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 as 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 SHOULD be used in conjunction with control-plane framework be used in conjunction with control-plane convergence or
convergence or global repair, in order to take the advantages of both global repair, in order to take the advantages of both approaches.
approaches. That is, the framework provides fast and temporary That is, the framework provides fast and temporary repair, while
repair, while control-plane convergence or global repair provides control-plane convergence or global repair provides ultimate and
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119] and document are to be interpreted as described in [RFC2119] and
[RFC8174]. [RFC8174].
3. Terminology 3. Terminology
skipping to change at page 6, line 20 skipping to change at page 6, line 20
egress router, this is another router which has connectivity with all egress router, this is another router which has connectivity with all
or a subset of the destinations of the egress-protected services or a subset of the destinations of the egress-protected services
carried by the egress-protected tunnel. carried by the egress-protected tunnel.
Backup service instance - A service instance which is hosted by a Backup service instance - A service instance which is hosted by a
backup egress router, and corresponding to an egress-protected backup egress router, and corresponding to an egress-protected
service on a protected egress router. service on a protected egress router.
Protector - A role acted by a router as an alternate of a protected Protector - A role acted by a router as an alternate of a protected
egress router, to handle service packets in the event of an egress egress router, to handle service packets in the event of an egress
failure. A protector MAY be physically co-located with or decoupled failure. A protector may be physically co-located with or decoupled
from a backup egress router, depending on the co-located or from a backup egress router, depending on the co-located or
centralized protector mode. centralized protector mode.
Protection service instance - A service instance hosted by a Protection service instance - A service instance hosted by a
protector, corresponding to the service instance of an egress- protector, corresponding to the service instance of an egress-
protected service on a protected egress router. A protection service protected service on a protected egress router. A protection service
instance is a backup service instance, if the protector is co-located instance is a backup service instance, if the protector is co-located
with a backup egress router. with a backup egress router.
PLR - A router at the point of local repair. In egress node PLR - A router at the point of local repair. In egress node
skipping to change at page 7, line 17 skipping to change at page 7, line 17
Context label switching - Label switching performed by a protector, Context label switching - Label switching performed by a protector,
in the label space of an egress router indicated by a context label. 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 - IP forwarding performed by a protector, in
the IP address space of an egress router indicated by a context the IP address space of an egress router indicated by a context
label. label.
4. Requirements 4. Requirements
This document considers the followings 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 o 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 o 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 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 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 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.
o The framework MUST be able to work seamlessly with transit link/ o 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 o 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
skipping to change at page 9, line 5 skipping to change at page 9, line 5
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 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 in this protection. This document provides the following guidelines for
regard. network operators to choose a proper type of protection on a PLR.
o If the PLR has a reasonably fast mechanism to detect and o If the PLR has a mechanism to detect and differentiate a link
differentiate a link failure (of the link between the PLR and the failure (of the link between the PLR and the egress node) and an
egress node) and an egress node failure, it SHOULD set up both egress node failure, it SHOULD set up both link protection and
link protection and egress node protection, and trigger one and egress node protection, and trigger one and only one protection
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 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.
skipping to change at page 9, line 45 skipping to change at page 9, line 45
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 tailend 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 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 may serve as the protector. Each protection
instance on the protector relies on such connectivity to set up service instance on the protector relies on such connectivity to set
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 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 49 skipping to change at page 11, line 49
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 the protector P. This
bypass tunnel is called an egress-protection bypass tunnel. The bypass tunnel is called an egress-protection bypass tunnel. The
bypass tunnel is considered as logically "destined" for the protected bypass tunnel is considered as logically "destined" for the protected
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 or IPv6 address is assigned
protected egress {E, P} as the identifier of the protected egress {E, to a protected egress {E, P} as the identifier of the protected
P}. It is called a "context ID" due to its specific usage in context egress {E, P}. It is called a "context ID" due to its specific usage
label switching and context IP forwarding on the protector. It is an in context label switching and context IP forwarding on the
IP address that is logically owned by both the egress router and the protector. It is an IP address that is logically owned by both the
protector. For the egress router, it indicates the protector. For egress router and the protector. For the egress router, it indicates
the protector, it indicates the egress router, particularly the the protector. For the protector, it indicates the egress router,
egress router's forwarding context. For other routers in the particularly the egress router's forwarding context. For other
network, it is an address reachable via both the egress router and routers in the network, it is an address reachable via both the
the protector (Section 5.8), similar to an anycast address. egress router and the protector (Section 5.8), similar to an anycast
address.
The main purpose of a context ID is to coordinate ingress router, The main purpose of a context ID is to coordinate ingress router,
egress router, PLR and protector to establish egress protection. The egress router, PLR and protector to establish egress protection. The
procedures are described below, given an egress-protected service 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 context ID.
o If the service is an MPLS service, when E distributes a service o 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
skipping to change at page 13, line 21 skipping to change at page 13, line 21
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
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 o P assigns a non-reserved label to the context ID. In the data
plane, this label represents the context ID and indicates E's 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 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 ultimate-hop-popping (UHP) tunnel whose
context label. incoming label on P is the 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
context label. Such kind of forwarding is called context label context label. Such kind of forwarding is called context label
switching. For an IP service packet, P looks up the IP switching. For an IP service packet, P looks up the IP
destination address in E's IP address space indicated by the destination address in E's IP address space indicated by the
context label. Such kind of forwarding is called context IP context label. Such kind of forwarding is called context IP
forwarding. forwarding.
skipping to change at page 14, line 27 skipping to change at page 14, line 27
ID will automatically follow the IGP or TE paths to E. Each PLR ID will automatically follow the IGP or TE paths to E. Each PLR
will no longer view itself as a penultimate-hop, but rather two will no longer view itself as a penultimate-hop, but rather two
hops away from the proxy node, via E. The PLR will be able to hops away from the proxy node, via E. The PLR will be able to
find a bypass path via P to the proxy node, while the bypass find a bypass path via P to the proxy node, while the bypass
tunnel is 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. In both
advertisement MUST be understood by the PLR. In both routing routing domain and TE domain, the context ID is only reachable
domain and TE domain, the context ID is only reachable via E. via E. Therefore, all egress-protected tunnels destined for the
Therefore, all egress-protected tunnels destined for the context context ID will have E as tailend. Based on the "context ID
ID will have E as tailend. Based on the "context ID label 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] and [SR-ISIS]. These IGP
These IGP extensions are generic in nature, and hence can be used extensions are generic in nature, and hence can be used for
for egress protection purposes. egress protection purposes. It is RECOMMENDED that a similar
advertisement be defined for OSPF as well.
3. The third approach is called "stub link mode". In this mode, 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 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 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
skipping to change at page 15, line 21 skipping to change at page 15, line 21
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 or AS to the area or AS of the ingress or BGP from the original area or AS to the area or AS of the ingress
router. The propagation process of the context ID SHOULD be the same router. The propagation process of the context ID SHOULD be the same
as that of an IP address in an inter-area or inter-AS environment. 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- (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 the TE domain
by IGP according to Section 5.8, the PLR is able to resolve or 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 tailend. In the
case of proxy mode, the PLR MAY do so in the same manner as transit case of proxy mode, the PLR may do so in the same manner as transit
node 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 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
skipping to change at page 16, line 51 skipping to change at page 16, line 51
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
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
discussion has been focusing on the scenario where a protector and a discussion has been focusing on the scenario where a protector and a
backup egress router are co-located as one router. Therefore, the backup egress router are co-located as one router. Therefore, the
number of protectors in a network is equal to the number of backup number of protectors in a network is equal to the number of backup
egress routers. As another scenario, a network MAY assign a small egress routers. As another scenario, a network may assign a small
number of routers to serve as dedicated protectors, each protecting a number of routers to serve as dedicated protectors, each protecting a
subset of egress routers. These protectors are called centralized subset of 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 \
skipping to change at page 22, line 33 skipping to change at page 22, line 33
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
egress link failure may simultaneously be an ingress link failure for egress link failure may simultaneously be an ingress link failure for
the traffic in the opposite direction. Protection for ingress link the 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, it is RECOMMENDED and egress link failures. For permanent repair, the services
that the services affected by a failure SHOULD be moved to an affected by a failure SHOULD be moved to an alternative tunnel, or
alternative tunnel, or replaced by alternative services, which are replaced by alternative services, which are fully functional. This
fully functional. This is referred to as global repair. Possible is referred to as global repair. Possible triggers of global repair
triggers of global repair include control plane notifications of include control plane notifications of tunnel status and service
tunnel status and service status, end-to-end OAM and fault detection status, end-to-end OAM and fault detection at tunnel and service
at tunnel and service level, and others. The alternative tunnel and level, and others. The alternative tunnel and services may be pre-
services MAY be pre-established in standby state, or dynamically established in standby state, or dynamically established as a result
established as a result of the triggers or network protocol of the triggers or network protocol convergence.
convergence.
8. Operational Considerations 8. Operational Considerations
When a PLR performs local repair, it is RECOMMENDED that the router When a PLR performs local repair, the router SHOULD generate an alert
SHOULD generate an alert for the event. The alert MAY be logged for the event. The alert may be logged locally for tracking
locally for tracking purposes, or it MAY be sent to the operator at a purposes, or it may be sent to the operator at a management station.
management station. The communication channel and protocol between The communication channel and protocol between the PLR and the
the PLR and the management station may vary depending on networks, management station may vary depending on networks, and are out of the
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/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).
10. 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 layer-3 IPv4
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 site 1 (subnet 203.0.113.192/26) of a given VPN In this example, the core network is IPv4 and MPLS. Both of the IPv4
is attached to PE1, and site 2 (subnet 203.0.113.128/26) is dual- VPN and the IPv6 VPN consist of site 1 and site 2. Site 1 is
homed to PE2 and PE3. PE2 is the primary PE for site 2, and PE3 is connected to PE1, and site 2 is dual-homed to PE2 and PE3. Site 1
the backup PE. Each PE hosts a VPN instance. R1 and R2 are transit includes an IPv4 subnet 203.0.113.64/26 and an IPv6 subnet
routers in the MPLS network. The network uses OSPF as routing 2001:db8:1:1::/64. Site 2 includes an IPv4 subnet 203.0.113.128/26
protocol, and RSVP-TE as tunnel signaling protocol. The PEs use BGP and an IPv6 subnet 2001:db8:1:2::/64. PE2 is the primary PE for site
to exchange VPN prefixes and VPN labels between each other. 2, and PE3 is the backup PE. Each of PE1, PE2 and PE3 hosts an IPv4
VPN instance and an IPv6 VPN instance. The PEs use BGP to exchange
VPN prefixes and VPN labels between each other. In the core network,
R1 and R2 are transit routers, OSPF is used as the routing protocol,
and RSVP-TE as the tunnel signaling protocol.
Using the framework in this document, the network assigns PE3 to be a Using the framework in this document, the network assigns PE3 to be
protector for 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. Hence, PE2 site 1 to site 2. This is the co-located protector mode. PE2 and
and PE3 form a protected egress {PE2, PE3}. A context ID 198.51.100.1 PE3 form a protected egress {PE2, PE3}. A context ID 198.51.100.1 is
is assigned to the protected egress {PE2, PE3}. The VPN instance on assigned to the protected egress {PE2, PE3}. (If the core network is
PE3 serves as a protection instance for the VPN instance on PE2. On IPv6, the context ID would be an IPv6 address.) The IPv4 and IPv6
PE3, a context label 100 is assigned to the context ID, and a label VPN instances on PE3 serve as protection instances for the
table pe2.mpls is created to represent PE2's label space. PE3 corresponding VPN instances on PE2. On PE3, a context label 100 is
installs the label 100 in its MPLS forwarding table, with nexthop assigned to the context ID, and a label table pe2.mpls is created to
pointing to the label table pe2.mpls. PE2 and PE3 are coordinated to represent PE2's label space. PE3 installs label 100 in its MPLS
use the proxy mode to advertise the context ID in the routing domain forwarding table, with nexthop pointing to the label table pe2.mpls.
and the TE domain. PE2 and PE3 are coordinated to use the proxy mode to advertise the
context ID in the routing domain and the TE domain.
PE2 uses per-VRF VPN label allocation mode. It assigns a single PE2 uses per-VRF label allocation mode for both of its IPv4 and IPv6
label 9000 to the VRF of the VPN. For a given VPN prefix VPN instances. It assigns label 9000 to the IPv4 VRF, and label 9001
203.0.113.128/26 in site 2, PE2 advertises it along with the label to the IPv6 VRF. For the IPv4 prefix 203.0.113.128/26 in site 2, PE2
9000 to PE1 and PE3 via BGP. The NEXT_HOP attribute is set to the advertises it with label 9000 and NEXT_HOP 198.51.100.1 to PE1 and
context ID 198.51.100.1. PE3 via BGP. Likewise, for the IPv6 prefix 2001:db8:1:2::/64 in site
2, PE2 advertises it with label 9001 and NEXT_HOP 198.51.100.1 to PE1
and PE3 via BGP.
Similarly, PE3 also uses per-VRF VPN label allocation mode. It PE3 also uses per-VRF VPN label allocation mode for both of its IPv4
assigns a single label 10000 to the VRF of the VPN. For the VPN and IPv6 VPN instances. It assigns label 10000 to the IPv4 VRF, and
prefix 203.0.113.128/26 in site 2, PE3 advertises it along with the label 10001 to the IPv6 VRF. For the prefix 203.0.113.128/26 in site
label 10000 to PE1 and PE2 via BGP. The NEXT_HOP attribute is set to 2, PE3 advertises it with label 10000 and NEXT_HOP as itself to PE1
an IP address of PE3. and PE2 via BGP. For the IPv6 prefix 2001:db8:1:2::/64 in site 2,
PE3 advertises it with label 10001 and NEXT_HOP as itself to PE1 and
PE2 via BGP.
Upon receipt and acceptance of the BGP advertisement, 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 TE path for an context ID 198.51.100.1 as destination to compute a path for an
egress-protected tunnel. The resultant path is PE1->R1->PE2. PE1 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 destination, and with the "node protection desired" flag set in
the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes the SESSION_ATTRIBUTE of RSVP Path message. Once the tunnel comes
up, PE1 maps the VPN prefix 203.0.113.128/26 to the tunnel and up, PE1 maps the VPN prefixes 203.0.113.128/26 and 2001:db8:1:2::/64
installs a route for the prefix in the corresponding VRF. The to the tunnel, and installs a route for each prefix in the
route's nexthop is a push of the VPN label 9000, followed by a push corresponding IPv4 or IPv6 VRF. The nexthop of the route
of the outgoing label of the egress-protected tunnel. 203.0.113.128/26 is a push of the VPN label 9000, followed by a push
of the outgoing label of the egress-protected tunnel. The nexthop of
the route 2001:db8:1:2::/64 is a push of the VPN label 9001, followed
by a push of the outgoing label of the egress-protected tunnel.
Upon receipt of the above BGP advertisement 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 in the label table pe2.mpls. PE3 sets the route for label 9000 and a route for label 9001 in the label table
route's nexthop to a "protection VRF". This protection VRF contains pe2.mpls. PE3 sets the nexthop of the route 9000 to the IPv4
IP routes of the IP prefixes in the dual-homed site 2, including protection VRF, and the nexthop of the route 9001 to the IPv6
203.0.113.128/26. The nexthops of these routes MUST be based on protection VRF. The IPv4 protection VRF contains the routes to the
PE3's connectivity with site 2, even if this connectivity may not IPv4 prefixes in site 2. The IPv6 protection VRF contains the routes
have the best metrics (e.g., MED, local preference, etc.) for PE3 to to the IPv6 prefixes in site 2. The nexthops of these routes must be
use in its own VRF. The nexthops MUST NOT use any path traversing based on PE3's connectivity with site 2, even if the connectivity may
PE2. Note that the protection VRF is a logical concept, and it may not have the best metrics (e.g., MED, local preference, etc.) to be
simply be PE3's own VRF if the VRF satisfies the requirement. used in PE3's own VRF. The nexthops must not use any path traversing
PE2. Note that the protection VRFs are a logical concept, and they
may simply be PE3's own VRFs if they satisfies the requirement.
10.1. Egress node protection 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 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 responds with the context label 100 in an RSVP Resv
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 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.
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 packets. Each IPv4 VPN packet 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 IPv4 VPN label
9000 as inner label. Each IPv6 VPN packets will have the label of
the bypass tunnel as outer label, and the IPv6 VPN label 9001 as
inner label. When the packets arrive at PE3, they will have the 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 or 9001 as
label. The context label will first be popped, and then the VPN inner label. The context label will first be popped, and then the
label will be looked up in the label table pe2.mpls. The lookup will VPN label will be looked up in the label table pe2.mpls. The lookup
cause the VPN label to be popped, and the IP packets to be forwarded will cause the VPN label to be popped, and the IPv4 and IPv6 packets
to site 2 based on the protection VRF. to be forwarded to site 2 based on the IPv4 and IPv6 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 the VPN label 10000 from PE3, and hence it uses the approach learned PE3's IPv4 VPN label 10000 and IPv6 VPN label 10001. Hence
(2) described in Section 6 to set up bypass forwarding state. It it uses the approach (2) described in Section 6 to set up bypass
signals an egress-protection bypass tunnel to PE3, by using the path forwarding state. It signals an egress-protection bypass tunnel to
PE2->R3->PE3, and PE3's IP address as destination. After the bypass PE3, by using the path PE2->R3->PE3, and PE3's IP address as
tunnel comes up, PE2 installs a bypass nexthop for the VPN label destination. After the bypass tunnel comes up, PE2 installs a bypass
9000. The bypass nexthop is a label swap from the incoming label nexthop for the IPv4 VPN label 9000, and a bypass nexthop for the
9000 to the VPN label 10000 of PE3, followed by a label push with the IPv6 VPN label 9001. For label 9000, the bypass nexthop is a label
outgoing label of the bypass tunnel. swap to label 10000, followed by a label push with the outgoing label
of the bypass tunnel. For label 9001, the bypass nexthop is a label
swap to label 10001, followed by a label push with the outgoing label
of the bypass tunnel.
When PE2 detects a failure of the egress link, it will invoke the 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 packets. Each IPv4 VPN packet
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 label
label 10000 as inner label. When the packets arrive at PE3, the VPN 10000 as inner label. Each IPv6 VPN packet will have the label of
label 10000 will be popped, and the IP packets to be forwarded based the bypass tunnel as outer label, and label 10001 as inner label.
on the VRF indicated by on the VPN label 10000. When the packets arrive at PE3, the VPN label 10000 or 10001 will be
popped, and the exposed IPv4 and IPv6 packets will be forwarded based
on PE3's IPv4 and IPv6 VRFs, respectively.
10.3. Global repair 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
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.
When PE3 processes the VPN label in the redirected packets, it
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
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 VPN
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 may use the same nexthop as the above for all advertised by PE2. PE3 forwards rerouted packets by popping a VPN
the label routes, to process redirected packets by popping a VPN label and performing an IP lookup in the corresponding protection
label and performing an IP lookup in the protection VRF. Therefore, VRF. PE3's forwarding behavior is consistent with the above case
PE3 does not need to learn PE2's VPN label allocation mode or where PE2 uses per-VRF VPN label allocation mode. PE3 does not need
construct a specific nexthop for each label route in the pe2.mpls to know PE2's VPN label allocation mode, or construct a specific
table. nexthop 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 request for new IANA allocation.
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. Some control protector, and ultimately to a backup egress router. The forwarding
plane protocols MAY be used between these routers to facilitate the performed by the routers in the data plane is anticipated, as part of
establishment of egress protection. The general security measures of the planning of egress protection.
the protocols SHOULD be used whenever applicable. In particular, the
framework requires a service label distribution protocol between an Control plane protocols MAY be used to facilitate the provisioning of
egress router and a protector. The security measures of the chosen the egress protection on the routers. In particular, the framework
protocol SHOULD be used to achieve a secured session between the two requires a service label distribution protocol between an egress
routers. router and a protector over a secure session. The security
properties of this provisioning and label distribution depend
entirely on the underlying protocol chosen to implement these
activities . Their associated security considerations apply. This
framework introduces no new security requirements or guarantees
relative to these activities.
Also, the PLR, protector, and backup egress router are located close 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, and 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. The forwarding performed by order for the protocols to run securely across the domain boundary.
the routers in the data plane is also anticipated, as part of the The basis of this trust is the security model of the protocols (as
planning of egress protection. described above), and further security considerations for inter-
domain scenarios should be addressed by the protocols as a common
requirement.
In one possible case, the egress link between an egress router and a Security attacks may sometimes come from a customer domain. Such
CE could become a point of attack. An attacker that gains control of kind of attacks are not introduced by the framework in this document,
and may occur regardless of the existence of egress protection. In
one possible case, the egress link between an egress router and a CE
could become a point of attack. An attacker that gains control of
the CE might use it to simulate link failures and trigger constant the CE might use it to simulate link failures and trigger constant
and cascading activities in the network. Such attack could occur and cascading activities in the network. If egress link protection
regardless of the existence of egress protection. If egress link is in place, egress link protection activities may also be triggered.
protection is in place, the attack might also trigger egress link As a general solution to defeat the attack, a damping mechanism
protection activities. As a general solution to defeat the attack, a SHOULD be used by the egress router to promptly suppress the services
damping mechanism SHOULD be used by the egress router to promptly associated with the link or CE. The egress router would stop
suppress the services associated with the link or CE. The egress advertising the services, essentially detaching them from the network
router would stop advertising the services, essentially detaching and eliminating the effect of the simulated link failures.
them from the network 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. 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, Roman
Yuanlong Jiang for their valuable comments that helped to shape this Danyliw, and Yuanlong Jiang for their valuable comments that helped
document and improve its clarity. to shape this document and improve its clarity.
14. References 14. References
14.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>.
[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-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment-
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.
14.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,
 End of changes. 75 change blocks. 
216 lines changed or deleted 235 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/