draft-ietf-mpls-egress-protection-framework-03.txt   draft-ietf-mpls-egress-protection-framework-04.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: April 23, 2019 Bruno Decraene Expires: July 6, 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.
October 20, 2018 January 2, 2019
MPLS Egress Protection Framework MPLS Egress Protection Framework
draft-ietf-mpls-egress-protection-framework-03 draft-ietf-mpls-egress-protection-framework-04
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 an of an MPLS tunnel acts as the point of local repair (PLR) for an
egress node failure, and the egress router of the MPLS tunnel acts as egress node failure, and the egress router of the MPLS tunnel acts as
the PLR for an egress link failure. Each of them pre-establishes a the PLR for an egress link failure. Each of them pre-establishes a
bypass tunnel to a protector. Upon an egress node or link failure, bypass tunnel to a protector. Upon an egress node or link failure,
skipping to change at page 2, line 10 skipping to change at page 2, line 10
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 April 23, 2019. This Internet-Draft will expire on July 6, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 5 2. Specification of Requirements . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Egress node protection . . . . . . . . . . . . . . . . . . . 8 5. Egress node protection . . . . . . . . . . . . . . . . . . . 8
5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8 5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8
5.2. Egress node failure and detection . . . . . . . . . . . . 8 5.2. Egress node failure and detection . . . . . . . . . . . . 9
5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9 5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9
5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 10 5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 10
5.5. Egress-protected tunnel and service . . . . . . . . . . . 11 5.5. Egress-protected tunnel and service . . . . . . . . . . . 11
5.6. Egress-protection bypass tunnel . . . . . . . . . . . . . 11 5.6. Egress-protection bypass tunnel . . . . . . . . . . . . . 11
5.7. Context ID, context label, and context based forwarding . 12 5.7. Context ID, context label, and context based forwarding . 12
5.8. Advertisement and path resolution for context ID . . . . 14 5.8. Advertisement and path resolution for context ID . . . . 14
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. Example: Layer-3 VPN egress protection . . . . . . . . . . . 22 8. General context-based forwarding . . . . . . . . . . . . . . 22
8.1. Egress node protection . . . . . . . . . . . . . . . . . 24 9. Example: Layer-3 VPN egress protection . . . . . . . . . . . 23
8.2. Egress link protection . . . . . . . . . . . . . . . . . 25 9.1. Egress node protection . . . . . . . . . . . . . . . . . 24
8.3. Global repair . . . . . . . . . . . . . . . . . . . . . . 25 9.2. Egress link protection . . . . . . . . . . . . . . . . . 25
9.3. Global repair . . . . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 9.4. Other modes of VPN label allocation . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 26 13.1. Normative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 13.2. Informative References . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28
1. Introduction 1. Introduction
In MPLS networks, label switched paths (LSPs) are widely used as In MPLS networks, label switched paths (LSPs) are widely used as
transport tunnels to carry IP and MPLS services across MPLS domains. transport tunnels to carry IP and MPLS services across MPLS domains.
Examples of MPLS services are layer-2 VPNs, layer-3 VPNs, Examples of MPLS services are layer-2 VPNs, layer-3 VPNs,
hierarchical LSPs, and others. In general, a tunnel may carry hierarchical LSPs, and others. In general, a tunnel may carry
multiple services of one or multiple types, if the tunnel 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 hosts the service services. The egress router of the tunnel hosts the service
skipping to change at page 4, line 42 skipping to change at page 4, line 44
multipoint), MP2P (multipoint-to-point) and MP2MP (multipoint-to- multipoint), MP2P (multipoint-to-point) and MP2MP (multipoint-to-
multipoint) tunnels, if 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. However, there are services with certain modes,
are out of scope of this document and left for future study. where a protector is unable to pre-establish forwarding state for
egress protection, or a PLR is prohibited from rerouting traffic to
any other router to avoid traffic duplication, e.g. the broadcast,
multicast, and unknown unicast traffic in VPLS and EVPN. These cases
are left for future study. Services which use upstream-assigned
service labels are also 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 extensions to the protocols. On the other hand, it does not preclude extensions to the
protocols which may facilitate the procedures. One example of such protocols which may facilitate the procedures. One example of such
extension is [RFC8400]. The framework may need extensions for IGPs extension is [RFC8400]. The framework may need extensions for 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
skipping to change at page 5, line 29 skipping to change at page 5, line 37
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. That is, the order to take the advantages of both approaches. That is, the
framework provides fast and temporary repair, and control-plane framework provides fast and temporary repair, and control-plane
convergence or global repair provides ultimate and permanent repair. convergence or global 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] and
[RFC8174].
3. Terminology 3. Terminology
Egress router - A router at the egress endpoint of a tunnel. It Egress router - A router at the egress endpoint of a tunnel. It
hosts service instances for all the services carried by the tunnel, hosts service instances for all the services carried by the tunnel,
and has connectivity with the destinations of the services. and has connectivity with the destinations of the services.
Egress node failure - A failure of an egress router. Egress node failure - A failure of an egress router.
Egress link failure - A failure of the egress link (e.g. PE-CE link, Egress link failure - A failure of the egress link (e.g. PE-CE link,
skipping to change at page 7, line 27 skipping to change at page 7, line 34
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 generic solution for environments where others. It must provide a general solution for environments where
different types of services and tunnels may co-exist. different types of services and tunnels may 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,
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-
skipping to change at page 15, line 9 skipping to change at page 15, line 19
both E and P advertise the context ID as a link to a stub both E and P advertise the context ID as a link to a stub
network, essentially modelling the context ID as an any-cast IP network, essentially modelling the context ID as an any-cast IP
address owned by the two routers. E, P and the PLR do not need address owned by the two routers. E, P and the PLR do not need
to have the knowledge of the egress protection schema. The to have the knowledge of the egress protection schema. The
correctness of the egress-protected tunnels and the bypass correctness of the egress-protected tunnels and the bypass
tunnels relies on the path computations for the any-cast IP tunnels relies on the path computations for the 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.
This framework considers the approaches as technically equal, and the
feasibility of each approach in a given network as dependent on the
topology, manageability, and available protocols of the network. For
a given context ID, all relevant routers, including primary PE,
protector, and PLR, must support and agree on the chosen approach.
The coordination between these routers can be achieved by
configuration.
In a scenario where an egress-protected tunnel is an inter-area or In a scenario where an egress-protected tunnel is an inter-area or
inter-AS tunnel, its associated context ID MUST be propagated from inter-AS tunnel, its associated context ID MUST be propagated from
the original area/AS to other areas/AS' via IGP or BGP, so that the the original area/AS to other areas/AS' via IGP or BGP, so that the
ingress router of the tunnel can have the reachability to the context ingress router of the tunnel can have the reachability to the context
ID. The propagation process of the context ID SHOULD be the same as ID. The propagation process of the context ID SHOULD be the 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
skipping to change at page 22, line 44 skipping to change at page 22, line 44
that the services affected by a failure SHOULD be moved to an that the services affected by a failure SHOULD be moved to an
alternative tunnel, or replaced by alternative services, which are alternative tunnel, or replaced by alternative services, which are
fully functional. This is referred to as global repair. Possible fully functional. This is referred to as global repair. Possible
triggers of global repair include control plane notifications of triggers of global repair include control plane notifications of
tunnel and service status, end-to-end OAM and fault detection at tunnel and service status, end-to-end OAM and fault detection at
tunnel or service level, and others. The alternative tunnel and tunnel or service level, and others. The alternative tunnel and
services may be pre-established in standby state, or dynamically services may be pre-established in standby state, or dynamically
established as a result of the triggers or network protocol established as a result of the triggers or network protocol
convergence. convergence.
8. Example: Layer-3 VPN egress protection 8. General context-based forwarding
So far this document has been focusing on the cases where service
packets are MPLS or IP packets and protectors perform context label
switching or context IP forwarding. Although this should cover most
common services, it is worth mentioning that the framework is also
applicable to services or sub-modes of services where service packets
are layer-2 packets or encapsulated in non-IP/MPLS formats. The only
specific in these cases is that a protector MUST perform context-
based forwarding based on the layer-2 table or corresponding lookup
table which is indicated by a context ID (i.e. context label).
9. 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 24, line 29 skipping to change at page 24, line 37
pe2.mpls. PE3 sets the route's nexthop to a "protection VRF". This pe2.mpls. PE3 sets the route's nexthop to a "protection VRF". This
protection VRF contains IP routes corresponding to the IP prefixes in protection VRF contains IP routes corresponding to the IP prefixes in
the dual-homed site 2, including 203.0.113.128/26. The nexthops of the dual-homed site 2, including 203.0.113.128/26. The nexthops of
these routes MUST be based on PE3's connectivity with site 2, even if these routes MUST be based on PE3's connectivity with site 2, even if
this connectivity is not the best path in PE3's VRF due to metrics this connectivity is not the best path in PE3's VRF due to metrics
(e.g. MED, local preference, etc.), and MUST NOT use any path (e.g. MED, local preference, etc.), and MUST NOT use any path
traversing PE2. Note that the protection VRF is a logical concept, traversing PE2. Note that the protection VRF is a logical concept,
and it may simply be PE3's own VRF if the VRF satisfies the and it may simply be PE3's own VRF if the VRF satisfies the
requirement. requirement.
8.1. Egress node protection 9.1. Egress node protection
R1, i.e. the penultimate-hop router of the egress-protected tunnel, R1, i.e. the penultimate-hop router of the egress-protected tunnel,
serves as the PLR for egress node protection. Based on the "node serves as the PLR for egress node protection. Based on the "node
protection desired" flag and the destination address (i.e. context ID protection desired" flag and the destination address (i.e. context ID
198.51.100.1) of the tunnel, R1 computes a bypass path to 198.51.100.1) of the tunnel, R1 computes a bypass path to
198.51.100.1 while avoiding PE2. The resulted bypass path is 198.51.100.1 while avoiding PE2. The resulted bypass path is
R1->R2->PE3. R1 then signals the path (i.e. egress-protection bypass R1->R2->PE3. R1 then signals the path (i.e. egress-protection bypass
tunnel), with 198.51.100.1 as destination. 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
skipping to change at page 25, line 10 skipping to change at page 25, line 20
When R1 detects a failure of PE2, it will invoke the above bypass When R1 detects a failure of PE2, it will invoke the above bypass
nexthop to reroute VPN service packets. The packets will have the nexthop to reroute VPN service packets. The packets will have the
label of the bypass tunnel as outer label, and the VPN label 9000 as label of the bypass tunnel as outer label, and the VPN label 9000 as
inner label. When the packets arrive at PE3, they will have the inner label. When the packets arrive at PE3, they will have the
context label 100 as outer label, and the VPN label 9000 as inner context label 100 as outer label, and the VPN label 9000 as inner
label. The context label will first be popped, and then the VPN label. The context label will first be popped, and then the VPN
label will be looked up in the label table pe2.mpls. The lookup will label will be looked up in the label table pe2.mpls. The lookup will
cause the VPN label to be popped, and the IP packets will finally be cause the VPN label to be popped, and the IP packets will finally be
forwarded to site 2 based on the protection VRF. forwarded to site 2 based on the protection VRF.
8.2. Egress link protection 9.2. Egress link protection
PE2 serves as the PLR for egress link protection. It has already PE2 serves as the PLR for egress link protection. It has already
learned the VPN label 10000 from PE3, and hence it uses the approach learned the VPN label 10000 from PE3, and hence it uses the approach
(2) described in Section 6 to set up bypass forwarding state. It (2) described in Section 6 to set up bypass forwarding state. It
signals an egress-protection bypass tunnel to PE3, by using the path signals an egress-protection bypass tunnel to PE3, by using the path
PE2->R3->PE3, and PE3's IP address as destination. After the bypass PE2->R3->PE3, and PE3's IP address as destination. After the bypass
tunnel comes up, PE2 installs a bypass nexthop for the VPN label tunnel comes up, PE2 installs a bypass nexthop for the VPN label
9000. The bypass nexthop is a label swap from the incoming label 9000. The bypass nexthop is a label swap from the incoming label
9000 to the VPN label 10000 of PE3, followed by a label push with the 9000 to the VPN label 10000 of PE3, followed by a label push with the
outgoing label of the bypass tunnel. outgoing label of the bypass tunnel.
When PE2 detects a failure of the egress link, it will invoke the When PE2 detects a failure of the egress link, it will invoke the
above bypass nexthop to reroute VPN service packets. The packets above bypass nexthop to reroute VPN service packets. The packets
will have the label of the bypass tunnel as outer label, and the VPN will have the label of the bypass tunnel as outer label, and the VPN
label 10000 as inner label. When the packets arrive at PE3, the VPN label 10000 as inner label. When the packets arrive at PE3, the VPN
label 10000 will be popped, and the IP packets will be forwarded label 10000 will be popped, and the IP packets will be forwarded
based on the VRF indicated by on the VPN label 10000. based on the VRF indicated by on the VPN label 10000.
8.3. Global repair 9.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 new protocols converge on the new topology. PE1 will choose PE3 as new
entrance to site 2. Before that happens, the VPN traffic has been entrance to site 2. Before that happens, the VPN traffic has been
protected by the above local repair. protected by the above local repair.
9. IANA Considerations 9.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 originates.
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
label allocation mode. In either case, PE3 will have multiple 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
the label routes, so that PE3 will process the redirected packets by
popping a VPN label and performing an IP lookup in the protection
VRF. By using this universal nexthop, PE3 does not need to learn
PE2's VPN label allocation mode or construct a specific nexthop for
each label route in the pe2.mpls table.
10. IANA Considerations
This document has no request for new IANA allocation. This document has no request for new IANA allocation.
10. Security Considerations 11. Security Considerations
The framework in this document relies on fast reroute around a The framework in this document relies on fast reroute around a
network failure. Specifically, service traffic is temporarily network failure. Specifically, service traffic is temporarily
rerouted from a PLR to a protector. In the centralized protector rerouted from a PLR to a protector. In the centralized protector
mode, the traffic is further rerouted from the protector to a backup mode, the traffic is further rerouted from the protector to a backup
egress router. Such kind of fast reroute is planned and anticipated, egress router. Such kind of fast reroute is planned and anticipated,
and hence it should not be viewed as a new security threat. and hence it should not be viewed as a new security threat.
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 12. 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, and Krzysztof Szarkowicz for Vainshtein, Rolf Winter, Lizhong Jin, and Krzysztof Szarkowicz for
their valuable comments that helped to shape this document and their valuable comments that helped to shape this document and
improve its clarity. improve its clarity.
12. References 13. References
12.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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., [SR-OSPF] Psenak, P., Previdi, S., Filsfils, C., Gredler, H.,
Shakir, R., Henderickx, W., and J. Tantsura, "OSPF Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", draft-ietf-ospf-segment- Extensions for Segment Routing", draft-ietf-ospf-segment-
routing-extensions (work in progress), 2017. routing-extensions (work in progress), 2017.
[SR-ISIS] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H., [SR-ISIS] Previdi, S., Filsfils, C., Bashandy, A., Gredler, H.,
Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS Litkowski, S., Decraene, B., and J. Tantsura, "IS-IS
Extensions for Segment Routing", draft-ietf-isis-segment- Extensions for Segment Routing", draft-ietf-isis-segment-
routing-extensions (work in progress), 2017. routing-extensions (work in progress), 2017.
12.2. Informative References 13.2. Informative References
[RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast [RFC4090] Pan, P., Ed., Swallow, G., Ed., and A. Atlas, Ed., "Fast
Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090, Reroute Extensions to RSVP-TE for LSP Tunnels", RFC 4090,
DOI 10.17487/RFC4090, May 2005, DOI 10.17487/RFC4090, May 2005,
<https://www.rfc-editor.org/info/rfc4090>. <https://www.rfc-editor.org/info/rfc4090>.
[RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for
IP Fast Reroute: Loop-Free Alternates", RFC 5286, IP Fast Reroute: Loop-Free Alternates", RFC 5286,
DOI 10.17487/RFC5286, September 2008, DOI 10.17487/RFC5286, September 2008,
<https://www.rfc-editor.org/info/rfc5286>. <https://www.rfc-editor.org/info/rfc5286>.
 End of changes. 21 change blocks. 
32 lines changed or deleted 88 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/