draft-ietf-mpls-egress-protection-framework-01.txt   draft-ietf-mpls-egress-protection-framework-02.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 24, 2018 Bruno Decraene Expires: January 20, 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
Yuanlong Jiang Yuanlong Jiang
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
June 22, 2018 July 19, 2018
MPLS Egress Protection Framework MPLS Egress Protection Framework
draft-ietf-mpls-egress-protection-framework-01 draft-ietf-mpls-egress-protection-framework-02
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. In this framework, the penultimate-hop router egress link failures. In this framework, the penultimate-hop router
of an MPLS tunnel acts as the point of local repair (PLR) for egress of an MPLS tunnel acts as the point of local repair (PLR) for an
node failure, and the egress router of the MPLS tunnel acts as the egress node failure, and the egress router of the MPLS tunnel acts as
PLR for egress link failure. Each of them pre-establishes a bypass the PLR for an egress link failure. Each of them pre-establishes a
tunnel to a protector. Upon an egress node or link failure, the bypass tunnel to a protector. Upon an egress node or link failure,
corresponding PLR performs local failure detection and local repair, the corresponding PLR performs local failure detection and local
by rerouting packets over the corresponding bypass tunnel. The repair, by rerouting packets over the corresponding bypass tunnel.
protector in turn performs context label switching or context IP The protector in turn performs context label switching or context IP
forwarding to send the packets to the ultimate service forwarding to send the packets to the ultimate service
destination(s). This mechanism can be used to reduce traffic loss destination(s). This mechanism can be used to reduce traffic loss
before global repair reacts to the failure and control plane before global repair reacts to the failure and control plane
protocols converge on the topology changes due to the failure. The protocols converge on the topology changes due to the failure. The
framework is applicable to all types of IP/MPLS services and MPLS framework is applicable to all types of IP/MPLS services and MPLS
tunnels. Under the framework, service protocol extensions may be tunnels. Under the framework, service protocol extensions may be
further specified to support service label distribution to the further specified to support service label distribution from an
protector. egress router to a protector.
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 December 24, 2018. This Internet-Draft will expire on January 20, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 3, line 21 skipping to change at page 3, line 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
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 can satisfy multiple services of one or multiple types, if the tunnel can satisfy
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 should host the services. The egress router of the tunnel hosts the service
corresponding service instances of the services. An MPLS service instances of the services. Each MPLS service instance is responsible
instance is responsible for forwarding service packets via an egress for forwarding service packets via an egress link to the service
link to the service destination, based on a service label. An IP destination, based on a service label. Each IP service instance is
service instance is responsible for doing the same based on a service responsible for doing the same based on a service IP address. The
IP address. The egress link is often called a PE-CE (provider edge - egress link is often called a PE-CE (provider edge - customer edge)
customer edge) link or attachment circuit (AC). 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], [RFC7812] have been widely deployed to protect
MPLS tunnels against transit link/node failures. They can achieve MPLS tunnels against transit link/node failures, with traffic
fast restoration of traffic in the order of tens of milliseconds. restoration time in the order of tens of milliseconds. Local repair
Local repair refers to the scenario where the router upstream to an refers to the scenario where the router upstream to an anticipated
anticipated failure (aka. PLR, i.e. point of local repair) pre- failure (aka. PLR, i.e. point of local repair) pre-establishes a
establishes a bypass tunnel to the router downstream of the failure bypass tunnel to the router downstream of the failure (aka. MP, i.e.
(aka. MP, i.e. merge point), and pre-installs the forwarding state merge point), pre-installs the forwarding state of the bypass tunnel
of the bypass tunnel in the data plane. The PLR also uses a rapid in the data plane, and uses a rapid mechanism (e.g. link layer OAM,
mechanism (e.g. link layer OAM, BFD, and others) to locally detect BFD, and others) to locally detect the failure in the data plane.
the failure in the data plane. When the failure occurs, the PLR When the failure occurs, the PLR reroutes traffic through the bypass
reroutes traffic through the bypass tunnel to the MP, allowing the tunnel to the MP, allowing the traffic to continue to flow to the
traffic to continue to flow to the tunnel's egress router. tunnel's egress router.
This document describes a fast reroute framework for egress node and This document describes 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 relies on a PLR to perform local failure detection and this framework also relies on a PLR to perform local failure
local repair. In egress node protection, the PLR is the penultimate- detection and local repair. In egress node protection, the PLR is
hop router of a tunnel. In egress link protection, the PLR is the the penultimate-hop router of a tunnel. In egress link protection,
egress router of the tunnel. The framework relies on a so-called the PLR is the egress router of the tunnel. The framework further
"protector" to serve as the tailend of a bypass tunnel. The relies on a so-called "protector" to serve as the tailend of a bypass
protector is a router that hosts "protection service instances" and tunnel. The protector is a router that hosts "protection service
has its own connectivity or paths to service destinations. When a instances" and has its own connectivity or paths to service
PLR is doing local repair, the protector is responsible for destinations. When a PLR does local repair, the protector is
performing "context label switching" for rerouted MPLS service responsible for performing "context label switching" for rerouted
packets and "context IP forwarding" for rerouted IP service packets. MPLS service packets and "context IP forwarding" for rerouted IP
Thus, the service packets can continue to reach service destinations service packets, to allow the service packets to continue to reach
with minimum disruption. the service destinations.
This framework considers an egress node failure as a failure of a This framework considers an egress node failure as a failure of a
tunnel, as well as a failure of all the services carried by the tunnel, as well as a failure of all the services carried by the
tunnel, because service packets can no longer reach the service tunnel, because service packets can no longer reach the service
instances on the egress router. Therefore, the framework addresses instances on the egress router. Therefore, the framework addresses
egress node protection at both tunnel level and service level egress node protection at both tunnel level and service level
simultaneously. Likewise, the framework considers an egress link simultaneously. Likewise, the framework considers an egress link
failure as a failure of all the services traversing the link, and failure as a failure of all the services traversing the link, and
addresses egress link protection at the service level. addresses egress link protection at the service level.
This framework requires that the destination (a CE or site) of a This framework requires that the destination (a CE or site) of a
service MUST be dual-homed or have dual paths to an MPLS network, service MUST be dual-homed or have dual paths to an MPLS network, via
normally via two MPLS edge routers. One of them is the egress router two MPLS edge routers. One of the routers is the egress router of
of the service's transport tunnel, and the other is a backup egress the service's transport tunnel, and the other is a backup egress
router which hosts "backup service instances". 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 a protector mode in this document, the backup egress router serves as
protector, and hence each backup service instance acts as a the protector, and hence the backup service instance acts as the
protection instance. In the "centralized" protector mode protection service instance. In the "centralized" protector mode
(Section 5.12), a protector and a backup egress router are decoupled, (Section 5.12), the protector and the backup egress router are
and each protection service instance and its corresponding backup decoupled, and the protection service instance and the backup service
service instance are hosted on separate 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, when a sub-LSP can be viewed as a P2P tunnel. multipoint) tunnels, if a sub-LSP can be viewed as a P2P tunnel.
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, and set of components, including a service instance, a service label, and
a service label distribution protocol, and the service is transported a service label distribution protocol, and the service is transported
over an MPLS tunnel of any type. The framework also assumes service over an MPLS tunnel of any type. The framework also assumes service
labels to be downstream assigned, i.e. assigned by egress routers. labels to be downstream assigned, i.e. assigned by egress routers.
Therefore, the framework is generally applicable to most existing and Therefore, the framework is generally applicable to most existing and
future services. Services which use upstream-assigned service labels future services. Services which use upstream-assigned service labels
are out of scope of this document and left for further study. are out of scope of this document and left for future study.
The framework does not require extensions for the existing signaling The framework does not require extensions for the existing signaling
and label distribution protocols (e.g. RSVP, LDP, BGP, etc.) of MPLS and label distribution protocols (e.g. RSVP, LDP, BGP, etc.) of MPLS
tunnels. It expects transport tunnels and bypass tunnels to be tunnels. It expects transport tunnels and bypass tunnels to be
established by using the generic mechanisms provided by the established by using the generic mechanisms provided by the
protocols. On the other hand, it does not preclude future extensions protocols. On the other hand, it does not preclude extensions to the
to the protocols which may facilitate the procedures. One example of protocols which may facilitate the procedures. One example of such
such extension is [RSVP-EP]. The framework may need extensions for extension is [RFC 8400]. The framework may need extensions for IGPs
IGPs and service label distribution protocols, to support protection and service label distribution protocols, to support protection
establishment and context label switching. This document provides establishment and context label switching. This document provides
guidelines for these extensions, but the specific details SHOULD be guidelines for these extensions, but the specific details SHOULD be
addressed in separate documents. addressed in separate documents.
The framework is intended to complement control-plane convergence and The framework is intended to complement control-plane convergence and
global repair, which are traditionally used to recover networks from global repair, which are traditionally used to recover networks from
egress node and egress link failures. Control-plane convergence egress node and egress link failures. Control-plane convergence
relies on control protocols to react on the topology changes due to a relies on control protocols to react on the topology changes due to a
failure. Global repair relies an ingress router to remotely detect a failure. Global repair relies an ingress router to remotely detect a
failure and switch traffic to an alternative path. An example of failure and switch traffic to an alternative path. An example of
global repair is the BGP Prefix Independent Convergence mechanism global repair is the BGP Prefix Independent Convergence mechanism
[BGP-PIC] for BGP established services. Compared with these [BGP-PIC] for BGP established services. Compared with these
mechanisms, this framework is considered as faster in traffic mechanisms, this framework is considered as faster in traffic
restoration, due to the nature of local failure detection and local restoration, due to the nature of local failure detection and local
repair. However, it is RECOMMENDED that the framework SHOULD be used repair. However, it is RECOMMENDED that the framework SHOULD be used
in conjunction with control-plane convergence or global repair, in in conjunction with control-plane convergence or global repair, in
order to take the advantages of both approaches to achieve more order to take the advantages of both approaches. That is, the
effective protection. That is, the framework provides fast and framework provides fast and temporary repair, and control-plane
temporary repair, and control-plane convergence or global repair convergence or global repair provides ultimate and permanent repair.
provides ultimate and 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. document are to be interpreted as described in RFC2119.
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
skipping to change at page 7, line 44 skipping to change at page 7, line 44
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,
like PLRs in transit link/node protection. It must maintain like PLRs in transit link/node protection. It must maintain
bypass tunnels and bypass forwarding state on a per-transport- bypass tunnels and bypass forwarding state on a per-transport-
tunnel basis, rather than per-service-destination or per-service- tunnel basis, rather than per-service-destination or per-service-
label basis. It should also support bypass tunnel sharing between label basis. It should also support bypass tunnel sharing between
transport tunnels. 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 and/or TE topology to compute or resolve a path for a routing and/or TE topology to compute or resolve a path for a
bypass tunnel to a protector. bypass 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.
skipping to change at page 10, line 10 skipping to change at page 10, line 10
routers. 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 rerouted service packets packets. The protector in turn forwards the rerouted service packets
towards the ultimate service destinations. Specifically, it performs towards the ultimate service destinations. Specifically, it performs
context label switching for MPLS service packets, based on service context label switching for MPLS service packets, based on the
labels assigned by the protected egress router; It performs context service labels which are assigned by the protected egress router; It
IP forwarding for IP service packets, based on their destination performs context IP forwarding for IP service packets, based on their
addresses. destination 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 requires that each service destination MUST node failure. This also requires that each service destination MUST
be dual-homed or have dual paths to the egress router and a backup be 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
forwarding state for context label switching and/or context IP 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 Hence, the tunnel and services are considered as being "associated"
protected egress {E, P}. with the 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 same 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
skipping to change at page 11, line 46 skipping to change at page 11, line 46
5.6. Egress-protection bypass tunnel 5.6. Egress-protection bypass tunnel
An egress-protected tunnel destined for a protected egress {E, P} An egress-protected tunnel destined for a protected egress {E, P}
MUST have a bypass tunnel from its PLR to the protector P. This MUST have a bypass tunnel from its PLR to 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}. However, due to its bypass nature, it MUST be resolved egress {E, P}. However, due to its bypass nature, it MUST be resolved
and established with P as the physical tailend and E as the node to and established with P as the physical tailend and E as the node to
avoid. The bypass tunnel MUST have the property that it MUST NOT be avoid. The bypass tunnel MUST have the property that it MUST NOT be
affected by any topology change caused by an egress node failure. affected by the 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}. For multiple egress-protected tunnels common protected egress {E, P}. For multiple egress-protected tunnels
associated with a common protected egress {E, P}, there may be one or associated with a common protected egress {E, P}, there may be one or
multiple egress-protection bypass tunnels from one or multiple PLRs multiple egress-protection bypass tunnels from one or multiple PLRs
to the protector P, depending on the paths of the egress-protected to the protector P, depending on the paths of the egress-protected
tunnels. tunnels.
skipping to change at page 12, line 23 skipping to change at page 12, line 23
in context label switching and context IP forwarding on the in context label switching and context IP forwarding on the
protector. It is an IP address that is logically owned by both the protector. It is an IP address that is logically owned by both the
egress router and the protector. For the egress node, it indicates egress router and the protector. For the egress node, it indicates
the protector. For the protector, it indicates the egress router, the protector. For the protector, it indicates the egress router,
particularly the egress router's forwarding context. For other particularly the egress router's forwarding context. For other
routers in the network, it is an address reachable via both the routers in the network, it is an address reachable via both the
egress router and the protector in the routing domain and the TE egress router and the protector in the routing domain and the TE
domain (Section 5.8), similar to an anycast address. domain (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 in setting up egress protection. egress router, PLR and protector to set up egress protection. Given
Given an egress-protected service associated with a protected egress an egress-protected service associated with a protected egress {E,
{E, P}, its context ID is used as below: P}, its context ID is used as below:
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
router, E also attaches the context ID to the advertisement router, E also attaches the context ID to the advertisement
message. How the context ID is encoded in the messages is a message. How the context ID is encoded in the messages is a
choice of the service protocol, and may need protocol extensions choice of the service protocol. It may need protocol extensions
to define a "context ID" object. to define a "context ID" object, if there is no existing object
that can be used for this purpose.
o The ingress router uses the context ID as destination to establish o The ingress router uses the context ID as a destination to
or resolve an egress-protected tunnel. The ingress router then establish or resolve an egress-protected tunnel. The ingress
maps the service to the tunnel for transportation. In this router then maps the service to the tunnel for transportation. In
process, the special semantics of the context ID is transparent to this process, 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, and behaves in the same manner as in as an IP address of E, and behaves in the same manner as
establishing or resolving a regular transport tunnel, although the establishing or resolving a regular transport tunnel, although the
end result is an egress-protected tunnel. result should be an egress-protected 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 or a dedicated IP address o P maintains a dedicated label space or a dedicated IP address
space for E, depending on whether the service is MPLS or IP. This space for E, depending on whether the service is MPLS or IP. This
is referred to as "E's label space" or "E's IP address space", is referred to as "E's label space" or "E's IP address space",
respectively. P uses the context ID to identify the space. respectively. P uses the context ID to identify the 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
message that E advertises to the ingress router, attached with the message that E advertises to the ingress router, which is attached
context ID. Based on the context ID, P installs the service label with the context ID. Based on the context ID, P installs the
in an MPLS forwarding table corresponding to E's label space. If service label in an MPLS forwarding table corresponding to E's
the service is an IP service, P installs an IP route in an IP label space. If the service is an IP service, P installs an IP
forwarding table corresponding to E's IP address space. In either route in an IP forwarding table corresponding to E's IP address
case, the protection service instance on P interprets the service space. In either case, the protection service instance on P
and constructs forwarding state for the route based on P's own interprets the service and constructs forwarding state for the
connectivity to the service's destination. route based on P's own 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 at 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 top label. P first pops bypass tunnel have the context label as the top label. P first
the context label. For an MPLS service packet, P further looks up pops the context label. For an MPLS service packet, P further
the service label in E's label space indicated by the context looks up the service label in E's label space indicated by the
label, which is called context label switching. For an IP service context label, which is called context label switching. For an IP
packet, P looks up the IP destination address in E's IP address service packet, P looks up the IP destination address in E's IP
space indicated by the context label, which is called context IP address space indicated by the context label, which is called
forwarding. context IP forwarding.
5.8. Advertisement and path resolution for context ID 5.8. Advertisement and path resolution for context ID
Path resolution and computation for a context ID are done on ingress Path resolution and computation for a context ID are done on ingress
routers for egress-protected tunnels, and on PLRs for egress- routers for egress-protected tunnels, and on PLRs for egress-
protection bypass tunnels. Given a protected egress {E, P} and its protection bypass tunnels. Given a protected egress {E, P} and its
context ID, E and P MUST coordinate the context ID in the routing context ID, E and P MUST coordinate the context ID in the routing
domain and the TE domain via IGP advertisement. The context ID MUST domain and the TE domain via IGP advertisement. 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 have have E as tailend, and all egress-protection bypass tunnels MUST have
skipping to change at page 14, line 25 skipping to change at page 14, line 25
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 link
between the proxy node and E having more preferable IGP and TE between the proxy node and E having more preferable IGP and TE
metrics than the link between the proxy node and P. Therefore, metrics than the link between the proxy node and P. Therefore,
all egress-protected tunnels destined for the context ID should all egress-protected tunnels destined for the context ID should
automatically follow the shortest IGP or TE paths to E. Each PLR automatically follow the IGP or TE paths to E. Each PLR will no
will no longer view itself as a penultimate-hop, but rather two longer view itself as a penultimate-hop, but rather two hops away
hops away from the proxy node, via E. The PLR will be able to from the proxy node, via E. The PLR will be able to find a
find a bypass path via P to the proxy node, while the bypass bypass path via P to the proxy node, while the bypass tunnel
tunnel should actually be terminated by P. should 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 a protection schema. E simply advertises the context ID as a
regular IP address. P advertises the context ID and the context regular IP address. P advertises the context ID and the context
label by using a "context ID label binding" advertisement. The label by 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.
This ensures that all egress-protected tunnels destined for the This ensures that all egress-protected tunnels destined for the
context ID should have E as tailend. Based on the "context ID context ID should have E as tailend. Based on the "context ID
label binding" advertisement, the PLR can establish an egress- label 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 [SR-ARCH], [SR-OSPF] and [SR-ISIS]. mirroring context segment in [SR-ARCH], [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 stub network, both E and P advertise the context ID as a link to a stub
essentially modelling the context ID as an any-cast IP address network, essentially modelling the context ID as an any-cast IP
owned by the two routers. E, P and the PLR do not need to have address owned by the two routers. E, P and the PLR do not need
the knowledge of the egress protection schema. The correctness to have the knowledge of the egress protection schema. The
of the egress-protected tunnels to E and the bypass tunnels from correctness of the egress-protected tunnels and the bypass
the PLR to P relies on the path computations for the any-cast IP tunnels relies on the path computations for the any-cast 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
given network topology. given network topology.
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 from inter-AS tunnel, its associated context ID MUST be propagated from
the residing area/AS to the other areas/AS' via IGP or BGP, so that the original area/AS to other areas/AS' via IGP or BGP, so that the
the ingress router of the tunnel can have the reachability to the ingress router of the tunnel can have the reachability to the context
context ID. The propagation process of the context ID SHOULD be the ID. The propagation process of the context ID SHOULD be the same as
same as that of a regular IP address in an inter-area/AS environment. that of a regular IP address in an inter-area/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-based
skipping to change at page 15, line 51 skipping to change at page 15, line 51
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, and others. 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 via the service packets received on the egress-protected tunnels via the
skipping to change at page 16, line 31 skipping to change at page 16, line 31
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 a stack of SID protected tunnel to a context label, and pushing a 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
As mentioned in previous sections, when a protector receives a When a protector receives a rerouted MPLS service packet, it performs
rerouted MPLS service packet, it performs context label switching context label switching based on the packet's service label which is
based on the packet's service label which is assigned by the assigned by the corresponding egress router. In order to achieve
corresponding egress router. In order to achieve this, the protector this, the protector MUST maintain such kind of service labels in
MUST maintain such kind of service labels in dedicated label spaces dedicated label spaces on a per protected egress {E, P} basis, i.e.
on a per protected egress {E, P} basis, i.e. one label space for each one label space for each egress router that it protects.
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 corresponding ingress router, attached with a advertises to the service's ingress router, which is attached with a
context ID. The corresponding protection service instance on the context ID. The corresponding protection service instance on the
protector recognizes the service, and resolves forwarding state based protector recognizes the service, and resolves forwarding state based
on its own connectivity with the service's destination. It then on its own connectivity with the service's destination. It then
installs the service label with the forwarding state in the label installs the service label with the forwarding state in the label
space of the egress router, which is indicated by the context ID space of the egress router, which is indicated by the context ID
(i.e. context label). (i.e. context label).
Different service protocols may use different mechanisms for such Different service protocols may use different mechanisms for such
kind of label distribution. Specific protocol extensions may be kind of label distribution. Specific protocol extensions may be
needed on a per-protocol basis or per-service-type basis. The needed on a per-protocol basis or per-service-type basis. The
details of the extensions SHOULD be specified in separate documents. details of the extensions SHOULD be specified in separate documents.
As an example, RFC 8104 specifies the LDP extensions for pseudowire As an example, [RFC 8104] specifies the LDP extensions for pseudowire
services. 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 the scenario where a protector and procedures in this section assume that a protector and a backup
a backup egress router are decoupled. egress router are decoupled.
services 1, ..., N services 1, ..., N
=====================================> tunnel =====================================> tunnel
I ------ R1 ------- PLR --------------- E ---- I ------ R1 ------- PLR --------------- E ----
ingress penultimate-hop egress \ ingress penultimate-hop egress \
| . (primary \ | . (primary \
| . service \ | . service \
| . instances) \ | . instances) \
| . \ | . \
skipping to change at page 19, line 12 skipping to change at page 19, line 12
protector associates the egress-protected service with the backup protector associates the egress-protected service with the backup
service, resolves or establishes a transport tunnel to the backup service, resolves or establishes a transport tunnel to the backup
egress router, and accordingly sets up forwarding state for the label egress router, and accordingly sets up forwarding state for the label
of the egress-protected service in the label space of the egress of the egress-protected service in the label space of the egress
router. router.
The service label which the backup egress router advertises to the The service label which the backup egress router advertises to the
protector can be the same as the label which the backup egress router protector can be the same as the label which the backup egress router
advertises to the ingress router(s), if and only if the forwarding advertises to the ingress router(s), if and only if the forwarding
state of the label does not direct service packets towards the state of the label does not direct service packets towards the
protected egress router. Otherwise, the label is not usable for protected egress router. Otherwise, the label cannot be used for
egress protection, because it will create a loop, which MUST be egress protection, because it will create a loop for the service
avoided. In this case, the backup egress router MUST advertise a packets. In this case, the backup egress router MUST advertise a
unique service label for egress protection, and set its forwarding unique service label for egress protection, and set up the forwarding
state to use the backup egress router's connectivity with the service state of the label to use the backup egress router's own connectivity
destination. with the service destination.
6. Egress link protection 6. Egress link protection
Egress link protection is achievable through procedures similar to Egress link protection is achievable through procedures similar to
that of egress node protection. In normal situations, an egress that of egress node protection. In normal situations, an egress
router forwards service packets to a service destination based on a router forwards service packets to a service destination based on a
service label, whose forwarding state points to an egress link. In service label, whose forwarding state points to an egress link. In
egress link protection, the egress router acts as PLR, by performing egress link protection, the egress router acts as the PLR, and
local failure detection and local repair. Specifically, the egress performs local failure detection and local repair. Specifically, the
router pre-establishes an egress-protection bypass tunnel to a egress router pre-establishes an egress-protection bypass tunnel to a
protector, and installs bypass forwarding state for the service protector, and sets up the bypass forwarding state for the service
label, pointing to the bypass tunnel. During local repair, the label to point to the bypass tunnel. During local repair, the egress
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 \
skipping to change at page 21, line 33 skipping to change at page 21, line 33
R3 --------------- P ---- R3 --------------- P ----
protector backup egress protector backup egress
(protection (backup (protection (backup
service service service service
instance) instance) instance) instance)
Figure 4 Figure 4
There are two approaches to set up the bypass forwarding state on the There are two approaches to set up the bypass forwarding state on the
egress router, depending on whether the egress router knows the egress router, depending on whether the egress router knows the
service label advertised by the backup egress router. The difference service label allocated by the backup egress router. The difference
is that one approach requires the protector to perform context label is that one approach requires the protector to perform context label
switching, and the other one does not. Both approaches are equally switching, and the other one does not. Both approaches are equally
supported by this framework, and may be used in parallel. supported by this framework, and may be used in parallel.
(1) The first approach applies when the egress router does not (1) The first approach applies when the egress router does not
know the service label advertised by the backup egress router. In know the service label allocated by the backup egress router. In
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 {E, P} and established as described in for the context ID of the {E, P} and established as described in
Section 5.9. This approach is consistent with egress node Section 5.9. This approach is consistent with egress node
protection. Hence, a protector can serve in egress node and protection. Hence, a protector can serve in egress node
egress link protection in a consistent manner, and both the co- protection and egress link protection in a consistent manner, and
located protector mode and the centralized protector mode may be both the co-located protector mode and the centralized protector
used (Figure-3 and Figure-4). mode may be used (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 advertised by the backup egress route, 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 regardless of the protector of egress node protection, which
should be the same router in the co-located protector mode but may should be the same router in the co-located protector mode but a
be a different router in the centralized protector mode. The different router in the centralized protector mode. The egress
egress router sets up the bypass forwarding state as a label swap router sets up the bypass forwarding state as a label swap from
from the incoming service label to the service label of the the incoming service label to the service label of the backup
protector, followed by a push with the outgoing label (or label egress router (i.e. protector), followed by a push with the
stack) of the egress link protection bypass tunnel. The bypass outgoing label (or label stack) of the egress link protection
tunnel is a regular tunnel destined for an IP address of the bypass tunnel. The bypass tunnel is a regular tunnel destined for
protector, instead of the context ID of the {E, P}. The protector an IP address of the protector, instead of the context ID of the
simply forwards rerouted service packets based on its own service {E, P}. The protector simply forwards rerouted service packets
label, rather than performing context label switching. With this based on its own service label, rather than performing context
approach, only the co-located protector mode is applicable. label switching. In this approach, only the co-located protector
mode is applicable.
Note that for a bidirectional service, the physical link of an egress Note that for a bidirectional service, the physical link of an egress
link may carry service traffic bi-directionally. Therefore, an link may carry service traffic 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. However, protection for the traffic in the opposite direction. However, protection for
ingress link failure SHOULD be provided by a separate mechanism, and ingress link failure SHOULD be provided by a separate mechanism, and
hence is out of the scope of this document. hence is out 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, it is RECOMMENDED
that the traffic SHOULD be moved to an alternative tunnel or that the services affected by a failure SHOULD be moved to an
alternative services which are fully functional. This is referred to alternative tunnel, or replaced by alternative services, which are
as global repair. Possible triggers of global repair include control fully functional. This is referred to as global repair. Possible
plane notifications of tunnel and service status, end-to-end OAM and triggers of global repair include control plane notifications of
fault detection at tunnel or service levels, and others. The tunnel and service status, end-to-end OAM and fault detection at
alternative tunnel and services may be pre-established as standby, or tunnel or service level, and others. The alternative tunnel and
dynamically established as a result of the triggers or network services may be pre-established in standby state, or dynamically
protocol convergence. established as a result of the triggers or network protocol
convergence.
8. Example: Layer-3 VPN egress protection 8. 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 26, line 11 skipping to change at page 26, line 11
The framework requires a service label distribution protocol to run The framework requires a service label distribution protocol to run
between an egress router and a protector. The available security between an egress router and a protector. The available security
measures of the protocol MAY be used to achieve a secured session measures of the protocol MAY be used to achieve a secured session
between the two routers. between the two routers.
11. Acknowledgements 11. 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, and Lizhong Jin for their valuable comments Vainshtein, Rolf Winter, Lizhong Jin, and Krzysztof Szarkowicz for
that helped shape this document and improve its clarity. their valuable comments that helped to shape this document and
improve its clarity.
12. References 12. References
12.1. Normative References 12.1. Normative References
[SR-ARCH] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., [SR-ARCH] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing (work in progress), 2017. spring-segment-routing (work in progress), 2017.
[SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H., [SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
skipping to change at page 27, line 15 skipping to change at page 27, line 15
[RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for [RFC7812] Atlas, A., Bowers, C., and G. Enyedi, "An Architecture for
IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT- IP/LDP Fast Reroute Using Maximally Redundant Trees (MRT-
FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016, FRR)", RFC 7812, DOI 10.17487/RFC7812, June 2016,
<https://www.rfc-editor.org/info/rfc7812>. <https://www.rfc-editor.org/info/rfc7812>.
[RFC8104] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang, [RFC8104] Shen, Y., Aggarwal, R., Henderickx, W., and Y. Jiang,
"Pseudowire (PW) Endpoint Fast Failure Protection", "Pseudowire (PW) Endpoint Fast Failure Protection",
RFC 8104, DOI 10.17487/RFC8104, March 2017, RFC 8104, DOI 10.17487/RFC8104, March 2017,
<https://www.rfc-editor.org/info/rfc8104>. <https://www.rfc-editor.org/info/rfc8104>.
[RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang,
"Extensions to RSVP-TE for Label Switched Path (LSP)
Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June
2018, <https://www.rfc-editor.org/info/rfc8400>.
[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-05.txt Independent Convergence", draft-ietf-rtgwg-bgp-pic-07.txt
(work in progress), 2017. (work in progress), 2017.
[RSVP-EP] Chen, H., Liu, A., Saad, T., Xu, F., Huang, L., and N. So,
"Extensions to RSVP-TE for LSP Egress Local Protection",
draft-ietf-teas-rsvp-egress-protection (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
Phone: +1 9785890722 Phone: +1 9785890722
Email: yshen@juniper.net Email: yshen@juniper.net
 End of changes. 48 change blocks. 
173 lines changed or deleted 176 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/