< draft-ietf-bess-mvpn-fast-failover-06.txt		draft-ietf-bess-mvpn-fast-failover-07.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: February 8, 2020 Juniper Networks		Expires: February 21, 2020 Juniper Networks
	G. Mirsky, Ed.		G. Mirsky, Ed.
	ZTE Corp.		ZTE Corp.
	August 7, 2019		August 20, 2019
	Multicast VPN fast upstream failover		Multicast VPN fast upstream failover
	draft-ietf-bess-mvpn-fast-failover-06		draft-ietf-bess-mvpn-fast-failover-07
	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 take into account the status of Provider-Tunnels (P-tunnels) when		to take into account the status of Provider-Tunnels (P-tunnels) when
	selecting the upstream PE for a VPN multicast flow, and extending BGP		selecting the upstream PE for a VPN multicast flow, and extending BGP
	MVPN routing so that a C-multicast route can be advertised toward a		MVPN routing so that a C-multicast route can be advertised toward a
	standby upstream PE.		standby upstream PE.
	skipping to change at page 1, line 46 ¶		skipping to change at page 1, line 46 ¶
	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 February 8, 2020.		This Internet-Draft will expire on February 21, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	skipping to change at page 2, line 33 ¶		skipping to change at page 2, line 33 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. UMH Selection based on tunnel status . . . . . . . . . . . . 3		3. UMH Selection based on tunnel status . . . . . . . . . . . . 3
	3.1. Determining the status of a tunnel . . . . . . . . . . . 4		3.1. Determining the status of a tunnel . . . . . . . . . . . 4
	3.1.1. mVPN tunnel root tracking . . . . . . . . . . . . . . 5		3.1.1. mVPN tunnel root tracking . . . . . . . . . . . . . . 5
	3.1.2. PE-P Upstream link status . . . . . . . . . . . . . . 5		3.1.2. PE-P Upstream link status . . . . . . . . . . . . . . 5
	3.1.3. P2MP RSVP-TE tunnels . . . . . . . . . . . . . . . . 5		3.1.3. P2MP RSVP-TE tunnels . . . . . . . . . . . . . . . . 5
	3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 6		3.1.4. Leaf-initiated P-tunnels . . . . . . . . . . . . . . 6
	3.1.5. (C-S, C-G) counter information . . . . . . . . . . . 6		3.1.5. (C-S, C-G) counter information . . . . . . . . . . . 6
	3.1.6. BFD Discriminator . . . . . . . . . . . . . . . . . . 6		3.1.6. BFD Discriminator . . . . . . . . . . . . . . . . . . 6
	3.1.7. Per PE-CE link BFD Discriminator . . . . . . . . . . 9		3.1.7. Per PE-CE link BFD Discriminator . . . . . . . . . . 9
	4. Standby C-multicast route . . . . . . . . . . . . . . . . . . 10		4. Standby C-multicast route . . . . . . . . . . . . . . . . . . 9
	4.1. Downstream PE behavior . . . . . . . . . . . . . . . . . 11		4.1. Downstream PE behavior . . . . . . . . . . . . . . . . . 10
	4.2. Upstream PE behavior . . . . . . . . . . . . . . . . . . 12		4.2. Upstream PE behavior . . . . . . . . . . . . . . . . . . 11
	4.3. Reachability determination . . . . . . . . . . . . . . . 13		4.3. Reachability determination . . . . . . . . . . . . . . . 12
	4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 13		4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 12
	4.4.1. Inter-AS procedures for downstream PEs, ASBR fast		4.4.1. Inter-AS procedures for downstream PEs, ASBR fast
	failover . . . . . . . . . . . . . . . . . . . . . . 14		failover . . . . . . . . . . . . . . . . . . . . . . 13
	4.4.2. Inter-AS procedures for ASBRs . . . . . . . . . . . . 14		4.4.2. Inter-AS procedures for ASBRs . . . . . . . . . . . . 13
	5. Hot Root Standby . . . . . . . . . . . . . . . . . . . . . . 14		5. Hot Root Standby . . . . . . . . . . . . . . . . . . . . . . 14
	6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 15		6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 14
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 16		8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 16		10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 15
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	11.1. Normative References . . . . . . . . . . . . . . . . . . 18		11.1. Normative References . . . . . . . . . . . . . . . . . . 17
	11.2. Informative References . . . . . . . . . . . . . . . . . 19		11.2. Informative References . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	In the context of multicast in BGP/MPLS VPNs, it is desirable to		In the context of multicast in BGP/MPLS VPNs, it is desirable to
	provide mechanisms allowing fast recovery of connectivity on		provide mechanisms allowing fast recovery of connectivity on
	different types of failures. This document addresses failures of		different types of failures. This document addresses failures of
	elements in the provider network that are upstream of PEs connected		elements in the provider network that are upstream of PEs connected
	to VPN sites with receivers.		to VPN sites with receivers.
	Section 3 describes local procedures allowing an egress PE (a PE		Section 3 describes local procedures allowing an egress PE (a PE
	skipping to change at page 4, line 12 ¶		skipping to change at page 4, line 12 ¶
	to a given upstream PE for a given (C-S, C-G) state is the S-PMSI		to a given upstream PE for a given (C-S, C-G) state is the S-PMSI
	tunnel advertised by that upstream PE for this (C-S, C-G) and		tunnel advertised by that upstream PE for this (C-S, C-G) and
	imported into that VRF, or if there isn't any such S-PMSI, the I-PMSI		imported into that VRF, or if there isn't any such S-PMSI, the I-PMSI
	tunnel advertised by that PE and imported into that VRF.		tunnel advertised by that PE and imported into that VRF.
	There are three options specified in Section 5.1 of [RFC6513] for a		There are three options specified in Section 5.1 of [RFC6513] for a
	downstream PE to select an Upstream PE.		downstream PE to select an Upstream PE.
	o The first two options select the Upstream PE from a candidate PE		o The first two options select the Upstream PE from a candidate PE
	set either based on IP address or a hashing algorithm. When used		set either based on IP address or a hashing algorithm. When used
	together with the optional procedure of considering the P-tunnel		together with the optional procedure of considering the P-tunnel
	status as in this document, a candidate upstream PE is included		status as in this document, a candidate upstream PE is included in
	in the set if it either:		the set if it either:
	o
	A. advertise a PMSI bound to a tunnel, where the specified tunnel		A. advertise a PMSI bound to a tunnel, where the specified tunnel
	is not known to be down or up		is not known to be down or up
	B. do not advertise any x-PMSI applicable to the given (C-S, C-G)		B. do not advertise any x-PMSI applicable to the given (C-S, C-G)
	but have associated a VRF Route Import BGP attribute to the		but have associated a VRF Route Import BGP attribute to the
	unicast VPN route for S (this is necessary to avoid		unicast VPN route for S (this is necessary to avoid
	incorrectly invalidating a UMH PE that would use a policy		incorrectly invalidating a UMH PE that would use a policy
	where no I-PMSI is advertised for a given VRF and where only		where no I-PMSI is advertised for a given VRF and where only
	S-PMSI are used, the S-PMSI advertisement being possibly done		S-PMSI are used, the S-PMSI advertisement being possibly done
	skipping to change at page 4, line 38 ¶		skipping to change at page 4, line 36 ¶
	(C-S, C-G)/(C-*, C-G) to be carried over the advertised		(C-S, C-G)/(C-*, C-G) to be carried over the advertised
	S-PMSI).		S-PMSI).
	If the resulting candidate set is empty, then the procedure is		If the resulting candidate set is empty, then the procedure is
	repeated without considering the P-tunnel status.		repeated without considering the P-tunnel status.
	o The third option uses the installed UMH Route (i.e., the "best"		o The third option uses the installed UMH Route (i.e., the "best"
	route towards the C-root) as the Selected UMH Route, and its		route towards the C-root) as the Selected UMH Route, and its
	originating PE is the selected Upstream PE. With the optional		originating PE is the selected Upstream PE. With the optional
	procedure of considering P-tunnel status as in this document, the		procedure of considering P-tunnel status as in this document, the
	Selected UMH Route is the best one among those whose originating		Selected UMH Route is the best one among those whose originating
	PE's P-tunnel is not "down". If that does not exist, the		PE's P-tunnel is not "down". If that does not exist, the
	installed UMH Route is selected regardless of the P-tunnel		installed UMH Route is selected regardless of the P-tunnel status.
	status.
	3.1. Determining the status of a tunnel		3.1. Determining the status of a tunnel
	Different factors can be considered to determine the "status" of a		Different factors can be considered to determine the "status" of a
	P-tunnel and are described in the following sub-sections. The		P-tunnel and are described in the following sub-sections. The
	optional procedures proposed in this section also allow that all		optional procedures proposed in this section also allow that all
	downstream PEs don't apply the same rules to define what the status		downstream PEs don't apply the same rules to define what the status
	of a P-tunnel is (please see Section 6), and some of them will		of a P-tunnel is (please see Section 6), and some of them will
	produce a result that may be different for different downstream PEs.		produce a result that may be different for different downstream PEs.
	Thus what is called the "status" of a P-tunnel in this section, is		Thus what is called the "status" of a P-tunnel in this section, is
	skipping to change at page 9, line 21 ¶		skipping to change at page 9, line 18 ¶
	o MUST stop processing BFD control packets for this p2mp BFD		o MUST stop processing BFD control packets for this p2mp BFD
	session;		session;
	o SHOULD delete the p2mp BFD session associated with the P-tunnel;		o SHOULD delete the p2mp BFD session associated with the P-tunnel;
	o SHOULD NOT switch the traffic to the Standby Upstream PE.		o SHOULD NOT switch the traffic to the Standby Upstream PE.
	3.1.7. Per PE-CE link BFD Discriminator		3.1.7. Per PE-CE link BFD Discriminator
	The following approach is defined for the fast failover in response		The following approach is defined in response to the detection by the
	to the detection of PE-CE link failures, in which UMH selection for a		upstream PE of PE-CE link failure. Even though the provider tunnel
	given C-multicast route takes into account the state of the BFD		is still up, it is desired for the downstream PEs to switch to a
	session associated with the state of the upstream PE-CE link.		backup upstream PE. To achieve that, if the upstream PE detects that
	According to section 6.8.17 [RFC5880], failure of a PE-CE link MAY be		its PE-CE link fails, it SHOULD set the bfd.LocalDiag of the p2mp BFD
	communicated to the downstream PE by setting the bfd.LocalDiag of the		session to Concatenated Path Down and/or Reverse Concatenated Path
	p2mp BFD session associated with this link to Concatenated Path Down		Down (per section 6.8.17 [RFC5880]), unless it switches to a new PE-
	and/or Reverse Concatenated Path Down. The mechanism to communicate		CE link within the time of bfd.DesiredMinTxInterval for the p2mp BFD
	the mapping between the PE-CE link and the associated BFD session is		session (in that case the upstream PE will start tracking the status
	outside the scope of this document.		of the new PE-CE link). When a downstream PE receives that
			bfd.LocalDiag code, it treats as if the tunnel itself failed and
	3.1.7.1. Upstream PE Procedures		tries to switch to a backup PE.
	For each protected PE-CE link, the upstream PE initiates a multipoint
	BFD session [RFC8562] as MultipointHead toward downstream PEs. A
	downstream PE monitors the state of the p2mp session as
	MultipointTail and MAY interpret the transition of the BFD session
	into Down state as the indication of the associated PE-CE link being
	down.
	For SSM groups, the upstream PE advertises a (C-S, C-G) S-PMSI A-D
	route or wildcard (S,*) S-PMSI A-D route for each received SSM (C-S,
	C-G) C-multicast route for which protection is desired. For each ASM
	(C-S, C-G) C-multicast route for which protection is desired, the
	upstream PE advertises a (C-S, C-G) S-PMSI A-D route. For each ASM
	(*, G) C-Multicast route for which protection is desired, the
	upstream PE advertises a wildcard (*, G) S-PMSI A-D route. Note that
	all S-PMSI A-D routes can signal the same P-tunnel, so there is no
	need for a new P-tunnel for each S-PMSI A-D route. Multicast flows
	for which protection is desired are controlled by configuration/
	policy on the upstream PE. The protected link is the RPF PE-CE
	interface towards the src/RP. The upstream PE advertises the BFD
	Discriminator of the protected link in the S-PMSI A-D route. If the
	route to the src/RP changes such that the RPF interface is changed to
	be a new PE-CE interface, then the upstream PE will update the S-PMSI
	A-D route with included BGP-BFD Attribute so that the previously
	advertised value of the BFD Discriminator is associated with the new
	RPF link.
	3.1.7.2. Downstream PE Procedures
	If an S-PMSI A-D route bound to a given C-multicast is signaled with
	a multipoint BFD session, then the upstream PE is considered during
	UMH selection for the C-multicast if and only if the corresponding
	BFD session is not in state Down, i.e., bfd.SessionState != Down.
	Whenever the state of the BFD session changes to Down the Provider
	Tunnel will be considered down, and the downstream PE MAY switch to
	the backup Provider Tunnel only if the backup Provider Tunnel deemed
	available. The dedicated p2mp BFD session MAY monitor the state of
	the backup Provider Tunnel. Note that the Provider Tunnel is
	considered down only for the C-multicast states that match to an
	S-PMSI A-D route which included BGP-BFD Attribute with the BFD
	Discriminator of the p2mp BFD session which is down.
	4. Standby C-multicast route		4. Standby C-multicast route
	The procedures described below are limited to the case where the site		The procedures described below are limited to the case where the site
	that contains C-S is connected to two or more PEs though, to simplify		that contains C-S is connected to two or more PEs though, to simplify
	the description, the case of dual-homing is described. The		the description, the case of dual-homing is described. The
	procedures require all the PEs of that MVPN to follow the UMH		procedures require all the PEs of that MVPN to follow the UMH
	selection, as specified in [RFC6513], whether the PE selected based		selection, as specified in [RFC6513], whether the PE selected based
	on its IP address, hashing algorithm described in section 5.1.3		on its IP address, hashing algorithm described in section 5.1.3
	[RFC6513], or Installed UMH Route. The procedures assume that if a		[RFC6513], or Installed UMH Route. The procedures assume that if a
End of changes. 11 change blocks.
	81 lines changed or deleted		37 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/