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/