< draft-ietf-bess-mvpn-fast-failover-03.txt		draft-ietf-bess-mvpn-fast-failover-04.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: November 5, 2018 Juniper Networks		Expires: May 3, 2019 Juniper Networks
	G. Mirsky, Ed.		G. Mirsky, Ed.
	ZTE Corp.		ZTE Corp.
	May 4, 2018		October 30, 2018
	Multicast VPN fast upstream failover		Multicast VPN fast upstream failover
	draft-ietf-bess-mvpn-fast-failover-03		draft-ietf-bess-mvpn-fast-failover-04
	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 November 5, 2018.		This Internet-Draft will expire on May 3, 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 2, line 44 ¶		skipping to change at page 2, line 44 ¶
	4.1. Downstream PE behavior . . . . . . . . . . . . . . . . . 11		4.1. Downstream PE behavior . . . . . . . . . . . . . . . . . 11
	4.2. Upstream PE behavior . . . . . . . . . . . . . . . . . . 12		4.2. Upstream PE behavior . . . . . . . . . . . . . . . . . . 12
	4.3. Reachability determination . . . . . . . . . . . . . . . 13		4.3. Reachability determination . . . . . . . . . . . . . . . 13
	4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 13		4.4. Inter-AS . . . . . . . . . . . . . . . . . . . . . . . . 13
	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 . . . . . . . . . . . . . . . . . . . . . . 14
	4.4.2. Inter-AS procedures for ASBRs . . . . . . . . . . . . 14		4.4.2. Inter-AS procedures for ASBRs . . . . . . . . . . . . 14
	5. Hot leaf standby . . . . . . . . . . . . . . . . . . . . . . 14		5. Hot leaf standby . . . . . . . . . . . . . . . . . . . . . . 14
	6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 15		6. Duplicate packets . . . . . . . . . . . . . . . . . . . . . . 15
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 15		8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 16		10. Contributor Addresses . . . . . . . . . . . . . . . . . . . . 16
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	11.1. Normative References . . . . . . . . . . . . . . . . . . 18		11.1. Normative References . . . . . . . . . . . . . . . . . . 18
	11.2. Informative References . . . . . . . . . . . . . . . . . 18		11.2. Informative References . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
	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.
	skipping to change at page 8, line 40 ¶		skipping to change at page 8, line 40 ¶
	= Up, the session state will then be used to track the health of the		= Up, the session state will then be used to track the health of the
	P-tunnel.		P-tunnel.
	According to [I-D.ietf-bfd-multipoint], if the Downstream PE receives		According to [I-D.ietf-bfd-multipoint], if the Downstream PE receives
	Down or AdminDown in the State field of the BFD control packet or		Down or AdminDown in the State field of the BFD control packet or
	associated with the BFD session Detection Timer expires, the BFD		associated with the BFD session Detection Timer expires, the BFD
	session state is down, i.e. bfd.SessionState = Down. When the BFD		session state is down, i.e. bfd.SessionState = Down. When the BFD
	session state is Down, then the P-tunnel associated with the BFD		session state is Down, then the P-tunnel associated with the BFD
	session as down MUST be declared down. Then The Downstream PE MAY		session as down MUST be declared down. Then The Downstream PE MAY
	initiate a switchover of the traffic from the Primary Upstream PE to		initiate a switchover of the traffic from the Primary Upstream PE to
			the Standby Upstream PE only if the Standby Upstream PE deemed
			available. The dedicated p2mp BFD session MAY monitor the state of
	the Standby Upstream PE.		the Standby Upstream PE.
	If the Downstream PE's P-tunnel is already up when the Downstream PE		If the Downstream PE's P-tunnel is already up when the Downstream PE
	receives the new x-PMSI A-D Route with BGP-BFD Attribute, the		receives the new x-PMSI A-D Route with BGP-BFD Attribute, the
	Downstream PE MUST accept the x-PMSI A-D Route and associate the		Downstream PE MUST accept the x-PMSI A-D Route and associate the
	value of BFD Discriminator field with the P-tunnel. The Upstream PE		value of BFD Discriminator field with the P-tunnel. The Upstream PE
	MUST follow procedures listed above in this section to bring the p2mp		MUST follow procedures listed above in this section to bring the p2mp
	BFD session up and use it to monitor the state of the associated		BFD session up and use it to monitor the state of the associated
	P-tunnel.		P-tunnel.
	skipping to change at page 10, line 15 ¶		skipping to change at page 10, line 17 ¶
	with included BGP-BFD Attribute so that value of the BFD		with included BGP-BFD Attribute so that value of the BFD
	Discriminator is associated with the new RPF link.		Discriminator is associated with the new RPF link.
	3.1.7.2. Downstream PE Procedures		3.1.7.2. Downstream PE Procedures
	If an S-PMSI A-D route bound to a given C-multicast is signaled with		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		a multipoint BFD session, then the upstream PE is considered during
	UMH selection for the C-multicast if and only if the corresponding		UMH selection for the C-multicast if and only if the corresponding
	BFD session is not in state Down, i.e bfd.SessionState != Down.		BFD session is not in state Down, i.e bfd.SessionState != Down.
	Whenever the state of the BFD session changes to Down the Provider		Whenever the state of the BFD session changes to Down the Provider
	Tunnel will be considered down, and the downstream PE will switch to		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		the backup Provider Tunnel. Note that the Provider Tunnel is
	considered down only for the C-multicast states that match to an		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		S-PMSI A-D route which included BGP-BFD Attribute with the BFD
	Discriminator of the p2mp BFD session which is down.		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 exactly two PEs. The procedures		that contains C-S is connected to exactly two PEs. The procedures
	require all the PEs of that MVPN to follow the single forwarder PE		require all the PEs of that MVPN to follow the single forwarder PE
	skipping to change at page 18, line 17 ¶		skipping to change at page 18, line 18 ¶
	USA		USA
	Email: kanwar.singh@alcatel-lucent.com		Email: kanwar.singh@alcatel-lucent.com
	11. References		11. References
	11.1. Normative References		11.1. Normative References
	[I-D.ietf-bfd-multipoint]		[I-D.ietf-bfd-multipoint]
	Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for		Katz, D., Ward, D., Networks, J., and G. Mirsky, "BFD for
	Multipoint Networks", draft-ietf-bfd-multipoint-16 (work		Multipoint Networks", draft-ietf-bfd-multipoint-18 (work
	in progress), April 2018.		in progress), June 2018.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.		[RFC4875] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S.
	Yasukawa, Ed., "Extensions to Resource Reservation		Yasukawa, Ed., "Extensions to Resource Reservation
	Protocol - Traffic Engineering (RSVP-TE) for Point-to-		Protocol - Traffic Engineering (RSVP-TE) for Point-to-
	Multipoint TE Label Switched Paths (LSPs)", RFC 4875,		Multipoint TE Label Switched Paths (LSPs)", RFC 4875,
End of changes. 9 change blocks.
	9 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/