< draft-ietf-bess-evpn-igmp-mld-proxy-19.txt		draft-ietf-bess-evpn-igmp-mld-proxy-20.txt >
	skipping to change at page 1, line 15 ¶		skipping to change at page 1, line 15 ¶
	Intended status: Standards Track M. Mishra		Intended status: Standards Track M. Mishra
	Expires: September 22, 2022 Cisco Systems		Expires: September 22, 2022 Cisco Systems
	K. Patel		K. Patel
	Arrcus		Arrcus
	J. Drake		J. Drake
	W. Lin		W. Lin
	Juniper Networks		Juniper Networks
	March 21, 2022		March 21, 2022
	IGMP and MLD Proxy for EVPN		IGMP and MLD Proxy for EVPN
	draft-ietf-bess-evpn-igmp-mld-proxy-19		draft-ietf-bess-evpn-igmp-mld-proxy-20
	Abstract		Abstract
	This document describes how to support efficiently endpoints running		This document describes how to support efficiently endpoints running
	IGMP(Internet Group Management Protocol) or MLD (Multicast Listener		IGMP(Internet Group Management Protocol) or MLD (Multicast Listener
	Discovery) for the multicast services over an EVPN network by		Discovery) for the multicast services over an EVPN network by
	incorporating IGMP/MLD proxy procedures on EVPN (Ethernet VPN) PEs.		incorporating IGMP/MLD proxy procedures on EVPN (Ethernet VPN) PEs.
	Status of This Memo		Status of This Memo
	skipping to change at page 18, line 21 ¶		skipping to change at page 18, line 21 ¶
	o The include/exclude (IE) bit helps in creating filters for a given		o The include/exclude (IE) bit helps in creating filters for a given
	multicast route.		multicast route.
	o If route is used for IPv6 (MLD) then bit 7 indicates support for		o If route is used for IPv6 (MLD) then bit 7 indicates support for
	MLD version 1. The second least significant bit, bit 6 indicates		MLD version 1. The second least significant bit, bit 6 indicates
	support for MLD version 2. Since there is no MLD version 3, in		support for MLD version 2. Since there is no MLD version 3, in
	case of IPv6 route third least significant bit MUST be 0. In case		case of IPv6 route third least significant bit MUST be 0. In case
	of IPv6 routes, the fourth least significant bit MUST be ignored		of IPv6 routes, the fourth least significant bit MUST be ignored
	if bit 6 is not set.		if bit 6 is not set.
	o Reserved bits MUST be set to 0 by sender. And receiver SHOULD		o Reserved bits MUST be set to 0 by sender. And receiver MUST
	ignore the Reserved bits.		ignore the Reserved bits.
	9.1.1. Constructing the Selective Multicast Ethernet Tag route		9.1.1. Constructing the Selective Multicast Ethernet Tag route
	This section describes the procedures used to construct the Selective		This section describes the procedures used to construct the Selective
	Multicast Ethernet Tag (SMET) route.		Multicast Ethernet Tag (SMET) route.
	The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The		The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. The
	value field comprises an IP address of the PE (typically, the		value field comprises an IP address of the PE (typically, the
	loopback address) followed by a number unique to the PE.		loopback address) followed by a number unique to the PE.
	skipping to change at page 21, line 5 ¶		skipping to change at page 21, line 5 ¶
	Consider the EVPN network of Figure-2, where there is an EVPN		Consider the EVPN network of Figure-2, where there is an EVPN
	instance configured across the PEs. Let's consider that PE2 is		instance configured across the PEs. Let's consider that PE2 is
	connected to multicast router R1 and there is a network running PIM		connected to multicast router R1 and there is a network running PIM
	ASM behind R1. If there are receivers behind the PIM ASM network the		ASM behind R1. If there are receivers behind the PIM ASM network the
	PIM Join would be forwarded to the PIM RP (Rendezvous Point). If		PIM Join would be forwarded to the PIM RP (Rendezvous Point). If
	receivers behind PIM ASM network are interested in a multicast flow		receivers behind PIM ASM network are interested in a multicast flow
	originated by multicast source S2 (behind PE1), it is necessary for		originated by multicast source S2 (behind PE1), it is necessary for
	PE2 to receive multicast traffic. In this case PE2 MUST originate a		PE2 to receive multicast traffic. In this case PE2 MUST originate a
	(*,*) SMET route to receive all of the multicast traffic in the EVPN		(*,*) SMET route to receive all of the multicast traffic in the EVPN
	domain. To generate Wildcards (*,*) routes, the procedure from		domain. To generate Wildcards (*,*) routes, the procedure from
	[RFC6625] SHOULD be used.		[RFC6625] MUST be used.
	9.2. Multicast Membership Report Synch Route		9.2. Multicast Membership Report Synch Route
	This EVPN route type is used to coordinate IGMP Membership Report		This EVPN route type is used to coordinate IGMP Membership Report
	(x,G) state for a given BD between the PEs attached to a given ES		(x,G) state for a given BD between the PEs attached to a given ES
	operating in All- Active (or Single-Active) redundancy mode and it		operating in All- Active (or Single-Active) redundancy mode and it
	consists of following:		consists of following:
	+--------------------------------------------------+		+--------------------------------------------------+
	| RD (8 octets) |		| RD (8 octets) |
	skipping to change at page 32, line 26 ¶		skipping to change at page 32, line 26 ¶
	MLD version-X expectation, the PE MUST apply the "treat-as-withdraw"		MLD version-X expectation, the PE MUST apply the "treat-as-withdraw"
	procedure as per [RFC7606]		procedure as per [RFC7606]
	If a received BGP update is malformed such that BGP route keys cannot		If a received BGP update is malformed such that BGP route keys cannot
	be extracted, then BGP update MUST be considered as invalid.		be extracted, then BGP update MUST be considered as invalid.
	Receiving PE MUST apply the "Session reset" procedure of [RFC7606].		Receiving PE MUST apply the "Session reset" procedure of [RFC7606].
	10. IGMP Version 1 Membership Report		10. IGMP Version 1 Membership Report
	This document does not provide any detail about IGMPv1 processing.		This document does not provide any detail about IGMPv1 processing.
	Multicast working group are in process of deprecating uses of IGMPv1.		Implementations are expected to only use IGMPv2 and above for IPv4
	Implementations MUST only use IGMPv2 and above for IPv4 and MLDv1 and		and MLDv1 and above for IPv6. IGMPv1 routes are considered invalid
	above for IPv6. IGMP V1 routes MUST be considered as invalid and the		and the PE MUST apply the "treat-as-withdraw" procedure as per
	PE MUST apply the "treat-as-withdraw" procedure as per [RFC7606].		[RFC7606].
	Initial version of document did mention use of IGMPv1 and flag had
	provision to support IGMPv1. There may be an implementation which is
	deployed as initial version of document, to interop flag has not been
	changed.
	11. Security Considerations		11. Security Considerations
	This document describes a means to efficiently operate IGMP and MLD		This document describes a means to efficiently operate IGMP and MLD
	on a subnet constructed across multiple PODs or DCs via an EVPN		on a subnet constructed across multiple PODs or DCs via an EVPN
	solution. The security considerations for the operation of the		solution. The security considerations for the operation of the
	underlying EVPN and BGP substrate are described in [RFC7432], and		underlying EVPN and BGP substrate are described in [RFC7432], and
	specific multicast considerations are outlined in [RFC6513] and		specific multicast considerations are outlined in [RFC6513] and
	[RFC6514]. The EVPN and associated IGMP proxy provides a single		[RFC6514]. The EVPN and associated IGMP proxy provides a single
	broadcast domain so the same security considerations of IGMPv2		broadcast domain so the same security considerations of IGMPv2
	skipping to change at page 33, line 25 ¶		skipping to change at page 33, line 25 ¶
	IANA has allocated the following EVPN route types from the EVPN Route		IANA has allocated the following EVPN route types from the EVPN Route
	Type registry.		Type registry.
	6 - Selective Multicast Ethernet Tag Route		6 - Selective Multicast Ethernet Tag Route
	7 - Multicast Membership Report Synch Route		7 - Multicast Membership Report Synch Route
	8 - Multicast Leave Synch Route		8 - Multicast Leave Synch Route
	The Multicast Flags Extended Community contains a 16-bit Flags field.		The Multicast Flags Extended Community contains a 16-bit Flags field.
	The bits are numbered 0-15, from high-order to low-order.		The bits are numbered 0-15, from high-order to low-order.
	The registry should be initialized as follows:		The registry should be initialized as follows:
	Bit Name Reference		Bit Name Reference Change Controller
	---- -------------- -------------		---- -------------- ------------- ------------------
	0 - 13 Unassigned		0 - 13 Unassigned
	14 MLD Proxy Support This document		14 MLD Proxy Support This document. IETF
	15 IGMP Proxy Support This document		15 IGMP Proxy Support This document IETF
	The registration policy should be "First Come First Served".		The registration policy should be "First Come First Served".
	13. Acknowledgement		13. Acknowledgement
	The authors would like to thank Stephane Litkowski, Jorge Rabadan,		The authors would like to thank Stephane Litkowski, Jorge Rabadan,
	Anoop Ghanwani, Jeffrey Haas, Krishna Muddenahally Ananthamurthy,		Anoop Ghanwani, Jeffrey Haas, Krishna Muddenahally Ananthamurthy,
	Swadesh Agrawal for reviewing and providing valuable comment.		Swadesh Agrawal for reviewing and providing valuable comment.
	14. Contributors		14. Contributors
	Derek Yeung		Derek Yeung
End of changes. 6 change blocks.
	18 lines changed or deleted		14 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/