draft-ietf-mpls-egress-protection-framework-00.txt   draft-ietf-mpls-egress-protection-framework-01.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: July 14, 2018 Bruno Decraene Expires: December 24, 2018 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.
January 10, 2018 June 22, 2018
MPLS Egress Protection Framework MPLS Egress Protection Framework
draft-ietf-mpls-egress-protection-framework-00 draft-ietf-mpls-egress-protection-framework-01
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 egress
node failure, and the egress router of the MPLS tunnel acts as the node failure, and the egress router of the MPLS tunnel acts as the
PLR for egress link failure. Each of them pre-establishes a bypass PLR for egress link failure. Each of them pre-establishes a bypass
tunnel to a protector. Upon an egress node or link failure, the tunnel to a protector. Upon an egress node or link failure, the
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 July 14, 2018. This Internet-Draft will expire on December 24, 2018.
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 2, line 43 skipping to change at page 2, line 43
5. Egress node protection . . . . . . . . . . . . . . . . . . . 8 5. Egress node protection . . . . . . . . . . . . . . . . . . . 8
5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8 5.1. Reference topology . . . . . . . . . . . . . . . . . . . 8
5.2. Egress node failure and detection . . . . . . . . . . . . 8 5.2. Egress node failure and detection . . . . . . . . . . . . 8
5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9 5.3. Protector and PLR . . . . . . . . . . . . . . . . . . . . 9
5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 10 5.4. Protected egress . . . . . . . . . . . . . . . . . . . . 10
5.5. Egress-protected tunnel and service . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 15 5.10. Local repair on PLR . . . . . . . . . . . . . . . . . . . 16
5.11. Service label distribution from egress router to 5.11. Service label distribution from egress router to
protector . . . . . . . . . . . . . . . . . . . . . . . . 16 protector . . . . . . . . . . . . . . . . . . . . . . . . 16
5.12. Centralized protector mode . . . . . . . . . . . . . . . 16 5.12. Centralized protector mode . . . . . . . . . . . . . . . 17
6. Egress link protection . . . . . . . . . . . . . . . . . . . 18 6. Egress link protection . . . . . . . . . . . . . . . . . . . 19
7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 21 7. Global repair . . . . . . . . . . . . . . . . . . . . . . . . 22
8. Example: Layer-3 VPN egress protection . . . . . . . . . . . 21 8. Example: Layer-3 VPN egress protection . . . . . . . . . . . 22
8.1. Egress node protection . . . . . . . . . . . . . . . . . 23 8.1. Egress node protection . . . . . . . . . . . . . . . . . 24
8.2. Egress link protection . . . . . . . . . . . . . . . . . 24 8.2. Egress link protection . . . . . . . . . . . . . . . . . 25
8.3. Global repair . . . . . . . . . . . . . . . . . . . . . . 24 8.3. Global repair . . . . . . . . . . . . . . . . . . . . . . 25
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
12.1. Normative References . . . . . . . . . . . . . . . . . . 25 12.1. Normative References . . . . . . . . . . . . . . . . . . 26
12.2. Informative References . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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 should host the
skipping to change at page 14, line 7 skipping to change at page 14, line 7
bypass tunnel have the context label as top label. P first pops bypass tunnel have the context label as top label. P first pops
the context label. For an MPLS service packet, P further looks up the context label. For an MPLS service packet, P further looks up
the service label in E's label space indicated by the context the service label in E's label space indicated by the context
label, which is called context label switching. For an IP service label, which is called context label switching. For an IP service
packet, P looks up the IP destination address in E's IP address packet, P looks up the IP destination address in E's IP address
space indicated by the context label, which is called context IP space indicated by the context label, which is called context IP
forwarding. forwarding.
5.8. Advertisement and path resolution for context ID 5.8. Advertisement and path resolution for context ID
Path resolution are 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. Therefore, given a protected egress {E, protection bypass tunnels. Given a protected egress {E, P} and its
P} and its context ID, E and P MUST coordinate the context ID in the context ID, E and P MUST coordinate the context ID in the routing
routing domain and the TE domain via IGP advertisement. The context domain and the TE domain via IGP advertisement. The context ID MUST
ID MUST be advertised in such a manner that all egress-protected be advertised in such a manner that all egress-protected tunnels MUST
tunnels MUST have E as tailend, and all egress-protection bypass have E as tailend, and all egress-protection bypass tunnels MUST have
tunnels MUST have P as tailend while avoiding E. P as tailend while avoiding E.
This document suggests two 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 shortest IGP or TE paths to E. Each PLR
will no longer view itself as a penultimate-hop, but rather two will no longer view itself as a penultimate-hop, but rather two
skipping to change at page 14, line 47 skipping to change at page 14, line 47
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,
both E and P advertise the context ID as a link to stub 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 to have
the knowledge of the egress protection schema. The correctness
of the egress-protected tunnels to E and the bypass tunnels from
the PLR to P relies on the path computations for the any-cast IP
address performed by the ingress routers and PLR. Therefore,
care MUST be taken for the applicability of this approach to a
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 residing area/AS to the other areas/AS' via IGP or BGP, so that
the ingress router of the tunnel can have the reachability to the the ingress router of the tunnel can have the reachability to the
context ID. The propagation process of the context ID SHOULD be the context 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. same as 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
 End of changes. 11 change blocks. 
27 lines changed or deleted 38 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/