draft-ietf-mpls-egress-protection-framework-02.txt   draft-ietf-mpls-egress-protection-framework-03.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: January 20, 2019 Bruno Decraene Expires: April 23, 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.
July 19, 2018 October 20, 2018
MPLS Egress Protection Framework MPLS Egress Protection Framework
draft-ietf-mpls-egress-protection-framework-02 draft-ietf-mpls-egress-protection-framework-03
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 January 20, 2019. This Internet-Draft will expire on April 23, 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 4, line 51 skipping to change at page 4, line 51
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 future 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 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 [RFC 8400]. 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
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
skipping to change at page 14, line 43 skipping to change at page 14, line 43
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 [RFC8402], [SR-OSPF] and [SR-ISIS].
These IGP extensions are generic in nature, and hence can be used These IGP extensions are generic in nature, and hence can be used
for egress protection purposes. for egress protection purposes.
3. The third approach is called "stub link mode". In this mode, 3. The third approach is called "stub link mode". In this mode,
both E and P advertise the context ID as a link to a stub both E and P advertise the context ID as a link to a stub
network, essentially modelling the context ID as an any-cast IP network, essentially modelling the context ID as an 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
skipping to change at page 17, line 5 skipping to change at page 17, line 5
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, [RFC8104] 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
skipping to change at page 25, line 22 skipping to change at page 25, line 22
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 PE3 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 8.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
skipping to change at page 26, line 19 skipping to change at page 26, line 19
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 12. References
12.1. Normative References 12.1. Normative References
[SR-ARCH] Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- Decraene, B., Litkowski, S., and R. Shakir, "Segment
spring-segment-routing (work in progress), 2017. Routing Architecture", RFC 8402, DOI 10.17487/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.
skipping to change at page 27, line 21 skipping to change at page 27, line 21
"Pseudowire (PW) Endpoint Fast Failure Protection", "Pseudowire (PW) Endpoint Fast Failure Protection",
RFC 8104, DOI 10.17487/RFC8104, March 2017, RFC 8104, DOI 10.17487/RFC8104, March 2017,
<https://www.rfc-editor.org/info/rfc8104>. <https://www.rfc-editor.org/info/rfc8104>.
[RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang, [RFC8400] Chen, H., Liu, A., Saad, T., Xu, F., and L. Huang,
"Extensions to RSVP-TE for Label Switched Path (LSP) "Extensions to RSVP-TE for Label Switched Path (LSP)
Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June Egress Protection", RFC 8400, DOI 10.17487/RFC8400, June
2018, <https://www.rfc-editor.org/info/rfc8400>. 2018, <https://www.rfc-editor.org/info/rfc8400>.
[BGP-PIC] Bashandy, P., Filsfils, C., and P. Mohapatra, "BGP Prefix [BGP-PIC] Bashandy, P., Filsfils, C., and P. Mohapatra, "BGP Prefix
Independent Convergence", draft-ietf-rtgwg-bgp-pic-07.txt Independent Convergence", draft-ietf-rtgwg-bgp-pic-08.txt
(work in progress), 2017. (work in progress), 2017.
Authors' Addresses Authors' Addresses
Yimin Shen Yimin Shen
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
 End of changes. 10 change blocks. 
12 lines changed or deleted 13 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/