< draft-ietf-bier-mld-03.txt		draft-ietf-bier-mld-04.txt >
	Network Working Group P. Pfister		Network Working Group P. Pfister
	Internet-Draft IJ. Wijnands		Internet-Draft IJ. Wijnands
	Intended status: Standards Track S. Venaas		Intended status: Standards Track S. Venaas
	Expires: May 7, 2020 Cisco Systems		Expires: September 7, 2020 Cisco Systems
	C. Wang		C. Wang
	Z. Zhang		Z. Zhang
	ZTE Corporation		ZTE Corporation
	M. Stenberg		M. Stenberg
	November 4, 2019		March 6, 2020
	BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery		BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery
	Protocols		Protocols
	draft-ietf-bier-mld-03		draft-ietf-bier-mld-04
	Abstract		Abstract
	This document specifies the ingress part of a multicast flow overlay		This document specifies the ingress part of a multicast flow overlay
	for BIER networks. Using existing multicast listener discovery		for BIER networks. Using existing multicast listener discovery
	protocols, it enables multicast membership information sharing from		protocols, it enables multicast membership information sharing from
	egress routers, acting as listeners, toward ingress routers, acting		egress routers, acting as listeners, toward ingress routers, acting
	as queriers. Ingress routers keep per-egress-router state, used to		as queriers. Ingress routers keep per-egress-router state, used to
	construct the BIER bit mask associated with IP multicast packets		construct the BIER bit mask associated with IP multicast packets
	entering the BIER domain.		entering the BIER domain.
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 7, 2020.		This Internet-Draft will expire on September 7, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4		4. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
	5. Querier and Listener Specifications . . . . . . . . . . . . . 4		5. Querier and Listener Specifications . . . . . . . . . . . . . 4
	5.1. Configuration Parameters . . . . . . . . . . . . . . . . 5		5.1. Configuration Parameters . . . . . . . . . . . . . . . . 5
	5.2. MLDv2 instances. . . . . . . . . . . . . . . . . . . . . 6		5.2. MLDv2 instances. . . . . . . . . . . . . . . . . . . . . 6
	5.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 6		5.2.1. Sending Queries . . . . . . . . . . . . . . . . . . . 6
	5.2.2. Sending Reports . . . . . . . . . . . . . . . . . . . 6		5.2.2. Sending Reports . . . . . . . . . . . . . . . . . . . 6
	5.2.3. Receiving Queries . . . . . . . . . . . . . . . . . . 7		5.2.3. Receiving Queries . . . . . . . . . . . . . . . . . . 7
	5.2.4. Receiving Reports . . . . . . . . . . . . . . . . . . 8		5.2.4. Receiving Reports . . . . . . . . . . . . . . . . . . 8
	5.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 8		5.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 8		6. BIER MLD/IGMP Extension Type . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9		7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	9.1. Normative References . . . . . . . . . . . . . . . . . . 9		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	9.2. Informative References . . . . . . . . . . . . . . . . . 10		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
	Appendix A. BIER Use Case in Data Centers . . . . . . . . . . . 11		10.2. Informative References . . . . . . . . . . . . . . . . . 11
	A.1. Convention and Terminology . . . . . . . . . . . . . . . 12		Appendix A. BIER Use Case in Data Centers . . . . . . . . . . . 12
	A.2. BIER in data centers . . . . . . . . . . . . . . . . . . 13		A.1. Convention and Terminology . . . . . . . . . . . . . . . 13
	A.3. A BIER MLD solution for Virtual Network information . . . 13		A.2. BIER in data centers . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		A.3. A BIER MLD solution for Virtual Network information . . . 14
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	The Bit Index Explicit Replication (BIER - [RFC8279]) forwarding		The Bit Index Explicit Replication (BIER - [RFC8279]) forwarding
	technique enables IP multicast transport across a BIER domain. When		technique enables IP multicast transport across a BIER domain. When
	receiving or originating a packet, ingress routers have to construct		receiving or originating a packet, ingress routers have to construct
	a bit mask indicating which BIER egress routers located within the		a bit mask indicating which BIER egress routers located within the
	same BIER domain will receive the packet. A stateless approach would		same BIER domain will receive the packet. A stateless approach would
	consist of forwarding all incoming packets toward all egress routers,		consist of forwarding all incoming packets toward all egress routers,
	which would in turn make a forwarding decision based on local		which would in turn make a forwarding decision based on local
	skipping to change at page 3, line 17 ¶		skipping to change at page 3, line 17 ¶
	This document specifies how to use the Multicast Listener Discovery		This document specifies how to use the Multicast Listener Discovery
	protocol version 2 [RFC3810] (resp. the Internet Group Management		protocol version 2 [RFC3810] (resp. the Internet Group Management
	protocol version 3 [RFC3376]) as the ingress part of a BIER multicast		protocol version 3 [RFC3376]) as the ingress part of a BIER multicast
	flow overlay (BIER layering is described in [RFC8279]) for IPv6		flow overlay (BIER layering is described in [RFC8279]) for IPv6
	(resp. IPv4). It enables multicast membership information sharing		(resp. IPv4). It enables multicast membership information sharing
	from egress routers, acting as listeners, toward ingress routers,		from egress routers, acting as listeners, toward ingress routers,
	acting as queriers. Ingress routers keep per-egress-router state,		acting as queriers. Ingress routers keep per-egress-router state,
	used to construct the BIER bit mask associated with IP multicast		used to construct the BIER bit mask associated with IP multicast
	packets entering the BIER domain.		packets entering the BIER domain.
	This document makes use of an extension to MLDv2 and IGMPv3 specified		This document defines an MLDv2 and IGMPv3 extension type, using the
	in [I-D.venaas-pim-igmp-mld-extension] that allows for providing BIER		extension scheme defined in [I-D.venaas-pim-igmp-mld-extension], that
	specific information about the message originator.		allows for providing BIER specific information about the message
			originator.
	This specification is applicable to both IP version 4 and version 6.		This specification is applicable to both IP version 4 and version 6.
	It therefore specifies two separate mechanisms operating		It therefore specifies two separate mechanisms operating
	independently. For the sake of simplicity, the rest of this document		independently. For the sake of simplicity, the rest of this document
	uses IPv6 terminology. It can be applied to IPv4 by replacing		uses IPv6 terminology. It can be applied to IPv4 by replacing
	'MLDv2' with 'IGMPv3', and following specific requirements when		'MLDv2' with 'IGMPv3', and following specific requirements when
	explicitly stated.		explicitly stated.
	2. Terminology		2. Terminology
	skipping to change at page 6, line 41 ¶		skipping to change at page 6, line 41 ¶
	o With the IP destination address set to the 'all BMLD Nodes' group		o With the IP destination address set to the 'all BMLD Nodes' group
	address.		address.
	o With the IP source address set to the BFR-Prefix of the sender.		o With the IP source address set to the BFR-Prefix of the sender.
	o With a TTL value large enough such that the packet can be received		o With a TTL value large enough such that the packet can be received
	by all BMLD Nodes, depending on the underlying BIER layer (whether		by all BMLD Nodes, depending on the underlying BIER layer (whether
	it decrements the IP TTL or not) and the size of the network. The		it decrements the IP TTL or not) and the size of the network. The
	default value is 64.		default value is 64.
	o The extension defined in [I-D.venaas-pim-igmp-mld-extension] MUST		o The extension defined in Section 6 MUST be included, specifying
	be included, specifying the Sub-domain-id, BFR-id and BFR-Prefix		the Sub-domain-id, BFR-id and BFR-Prefix of the sender. This
	of the sender. This information may be useful for logging and		information may be useful for logging and debugging.
	debugging.
	5.2.2. Sending Reports		5.2.2. Sending Reports
	BMLD Reports are IP packets sent over BIER by BMLD Listeners:		BMLD Reports are IP packets sent over BIER by BMLD Listeners:
	o Toward all BMLD Queriers (i.e., providing to the BIER layer the		o Toward all BMLD Queriers (i.e., providing to the BIER layer the
	BFR-ids of all BMLD Queriers).		BFR-ids of all BMLD Queriers).
	o Without the IPv6 router alert option [RFC2711] in the hop-by-hop		o Without the IPv6 router alert option [RFC2711] in the hop-by-hop
	extension header [RFC8200] (or the IPv4 router alert option		extension header [RFC8200] (or the IPv4 router alert option
	skipping to change at page 7, line 19 ¶		skipping to change at page 7, line 19 ¶
	o With the IP destination address set to the 'all BMLD Queriers'		o With the IP destination address set to the 'all BMLD Queriers'
	group address.		group address.
	o With the IP source address set to the BFR-Prefix of the sender.		o With the IP source address set to the BFR-Prefix of the sender.
	o With a TTL value large enough such that the packet can be received		o With a TTL value large enough such that the packet can be received
	by all BMLD Queriers, depending on the underlying BIER layer		by all BMLD Queriers, depending on the underlying BIER layer
	(whether it decrements the IP TTL or not) and the size of the		(whether it decrements the IP TTL or not) and the size of the
	network. The default value is 64.		network. The default value is 64.
	o The extension defined in [I-D.venaas-pim-igmp-mld-extension] MUST		o The extension defined in Section 6 MUST be included, specifying
	be included, specifying the Sub-domain-id, BFR-id and BFR-Prefix		the Sub-domain-id, BFR-id and BFR-Prefix of the sender. This
	of the sender. This information is used to create the necessary		information is used to create the necessary forwarding state for
	forwarding state for requested flows, and may be useful for		requested flows, and may be useful for logging and debugging.
	logging and debugging.
	Since the reports may contain a large number of records, they may		Since the reports may contain a large number of records, they may
	become larger than the maximum BIER payload that can be delivered to		become larger than the maximum BIER payload that can be delivered to
	all the BMLD Queriers. Hence an implementation will need to either		all the BMLD Queriers. Hence an implementation will need to either
	use a small default maximum size, allow configuration of a maximum		use a small default maximum size, allow configuration of a maximum
	size, or rely on MTU discovery. MTU discovery may be done for a sub-		size, or rely on MTU discovery. MTU discovery may be done for a sub-
	domain using BIER MTU Discovery [I-D.venaas-bier-mtud] or for the set		domain using BIER MTU Discovery [I-D.venaas-bier-mtud] or for the set
	of BMLD Queriers using Path MTU Discovery		of BMLD Queriers using Path MTU Discovery
	[I-D.ietf-bier-path-mtu-discovery].		[I-D.ietf-bier-path-mtu-discovery].
	5.2.3. Receiving Queries		5.2.3. Receiving Queries
	BMLD Queriers and Listeners MUST check the destination address of all		BMLD Queriers and Listeners MUST check the destination address of all
	the IP packets that are received or forwarded over BIER whenever		the IP packets that are received or forwarded over BIER whenever
	their own BIER bit is set in the packet. If the destination address		their own BIER bit is set in the packet. If the destination address
	is equal to the 'all BMLD Nodes' group address the packet is		is equal to the 'all BMLD Nodes' group address the packet is
	processed as specified in this section.		processed as specified in this section.
	If the IPv6 (resp. IPv4) packet contains an ICMPv6 (resp. IGMP)		If the IPv6 (resp. IPv4) packet contains an ICMPv6 (resp. IGMP)
	message of type 'Multicast Listener Query' (resp. of type 'Membership		message of type 'Multicast Listener Query' (resp. of type 'Membership
	Query'), and include the extension defined in		Query'), and include the extension defined in Section 6), it is
	[I-D.venaas-pim-igmp-mld-extension]), it is processed by the MLDv2		processed by the MLDv2 (resp. IGMPv3) instance run by the BMLD
	(resp. IGMPv3) instance run by the BMLD Querier. It MUST be dropped		Querier. It MUST be dropped otherwise.
	otherwise.
	During the MLDv2 processing, the packet MUST NOT be checked against		During the MLDv2 processing, the packet MUST NOT be checked against
	the MLDv2 consistency conditions (i.e., the presence of the router		the MLDv2 consistency conditions (i.e., the presence of the router
	alert option, the TTL equaling 1 and, for IPv6 only, the source		alert option, the TTL equaling 1 and, for IPv6 only, the source
	address being link-local).		address being link-local).
	5.2.4. Receiving Reports		5.2.4. Receiving Reports
	BMLD Queriers MUST check the destination address of all the IP		BMLD Queriers MUST check the destination address of all the IP
	packets that are received or forwarded over BIER whenever their own		packets that are received or forwarded over BIER whenever their own
	BIER bit is set. If the destination address is equal to the 'all		BIER bit is set. If the destination address is equal to the 'all
	BMLD Queriers' the packet is processed as specified in this section.		BMLD Queriers' the packet is processed as specified in this section.
	If the IPv6 (resp. IPv4) packet contains an ICMPv6 (resp. IGMP)		If the IPv6 (resp. IPv4) packet contains an ICMPv6 (resp. IGMP)
	message of type 'Multicast Listener Report Message v2' (resp.		message of type 'Multicast Listener Report Message v2' (resp.
	'Version 3 Membership Report'), and include the extension defined in		'Version 3 Membership Report'), and include the extension defined in
	[I-D.venaas-pim-igmp-mld-extension]), it is processed by the MLDv2		Section 6), it is processed by the MLDv2 (resp. IGMPv3) instance run
	(resp. IGMPv3) instance run by the BMLD Querier. It MUST be dropped		by the BMLD Querier. It MUST be dropped otherwise.
	otherwise.
	During the MLDv2 processing, the packet MUST NOT be checked against		During the MLDv2 processing, the packet MUST NOT be checked against
	the MLDv2 consistency conditions (i.e., the presence of the router		the MLDv2 consistency conditions (i.e., the presence of the router
	alert option, the TTL equaling 1 and, for IPv6 only, the source		alert option, the TTL equaling 1 and, for IPv6 only, the source
	address being link-local).		address being link-local).
	5.3. Packet Forwarding		5.3. Packet Forwarding
	BMLD Queriers configure the BIER Layer using the information obtained		BMLD Queriers configure the BIER Layer using the information obtained
	using BMLD, and the extension [I-D.venaas-pim-igmp-mld-extension]),		using BMLD, and the extension Section 6), to track membership state,
	to track membership state, including the Sub-domain-id, BFR-id and		including the Sub-domain-id, BFR-id and BFR-Prefix of the members.
	BFR-Prefix of the members.
	More specifically, the membership state associated with each BMLD		More specifically, the membership state associated with each BMLD
	Listener is provided to the BIER layer such that whenever a multicast		Listener is provided to the BIER layer such that whenever a multicast
	packet enters the BIER domain, if that packet matches the membership		packet enters the BIER domain, if that packet matches the membership
	information from a BMLD Listener, its Sub-domain-id and BFR-id is		information from a BMLD Listener, its Sub-domain-id and BFR-id is
	added to the set of Sub-domains and BFR-ids the packet should be		added to the set of Sub-domains and BFR-ids the packet should be
	forwarded to by the BIER-Layer.		forwarded to by the BIER-Layer.
	6. Security Considerations		6. BIER MLD/IGMP Extension Type
			A new MLD/IGMP extension type adds BIER specific information to IGMP/
			MLD messages, using the extension scheme defined in
			[I-D.venaas-pim-igmp-mld-extension]). The BIER specific information
			is the same as the PTA tunnel identifier in [RFC8556] and is shown in
			Figure 1. Note that, as defined in the MLD (resp. IGMP), existing
			implementations are supposed to ignore this additional data.
			0 1 2 3
			0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| Ext Type TBD | Sub-domain ID | BFR-ID |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| BFR-Prefix |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			~ ~
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			| BFR-Prefix |
			+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
			Figure 1: MLD/IGMP Extension Type for BIER
			o Ext Type: Assigned by IANA, identifying this BIER extension.
			o Sub-domain-id: A single octet containing a BIER sub-domain-id (see
			[[RFC8279]]). This indicates the BIER sub-domain of the router
			originating the message.
			o BFR-id: A two-octet field containing the BFR-id, in the specified
			sub-domain, of the router originating the message.
			o BFR-prefix: The BFR-prefix (see [[RFC8279]]) of the router that is
			originating the message. The BFR-prefix will either be a /32 IPv4
			address or a /128 IPv6 address.
			7. Security Considerations
	BMLD makes use of IP MLDv2 messages transported over BIER in order to		BMLD makes use of IP MLDv2 messages transported over BIER in order to
	configure the BIER Layer of BFIRs. BMLD messages MUST be secured,		configure the BIER Layer of BFIRs. BMLD messages MUST be secured,
	either by relying on physical or link-layer security, by securing the		either by relying on physical or link-layer security, by securing the
	IP packets (e.g., using IPSec [RFC4301]), or by relying on security		IP packets (e.g., using IPSec [RFC4301]), or by relying on security
	features provided by the BIER Layer.		features provided by the BIER Layer.
	Whenever an attacker would be able to spoof the identity of a router,		Whenever an attacker would be able to spoof the identity of a router,
	it could:		it could:
	o Redirect undesired traffic toward the spoofed router by		o Redirect undesired traffic toward the spoofed router by
	subscribing to undesired multicast traffic.		subscribing to undesired multicast traffic.
	o Prevent desired multicast traffic from reaching the spoofed router		o Prevent desired multicast traffic from reaching the spoofed router
	by unsubscribing to some desired multicast traffic.		by unsubscribing to some desired multicast traffic.
	7. IANA Considerations		8. IANA Considerations
	This specification does not require any action from IANA.		This document requests that IANA assigns a new type called BIER
			information in the registry defined in
			[I-D.venaas-pim-igmp-mld-extension].
	8. Acknowledgements		9. Acknowledgements
	Comments concerning this document are very welcome.		Comments concerning this document are very welcome.
	9. References		10. References
	9.1. Normative References		10.1. Normative References
	[I-D.ietf-bier-path-mtu-discovery]		[I-D.ietf-bier-path-mtu-discovery]
	Mirsky, G., Przygienda, T., and A. Dolganow, "Path Maximum		Mirsky, G., Przygienda, T., and A. Dolganow, "Path Maximum
	Transmission Unit Discovery (PMTUD) for Bit Index Explicit		Transmission Unit Discovery (PMTUD) for Bit Index Explicit
	Replication (BIER) Layer", draft-ietf-bier-path-mtu-		Replication (BIER) Layer", draft-ietf-bier-path-mtu-
	discovery-06 (work in progress), June 2019.		discovery-07 (work in progress), November 2019.
	[I-D.venaas-bier-mtud]		[I-D.venaas-bier-mtud]
	Venaas, S., Wijnands, I., Ginsberg, L., and M. Sivakumar,		Venaas, S., Wijnands, I., Ginsberg, L., and M. Sivakumar,
	"BIER MTU Discovery", draft-venaas-bier-mtud-02 (work in		"BIER MTU Discovery", draft-venaas-bier-mtud-02 (work in
	progress), October 2018.		progress), October 2018.
	[I-D.venaas-pim-igmp-mld-extension]		[I-D.venaas-pim-igmp-mld-extension]
	Sivakumar, M., Venaas, S., and Z. Zhang, "IGMPv3/MLDv2		Sivakumar, M., Venaas, S., and Z. Zhang, "IGMPv3/MLDv2
	Message Extension", draft-venaas-pim-igmp-mld-extension-00		Message Extension", draft-venaas-pim-igmp-mld-extension-00
	(work in progress), November 2019.		(work in progress), November 2019.
	skipping to change at page 10, line 20 ¶		skipping to change at page 11, line 15 ¶
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,		[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	Przygienda, T., and S. Aldrin, "Multicast Using Bit Index		Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
	Explicit Replication (BIER)", RFC 8279,		Explicit Replication (BIER)", RFC 8279,
	DOI 10.17487/RFC8279, November 2017,		DOI 10.17487/RFC8279, November 2017,
	<https://www.rfc-editor.org/info/rfc8279>.		<https://www.rfc-editor.org/info/rfc8279>.
	9.2. Informative References		10.2. Informative References
	[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",		[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
	RFC 2711, DOI 10.17487/RFC2711, October 1999,		RFC 2711, DOI 10.17487/RFC2711, October 1999,
	<https://www.rfc-editor.org/info/rfc2711>.		<https://www.rfc-editor.org/info/rfc2711>.
	[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6		[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
	Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,		Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
	August 2002, <https://www.rfc-editor.org/info/rfc3306>.		August 2002, <https://www.rfc-editor.org/info/rfc3306>.
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	skipping to change at page 11, line 16 ¶		skipping to change at page 12, line 10 ¶
	Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent		Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
	Multicast - Sparse Mode (PIM-SM): Protocol Specification		Multicast - Sparse Mode (PIM-SM): Protocol Specification
	(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March		(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
	2016, <https://www.rfc-editor.org/info/rfc7761>.		2016, <https://www.rfc-editor.org/info/rfc7761>.
	[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", STD 86, RFC 8200,		(IPv6) Specification", STD 86, RFC 8200,
	DOI 10.17487/RFC8200, July 2017,		DOI 10.17487/RFC8200, July 2017,
	<https://www.rfc-editor.org/info/rfc8200>.		<https://www.rfc-editor.org/info/rfc8200>.
			[RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S.,
			and A. Dolganow, "Multicast VPN Using Bit Index Explicit
			Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April
			2019, <https://www.rfc-editor.org/info/rfc8556>.
	Appendix A. BIER Use Case in Data Centers		Appendix A. BIER Use Case in Data Centers
	In current data center virtualization, virtual eXtensible Local Area		In current data center virtualization, virtual eXtensible Local Area
	Network (VXLAN) [RFC7348] is a kind of network virtualization overlay		Network (VXLAN) [RFC7348] is a kind of network virtualization overlay
	technology which is overlaid between NVEs and is intended for multi-		technology which is overlaid between NVEs and is intended for multi-
	tenancy data center networks, whose reference architecture is		tenancy data center networks, whose reference architecture is
	illustrated as per Figure 1.		illustrated as per Figure 2.
	+--------+ +--------+		+--------+ +--------+
	| Tenant +--+ +----| Tenant |		| Tenant +--+ +----| Tenant |
	| System | | (') | System |		| System | | (') | System |
	+--------+ | ................ ( ) +--------+		+--------+ | ................ ( ) +--------+
	| +-+--+ . . +--+-+ (_)		| +-+--+ . . +--+-+ (_)
	| | NVE|--. .--| NVE| |		| | NVE|--. .--| NVE| |
	+--| | . . | |---+		+--| | . . | |---+
	+-+--+ . . +--+-+		+-+--+ . . +--+-+
	/ . .		/ . .
	/ . L3 Overlay . +--+-++--------+		/ . L3 Overlay . +--+-++--------+
	+--------+ / . Network . | NVE|| Tenant |		+--------+ / . Network . | NVE|| Tenant |
	| Tenant +--+ . .--| || System |		| Tenant +--+ . .--| || System |
	| System | . . +--+-++--------+		| System | . . +--+-++--------+
	+--------+ ................		+--------+ ................
	Figure 1: NVO3 Architecture		Figure 2: NVO3 Architecture
	And there are two kinds of most common methods about how to forward		And there are two kinds of most common methods about how to forward
	BUM packets in this virtualization overlay network. One is using PIM		BUM packets in this virtualization overlay network. One is using PIM
	as underlay multicast routing protocol to build explicit multicast		as underlay multicast routing protocol to build explicit multicast
	distribution tree, such as PIM-SM [RFC7761] or PIM-BIDIR [RFC5015]		distribution tree, such as PIM-SM [RFC7761] or PIM-BIDIR [RFC5015]
	multicast routing protocol. Then, when BUM packets arrive at NVE, it		multicast routing protocol. Then, when BUM packets arrive at NVE, it
	requires NVE to have a mapping between the VXLAN Network Identifier		requires NVE to have a mapping between the VXLAN Network Identifier
	and the IP multicast group. According to the mapping, NVE can		and the IP multicast group. According to the mapping, NVE can
	encapsulate BUM packets in a multicast packet which group address is		encapsulate BUM packets in a multicast packet which group address is
	the mapping IP multicast group address and steer them through		the mapping IP multicast group address and steer them through
End of changes. 23 change blocks.
	48 lines changed or deleted		88 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/