< draft-ietf-bier-mld-00.txt		draft-ietf-bier-mld-01.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: December 31, 2017 Cisco Systems		Expires: December 31, 2018 Cisco Systems
	C. Wang		C. Wang
	Z. Zhang		Z. Zhang
	ZTE Corporation		ZTE Corporation
	M. Stenberg		M. Stenberg
	June 29, 2017		June 29, 2018
	BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery		BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery
	Protocols		Protocols
	draft-ietf-bier-mld-00		draft-ietf-bier-mld-01
	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.
	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 http://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 December 31, 2017.		This Internet-Draft will expire on December 31, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 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
	(http://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
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	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. . . . . . . . . . . . . . . . . . . . . 5		5.2. MLDv2 instances. . . . . . . . . . . . . . . . . . . . . 5
	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 . . . . . . . . . . . . . . . . . . 6		5.2.3. Receiving Queries . . . . . . . . . . . . . . . . . . 7
	5.2.4. Receiving Reports . . . . . . . . . . . . . . . . . . 7		5.2.4. Receiving Reports . . . . . . . . . . . . . . . . . . 7
	5.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 7		5.3. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 8
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	9.1. Normative References . . . . . . . . . . . . . . . . . . 8		9.1. Normative References . . . . . . . . . . . . . . . . . . 8
	9.2. Informative References . . . . . . . . . . . . . . . . . 9		9.2. Informative References . . . . . . . . . . . . . . . . . 9
	Appendix A. BIER Use Case in Data Centers . . . . . . . . . . . 9		Appendix A. BIER Use Case in Data Centers . . . . . . . . . . . 10
	A.1. Convention and Terminology . . . . . . . . . . . . . . . 11		A.1. Convention and Terminology . . . . . . . . . . . . . . . 12
	A.2. BIER in data centers . . . . . . . . . . . . . . . . . . 11		A.2. BIER in data centers . . . . . . . . . . . . . . . . . . 12
	A.3. A BIER MLD solution for Virtual Network information . . . 12		A.3. A BIER MLD solution for Virtual Network information . . . 13
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	The Bit Index Explicit Replication (BIER -		The Bit Index Explicit Replication (BIER - [RFC8279]) forwarding
	[I-D.ietf-bier-architecture]) forwarding technique enables IP		technique enables IP multicast transport across a BIER domain. When
	multicast transport across a BIER domain. When receiving or		receiving or originating a packet, ingress routers have to construct
	originating a packet, ingress routers have to construct a bit mask		a bit mask indicating which BIER egress routers located within the
	indicating which BIER egress routers located within the same BIER		same BIER domain will receive the packet. A stateless approach would
	domain will receive the packet. A stateless approach would consist		consist of forwarding all incoming packets toward all egress routers,
	in forwarding all incoming packets toward all egress routers, which		which would in turn make a forwarding decision based on local
	would in turn make a forwarding decision based on local information.		information. But any more efficient approach would require ingress
	But any more efficient approach would require ingress routers to keep		routers to keep some state about egress routers multicast membership
	some state about egress routers multicast membership information,		information, hence requiring state sharing from egress routers toward
	hence requiring state sharing from egress routers toward ingress		ingress routers.
	routers.
	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		flow overlay (BIER layering is described in [RFC8279]) for IPv6
	[I-D.ietf-bier-architecture]) for IPv6 (resp. IPv4). It enables		(resp. IPv4). It enables multicast membership information sharing
	multicast membership information sharing from egress routers, acting		from egress routers, acting as listeners, toward ingress routers,
	as listeners, toward ingress routers, acting as queriers. Ingress		acting as queriers. Ingress routers keep per-egress-router state,
	routers keep per-egress-router state, used to construct the BIER bit		used to construct the BIER bit mask associated with IP multicast
	mask associated with IP multicast packets entering the BIER domain.		packets entering the BIER domain.
	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
	In this document, the key words "MAY", "MUST", "MUST NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"RECOMMENDED", and "SHOULD", are to be interpreted as described in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	[RFC2119].		"OPTIONAL" in this document are to be interpreted as described in BCP
			14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	The terms "Bit-Forwarding Router" (BFR), "Bit-Forwarding Egress		The terms "Bit-Forwarding Router" (BFR), "Bit-Forwarding Egress
	Router" (BFER), "Bit-Forwarding Ingress Router" (BFIR), "BFR-id" and		Router" (BFER), "Bit-Forwarding Ingress Router" (BFIR), "BFR-id" and
	"BFR-Prefix" are to be interpreted as described in		"BFR-Prefix" are to be interpreted as described in [RFC8279].
	[I-D.ietf-bier-architecture].
	Additionally, the following definitions are used:		Additionally, the following definitions are used:
	BIER Multicast Listener Discovery (BMLD): The modified version of		BIER Multicast Listener Discovery (BMLD): The modified version of
	MLD specified in this document.		MLD specified in this document.
	BMLD Querier: A BFR implementing the Querier part of this		BMLD Querier: A BFR implementing the Querier part of this
	specification. A BMLD Node MAY be both a Querier and a Listener.		specification. A BMLD Node MAY be both a Querier and a Listener.
	BMLD Listener: A BFR implementing the Listener part of this		BMLD Listener: A BFR implementing the Listener part of this
	skipping to change at page 5, line 9 ¶		skipping to change at page 5, line 9 ¶
	originating multicast traffic, MUST behave as BMLD Queriers.		originating multicast traffic, MUST behave as BMLD Queriers.
	BMLD Queriers (resp. BMLD Listeners) MUST act as MLDv2 Queriers		BMLD Queriers (resp. BMLD Listeners) MUST act as MLDv2 Queriers
	(resp. MLDv2 Listeners) as specified in [RFC3810] unless stated		(resp. MLDv2 Listeners) as specified in [RFC3810] unless stated
	otherwise in this section.		otherwise in this section.
	5.1. Configuration Parameters		5.1. Configuration Parameters
	Both Queriers and Listeners MUST operate as BFIRs and BFERs within		Both Queriers and Listeners MUST operate as BFIRs and BFERs within
	the BIER domain in order to send and receive BMLD messages. They		the BIER domain in order to send and receive BMLD messages. They
	MUST therefore be configured accordingly, as specified in		MUST therefore be configured accordingly, as specified in [RFC8279].
	[I-D.ietf-bier-architecture].
	All Listeners MUST be configured with a 'all BMLD Queriers' multicast		All Listeners MUST be configured with an 'all BMLD Queriers'
	address and the BFR-ids of all the BMLD Queriers. This is used by		multicast address and the BFR-ids of all the BMLD Queriers. This is
	Listeners to send BMLD reports over BIER toward all Queriers. All		used by Listeners to send BMLD reports over BIER toward all Queriers.
	Queriers MUST be configured to accept BMLD reports sent to this		All Queriers MUST be configured to accept BMLD reports sent to this
	address.		address.
	All Queriers MUST be configured with a 'all BMLD Nodes' multicast		All Queriers MUST be configured with an 'all BMLD Nodes' multicast
	address and the BFR-ids of all the Queriers and Listeners. This		address and the BFR-ids of all the Queriers and Listeners. This
	information is used by Queriers to send BMLD queries over BIER toward		information is used by Queriers to send BMLD queries over BIER toward
	all BMLD Nodes. All BMLD Nodes MUST be configured to accept BMLD		all BMLD Nodes. All BMLD Nodes MUST be configured to accept BMLD
	queries sent to this address.		queries sent to this address.
			It may be cumbersone to configure the exact set of BFR-ids for
			Queriers and Listeners. One MAY configure the set of BFR-ids to
			contain any potentially used BFR-id, perhaps having all bit positions
			set. There is no harm in configuring unused BFR-ids. Configuring
			the BFR-ids of additional routers would in most cases cause no harm,
			as a router would drop the BMLD message unless it is configured as a
			Querier or a Listener.
	Note that BMLD (unlike MLDv2) makes use of per-instance configured		Note that BMLD (unlike MLDv2) makes use of per-instance configured
	multicast group addresses rather than well-known addresses so that		multicast group addresses rather than well-known addresses so that
	multiple instances of BMLD (using different group addresses) can be		multiple instances of BMLD (using different group addresses) can be
	run simultaneously within the same BIER domain. Configured group		run simultaneously within the same BIER domain. Configured group
	addresses MAY be obtained from allocated IP prefixes using [RFC3306].		addresses MAY be obtained from allocated IP prefixes using [RFC3306].
	One MAY choose to use the well-known MLDv2 addresses in one instance,		One MAY choose to use the well-known MLDv2 addresses in one instance,
	but different instances MUST use different addresses.		but different instances MUST use different addresses.
	IP packets coming from outside of the BIER domain and having a		IP packets coming from outside of the BIER domain and having a
	destination address set to the configured 'all BMLD Queriers' or the		destination address set to the configured 'all BMLD Queriers' or the
	skipping to change at page 6, line 13 ¶		skipping to change at page 6, line 20 ¶
	for IPv4) backward compatibility procedures.		for IPv4) backward compatibility procedures.
	5.2.1. Sending Queries		5.2.1. Sending Queries
	BMLD Queries are IP packets sent over BIER by BMLD Queriers:		BMLD Queries are IP packets sent over BIER by BMLD Queriers:
	o Toward all BMLD Nodes (i.e., providing to the BIER Layer the BFR-		o Toward all BMLD Nodes (i.e., providing to the BIER Layer the BFR-
	ids of all BMLD Nodes).		ids of all BMLD Nodes).
	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 [RFC2460] (or the IPv4 router alert option		extension header [RFC8200] (or the IPv4 router alert option
	[RFC2113] for IPv4).		[RFC2113] for IPv4).
	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 great 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.
	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 [RFC2460] (or the IPv4 router alert option		extension header [RFC8200] (or the IPv4 router alert option
	[RFC2113] for IPv4).		[RFC2113] for IPv4).
	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 great 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.
			Since the reports may contain a large number of records, they may
			become larger than the maximum BIER payload that can be delivered to
			all the BMLD Queriers. Hence an implementation will need to either
			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-
			domain using BIER MTU Discovery [I-D.venaas-bier-mtud]) or for the
			set of BMLD Queriers using 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
	skipping to change at page 8, line 28 ¶		skipping to change at page 8, line 46 ¶
	This specification does not require any action from IANA.		This specification does not require any action from IANA.
	8. Acknowledgements		8. Acknowledgements
	Comments concerning this document are very welcome.		Comments concerning this document are very welcome.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[I-D.ietf-bier-architecture]		[I-D.ietf-bier-path-mtu-discovery]
	Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and		Mirsky, G., Przygienda, T., and A. Dolganow, "Path Maximum
	S. Aldrin, "Multicast using Bit Index Explicit		Transmission Unit Discovery (PMTUD) for Bit Index Explicit
	Replication", draft-ietf-bier-architecture-07 (work in		Replication (BIER) Layer", draft-ietf-bier-path-mtu-
	progress), June 2017.		discovery-04 (work in progress), June 2018.
			[I-D.venaas-bier-mtud]
			Venaas, S., Wijnands, I., Ginsberg, L., and M. Sivakumar,
			"BIER MTU Discovery", draft-venaas-bier-mtud-01 (work in
			progress), June 2018.
	[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,		[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113,
	DOI 10.17487/RFC2113, February 1997,		DOI 10.17487/RFC2113, February 1997,
	<http://www.rfc-editor.org/info/rfc2113>.		<https://www.rfc-editor.org/info/rfc2113>.
	[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,
	<http://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.		[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
	Thyagarajan, "Internet Group Management Protocol, Version		Thyagarajan, "Internet Group Management Protocol, Version
	3", RFC 3376, DOI 10.17487/RFC3376, October 2002,		3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
	<http://www.rfc-editor.org/info/rfc3376>.		<https://www.rfc-editor.org/info/rfc3376>.
	[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener		[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
	Discovery Version 2 (MLDv2) for IPv6", RFC 3810,		Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
	DOI 10.17487/RFC3810, June 2004,		DOI 10.17487/RFC3810, June 2004,
	<http://www.rfc-editor.org/info/rfc3810>.		<https://www.rfc-editor.org/info/rfc3810>.
	9.2. Informative References		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A.,
	(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,		Przygienda, T., and S. Aldrin, "Multicast Using Bit Index
	December 1998, <http://www.rfc-editor.org/info/rfc2460>.		Explicit Replication (BIER)", RFC 8279,
			DOI 10.17487/RFC8279, November 2017,
			<https://www.rfc-editor.org/info/rfc8279>.
			9.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,
	<http://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, <http://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
	Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,		Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
	December 2005, <http://www.rfc-editor.org/info/rfc4301>.		December 2005, <https://www.rfc-editor.org/info/rfc4301>.
	[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,		[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
	"Bidirectional Protocol Independent Multicast (BIDIR-		"Bidirectional Protocol Independent Multicast (BIDIR-
	PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,		PIM)", RFC 5015, DOI 10.17487/RFC5015, October 2007,
	<http://www.rfc-editor.org/info/rfc5015>.		<https://www.rfc-editor.org/info/rfc5015>.
	[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,		[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
	L., Sridhar, T., Bursell, M., and C. Wright, "Virtual		L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
	eXtensible Local Area Network (VXLAN): A Framework for		eXtensible Local Area Network (VXLAN): A Framework for
	Overlaying Virtualized Layer 2 Networks over Layer 3		Overlaying Virtualized Layer 2 Networks over Layer 3
	Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,		Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
	<http://www.rfc-editor.org/info/rfc7348>.		<https://www.rfc-editor.org/info/rfc7348>.
	[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.		[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
	Rekhter, "Framework for Data Center (DC) Network		Rekhter, "Framework for Data Center (DC) Network
	Virtualization", RFC 7365, DOI 10.17487/RFC7365, October		Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
	2014, <http://www.rfc-editor.org/info/rfc7365>.		2014, <https://www.rfc-editor.org/info/rfc7365>.
	[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,		[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
	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, <http://www.rfc-editor.org/info/rfc7761>.		2016, <https://www.rfc-editor.org/info/rfc7761>.
			[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
			(IPv6) Specification", STD 86, RFC 8200,
			DOI 10.17487/RFC8200, July 2017,
			<https://www.rfc-editor.org/info/rfc8200>.
	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 1.
	+--------+ +--------+		+--------+ +--------+
	skipping to change at page 11, line 5 ¶		skipping to change at page 12, line 5 ¶
	The other method is using ingress replication to require each NVE to		The other method is using ingress replication to require each NVE to
	create a mapping between the VXLAN Network Identifier and the remote		create a mapping between the VXLAN Network Identifier and the remote
	addresses of NVEs which belong to the same virtual network. When NVE		addresses of NVEs which belong to the same virtual network. When NVE
	receives BUM traffic from the attached tenant, NVE can encapsulate		receives BUM traffic from the attached tenant, NVE can encapsulate
	these BUM packets in unicast packets and replicate them and tunnel		these BUM packets in unicast packets and replicate them and tunnel
	them to different remote NVEs respectively. Although this method can		them to different remote NVEs respectively. Although this method can
	eliminate the burden of running multicast protocol in the underlay		eliminate the burden of running multicast protocol in the underlay
	network, it has a significant disadvantage: large waste of bandwidth,		network, it has a significant disadvantage: large waste of bandwidth,
	especially in big-sized data center where there are many receivers.		especially in big-sized data center where there are many receivers.
	BIER [I-D.ietf-bier-architecture] is an architecture that provides		BIER [RFC8279] is an architecture that provides optimal multicast
	optimal multicast forwarding through a "BIER domain" without		forwarding through a "BIER domain" without requiring intermediate
	requiring intermediate routers to maintain any multicast related per-		routers to maintain any multicast related per-flow state. BIER also
	flow state. BIER also does not require any explicit tree-building		does not require any explicit tree-building protocol for its
	protocol for its operation. A multicast data packet enters a BIER		operation. A multicast data packet enters a BIER domain at a "Bit-
	domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the		Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one
	BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).		or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router
	The BFIR router adds a BIER header to the packet. The BIER header		adds a BIER header to the packet. The BIER header contains a bit-
	contains a bit-string in which each bit represents exactly one BFER		string in which each bit represents exactly one BFER to forward the
	to forward the packet to. The set of BFERs to which the multicast		packet to. The set of BFERs to which the multicast packet needs to
	packet needs to be forwarded is expressed by setting the bits that		be forwarded is expressed by setting the bits that correspond to
	correspond to those routers in the BIER header. Specifically, for		those routers in the BIER header. Specifically, for BIER-TE, the
	BIER-TE, the BIER header may also contain a bit-string in which each		BIER header may also contain a bit-string in which each bit indicates
	bit indicates the link the flow passes through.		the link the flow passes through.
	The following sub-sections try to propose how to take full advantage		The following sub-sections try to propose how to take full advantage
	of overlay multicast protocol to carry virtual network information,		of overlay multicast protocol to carry virtual network information,
	and create a mapping between the virtual network information and the		and create a mapping between the virtual network information and the
	bit-string to implement BUM services in data centers.		bit-string to implement BUM services in data centers.
	A.1. Convention and Terminology		A.1. Convention and Terminology
	The terms about NVO3 are defined in [RFC7365]. The most common		The terms about NVO3 are defined in [RFC7365]. The most common
	terminology used in this appendix is listed below.		terminology used in this appendix is listed below.
End of changes. 38 change blocks.
	83 lines changed or deleted		115 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/