< draft-ietf-bess-mvpn-fast-failover-12.txt		draft-ietf-bess-mvpn-fast-failover-13.txt >
	Network Working Group T. Morin, Ed.		Network Working Group T. Morin, Ed.
	Internet-Draft Orange		Internet-Draft Orange
	Intended status: Standards Track R. Kebler, Ed.		Intended status: Standards Track R. Kebler, Ed.
	Expires: May 1, 2021 Juniper Networks		Expires: May 14, 2021 Juniper Networks
	G. Mirsky, Ed.		G. Mirsky, Ed.
	ZTE Corp.		ZTE Corp.
	October 28, 2020		November 10, 2020
	Multicast VPN Fast Upstream Failover		Multicast VPN Fast Upstream Failover
	draft-ietf-bess-mvpn-fast-failover-12		draft-ietf-bess-mvpn-fast-failover-13
	Abstract		Abstract
	This document defines multicast VPN extensions and procedures that		This document defines multicast VPN extensions and procedures that
	allow fast failover for upstream failures by allowing downstream PEs		allow fast failover for upstream failures by allowing downstream PEs
	to consider the status of Provider-Tunnels (P-tunnels) when selecting		to consider the status of Provider-Tunnels (P-tunnels) when selecting
	the upstream PE for a VPN multicast flow. The fast failover is		the upstream PE for a VPN multicast flow. The fast failover is
	enabled by using RFC 8562 BFD for Multipoint Networks and the new BGP		enabled by using RFC 8562 BFD for Multipoint Networks and the new BGP
	Attribute - BFD Discriminator. Also, the document introduces a new		Attribute - BFD Discriminator. Also, the document introduces a new
	BGP Community, Standby PE, extending BGP MVPN routing so that a		BGP Community, Standby PE, extending BGP Multicast VPN routing so
	C-multicast route can be advertised toward a Standby Upstream PE.		that a C-multicast route can be advertised toward a Standby Upstream
			PE.
	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 May 1, 2021.		This Internet-Draft will expire on May 14, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 20 ¶		skipping to change at page 2, line 21 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions used in this document . . . . . . . . . . . . . . 3		2. Conventions used in this document . . . . . . . . . . . . . . 3
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
	2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4		2.3. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. UMH Selection Based on Tunnel Status . . . . . . . . . . . . 5		3. UMH Selection Based on Tunnel Status . . . . . . . . . . . . 5
	3.1. Determining the Status of a Tunnel . . . . . . . . . . . 6		3.1. Determining the Status of a Tunnel . . . . . . . . . . . 6
	3.1.1. mVPN Tunnel Root Tracking . . . . . . . . . . . . . . 6		3.1.1. MVPN Tunnel Root Tracking . . . . . . . . . . . . . . 6
	3.1.2. PE-P Upstream Link Status . . . . . . . . . . . . . . 7		3.1.2. PE-P Upstream Link Status . . . . . . . . . . . . . . 7
	3.1.3. P2MP RSVP-TE Tunnels . . . . . . . . . . . . . . . . 7		3.1.3. P2MP RSVP-TE Tunnels . . . . . . . . . . . . . . . . 7
	3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 8		3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 8
	3.1.5. (C-S, C-G) Counter Information . . . . . . . . . . . 8		3.1.5. (C-S, C-G) Counter Information . . . . . . . . . . . 8
	3.1.6. BFD Discriminator Attribute . . . . . . . . . . . . . 8		3.1.6. BFD Discriminator Attribute . . . . . . . . . . . . . 8
	3.1.7. Per PE-CE Link BFD Discriminator . . . . . . . . . . 12		3.1.7. Per PE-CE Link BFD Discriminator . . . . . . . . . . 12
	4. Standby C-multicast Route . . . . . . . . . . . . . . . . . . 12		4. Standby C-multicast Route . . . . . . . . . . . . . . . . . . 12
	4.1. Downstream PE Behavior . . . . . . . . . . . . . . . . . 13		4.1. Downstream PE Behavior . . . . . . . . . . . . . . . . . 13
	4.2. Upstream PE Behavior . . . . . . . . . . . . . . . . . . 14		4.2. Upstream PE Behavior . . . . . . . . . . . . . . . . . . 14
	4.3. Reachability Determination . . . . . . . . . . . . . . . 15		4.3. Reachability Determination . . . . . . . . . . . . . . . 15
	skipping to change at page 3, line 27 ¶		skipping to change at page 3, line 27 ¶
	connected to a receiver site) to take into account the status of		connected to a receiver site) to take into account the status of
	P-tunnels to determine the Upstream Multicast Hop (UMH) for a given		P-tunnels to determine the Upstream Multicast Hop (UMH) for a given
	(C-S, C-G). One of the optional methods uses [RFC8562] and the new		(C-S, C-G). One of the optional methods uses [RFC8562] and the new
	BGP Attribute - BFD Discriminator. None of these methods provide a		BGP Attribute - BFD Discriminator. None of these methods provide a
	"fast failover" solution when used alone, but can be used together		"fast failover" solution when used alone, but can be used together
	with the mechanism described in Section 4 for a "fast failover"		with the mechanism described in Section 4 for a "fast failover"
	solution.		solution.
	Section 4 describes an optional BGP extension, a new Standby PE		Section 4 describes an optional BGP extension, a new Standby PE
	Community. that can speed up failover by not requiring any multicast		Community. that can speed up failover by not requiring any multicast
	VPN routing message exchange at recovery time.		VPN (MVPN) routing message exchange at recovery time.
	Section 5 describes a "hot leaf standby" mechanism that can be used		Section 5 describes a "hot leaf standby" mechanism that can be used
	to improve failover time in MVPN. The approach combines mechanisms		to improve failover time in MVPN. The approach combines mechanisms
	defined in Section 3 and Section 4 has similarities with the solution		defined in Section 3 and Section 4 has similarities with the solution
	described in [RFC7431] to improve failover times when PIM routing is		described in [RFC7431] to improve failover times when PIM routing is
	used in a network given some topology and metric constraints.		used in a network given some topology and metric constraints.
	The procedures described in this document are optional to enable an		The procedures described in this document are optional to enable an
	operator to provide protection for multicast services in BGP/MPLS IP		operator to provide protection for multicast services in BGP/MPLS IP
	VPNs. An operator would enable these mechanisms using a method		VPNs. An operator would enable these mechanisms using a method
	skipping to change at page 6, line 46 ¶		skipping to change at page 6, line 46 ¶
	Depending on the criteria used to determine the status of a P-tunnel,		Depending on the criteria used to determine the status of a P-tunnel,
	there may be an interaction with another resiliency mechanism used		there may be an interaction with another resiliency mechanism used
	for the P-tunnel itself, and the UMH update may happen immediately or		for the P-tunnel itself, and the UMH update may happen immediately or
	may need to be delayed. Each particular case is covered in each		may need to be delayed. Each particular case is covered in each
	separate sub-section below.		separate sub-section below.
	An implementation may support any combination of the methods		An implementation may support any combination of the methods
	described in this section and provide a network operator with control		described in this section and provide a network operator with control
	to choose which one to use in the particular deployment.		to choose which one to use in the particular deployment.
	3.1.1. mVPN Tunnel Root Tracking		3.1.1. MVPN Tunnel Root Tracking
	A condition to consider that the status of a P-tunnel is Up is that		A condition to consider that the status of a P-tunnel is Up is that
	the root of the tunnel, as determined in the x-PMSI Tunnel attribute,		the root of the tunnel, as determined in the x-PMSI Tunnel attribute,
	is reachable through unicast routing tables. In this case, the		is reachable through unicast routing tables. In this case, the
	downstream PE can immediately update its UMH when the reachability		downstream PE can immediately update its UMH when the reachability
	condition changes.		condition changes.
	That is similar to BGP next-hop tracking for VPN routes, except that		That is similar to BGP next-hop tracking for VPN routes, except that
	the address considered is not the BGP next-hop address, but the root		the address considered is not the BGP next-hop address, but the root
	address in the x-PMSI Tunnel attribute.		address in the x-PMSI Tunnel attribute.
End of changes. 8 change blocks.
	9 lines changed or deleted		10 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/