draft-ietf-mboned-dc-deploy-08.txt		draft-ietf-mboned-dc-deploy-09.txt
	MBONED M. McBride		MBONED M. McBride
	Internet-Draft Futurewei		Internet-Draft Futurewei
	Intended status: Informational O. Komolafe		Intended status: Informational O. Komolafe
	Expires: August 7, 2020 Arista Networks		Expires: August 7, 2020 Arista Networks
	February 4, 2020		February 4, 2020
	Multicast in the Data Center Overview		Multicast in the Data Center Overview
	draft-ietf-mboned-dc-deploy-08		draft-ietf-mboned-dc-deploy-09
	Abstract		Abstract
	The volume and importance of one-to-many traffic patterns in data		The volume and importance of one-to-many traffic patterns in data
	centers is likely to increase significantly in the future. Reasons		centers is likely to increase significantly in the future. Reasons
	for this increase are discussed and then attention is paid to the		for this increase are discussed and then attention is paid to the
	manner in which this traffic pattern may be judiously handled in data		manner in which this traffic pattern may be judiciously handled in
	centers. The intuitive solution of deploying conventional IP		data centers. The intuitive solution of deploying conventional IP
	multicast within data centers is explored and evaluated. Thereafter,		multicast within data centers is explored and evaluated. Thereafter,
	a number of emerging innovative approaches are described before a		a number of emerging innovative approaches are described before a
	number of recommendations are made.		number of recommendations are made.
	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
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 15		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . 15		9.1. Normative References . . . . . . . . . . . . . . . . . . 15
	9.2. Informative References . . . . . . . . . . . . . . . . . 16		9.2. Informative References . . . . . . . . . . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The volume and importance of one-to-many traffic patterns in data		The volume and importance of one-to-many traffic patterns in data
	centers is likely to increase significantly in the future. Reasons		centers will likely continue to increase. Reasons for this increase
	for this increase include the nature of the traffic generated by		include the nature of the traffic generated by applications hosted in
	applications hosted in the data center, the need to handle broadcast,		the data center, the need to handle broadcast, unknown unicast and
	unknown unicast and multicast (BUM) traffic within the overlay		multicast (BUM) traffic within the overlay technologies used to
	technologies used to support multi-tenancy at scale, and the use of		support multi-tenancy at scale, and the use of certain protocols that
	certain protocols that traditionally require one-to-many control		traditionally require one-to-many control message exchanges.
	message exchanges.
	These trends, allied with the expectation that future highly		These trends, allied with the expectation that highly virtualized
	virtualized large-scale data centers must support communication		large-scale data centers must support communication between
	between potentially thousands of participants, may lead to the		potentially thousands of participants, may lead to the natural
	natural assumption that IP multicast will be widely used in data		assumption that IP multicast will be widely used in data centers,
	centers, specifically given the bandwidth savings it potentially		specifically given the bandwidth savings it potentially offers.
	offers. However, such an assumption would be wrong. In fact, there		However, such an assumption would be wrong. In fact, there is
	is widespread reluctance to enable conventional IP multicast in data		widespread reluctance to enable conventional IP multicast in data
	centers for a number of reasons, mostly pertaining to concerns about		centers for a number of reasons, mostly pertaining to concerns about
	its scalability and reliability.		its scalability and reliability.
	This draft discusses some of the main drivers for the increasing		This draft discusses some of the main drivers for the increasing
	volume and importance of one-to-many traffic patterns in data		volume and importance of one-to-many traffic patterns in data
	centers. Thereafter, the manner in which conventional IP multicast		centers. Thereafter, the manner in which conventional IP multicast
	may be used to handle this traffic pattern is discussed and some of		may be used to handle this traffic pattern is discussed and some of
	the associated challenges highlighted. Following this discussion, a		the associated challenges highlighted. Following this discussion, a
	number of alternative emerging approaches are introduced, before		number of alternative emerging approaches are introduced, before
	concluding by discussing key trends and making a number of		concluding by discussing key trends and making a number of
	skipping to change at page 5, line 38 ¶		skipping to change at page 5, line 37 ¶
	Another key contributor to the rise in one-to-many traffic patterns		Another key contributor to the rise in one-to-many traffic patterns
	is the proposed architecture for supporting large-scale multi-tenancy		is the proposed architecture for supporting large-scale multi-tenancy
	in highly virtualized data centers [RFC8014]. In this architecture,		in highly virtualized data centers [RFC8014]. In this architecture,
	a tenant's VMs are distributed across the data center and are		a tenant's VMs are distributed across the data center and are
	connected by a virtual network known as the overlay network. A		connected by a virtual network known as the overlay network. A
	number of different technologies have been proposed for realizing the		number of different technologies have been proposed for realizing the
	overlay network, including VXLAN [RFC7348], VXLAN-GPE [I-D.ietf-nvo3-		overlay network, including VXLAN [RFC7348], VXLAN-GPE [I-D.ietf-nvo3-
	vxlan-gpe], NVGRE [RFC7637] and GENEVE [I-D.ietf-nvo3-geneve]. The		vxlan-gpe], NVGRE [RFC7637] and GENEVE [I-D.ietf-nvo3-geneve]. The
	often fervent and arguably partisan debate about the relative merits		often fervent and arguably partisan debate about the relative merits
	of these overlay technologies belies the fact that, conceptually, it		of these overlay technologies belies the fact that, conceptually, it
	may be said that these overlays mainly simply provide a means to		may be said that these overlays simply provide a means to encapsulate
	encapsulate and tunnel Ethernet frames from the VMs over the data		and tunnel Ethernet frames from the VMs over the data center IP
	center IP fabric, thus emulating a Layer 2 segment between the VMs.		fabric, thus emulating a Layer 2 segment between the VMs.
	Consequently, the VMs believe and behave as if they are connected to		Consequently, the VMs believe and behave as if they are connected to
	the tenant's other VMs by a conventional Layer 2 segment, regardless		the tenant's other VMs by a conventional Layer 2 segment, regardless
	of their physical location within the data center.		of their physical location within the data center.
	Naturally, in a Layer 2 segment, point to multi-point traffic can		Naturally, in a Layer 2 segment, point to multi-point traffic can
	result from handling BUM (broadcast, unknown unicast and multicast)		result from handling BUM (broadcast, unknown unicast and multicast)
	traffic. And, compounding this issue within data centers, since the		traffic. And, compounding this issue within data centers, since the
	tenant's VMs attached to the emulated segment may be dispersed		tenant's VMs attached to the emulated segment may be dispersed
	throughout the data center, the BUM traffic may need to traverse the		throughout the data center, the BUM traffic may need to traverse the
	data center fabric.		data center fabric.
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 7 ¶
	Section 2.1, Section 2.2 and Section 2.3 have discussed how the		Section 2.1, Section 2.2 and Section 2.3 have discussed how the
	trends in the types of applications, the overlay technologies used		trends in the types of applications, the overlay technologies used
	and some of the essential networking protocols results in an increase		and some of the essential networking protocols results in an increase
	in the volume of one-to-many traffic patterns in modern highly-		in the volume of one-to-many traffic patterns in modern highly-
	virtualized data centers. Section 3 explores how such traffic flows		virtualized data centers. Section 3 explores how such traffic flows
	may be handled using conventional IP multicast.		may be handled using conventional IP multicast.
	3. Handling one-to-many traffic using conventional multicast		3. Handling one-to-many traffic using conventional multicast
	Faced with ever increasing volumes of one-to-many traffic flows for		Faced with ever increasing volumes of one-to-many traffic flows, for
	the reasons presented in Section 2, arguably the intuitive initial		the reasons presented in Section 2, it makes sense for a data center
	course of action for a data center operator is to explore if and how		operator to explore if and how conventional IP multicast could be
	conventional IP multicast could be deployed within the data center.		deployed within the data center. This section introduces the key
	This section introduces the key protocols, discusses some example use		protocols, discusses some example use cases where they are deployed
	cases where they are deployed in data centers and discusses some of		in data centers and discusses some of the advantages and
	the advantages and disadvantages of such deployments.		disadvantages of such deployments.
	3.1. Layer 3 multicast		3.1. Layer 3 multicast
	PIM is the most widely deployed multicast routing protocol and so,		PIM is the most widely deployed multicast routing protocol and so,
	unsurprisingly, is the primary multicast routing protocol considered		unsurprisingly, is the primary multicast routing protocol considered
	for use in the data center. There are three potential popular modes		for use in the data center. There are three potential popular modes
	of PIM that may be used: PIM-SM [RFC4601], PIM-SSM [RFC4607] or PIM-		of PIM that may be used: PIM-SM [RFC4601], PIM-SSM [RFC4607] or PIM-
	BIDIR [RFC5015]. It may be said that these different modes of PIM		BIDIR [RFC5015]. It may be said that these different modes of PIM
	tradeoff the optimality of the multicast forwarding tree for the		tradeoff the optimality of the multicast forwarding tree for the
	amount of multicast forwarding state that must be maintained at		amount of multicast forwarding state that must be maintained at
	skipping to change at page 9, line 21 ¶		skipping to change at page 9, line 21 ¶
	specification [RFC7348], a data-driven flood and learn control plane		specification [RFC7348], a data-driven flood and learn control plane
	was proposed, requiring the data center IP fabric to support		was proposed, requiring the data center IP fabric to support
	multicast routing. A multicast group is associated with each virtual		multicast routing. A multicast group is associated with each virtual
	network, each uniquely identified by its VXLAN network identifiers		network, each uniquely identified by its VXLAN network identifiers
	(VNI). VXLAN tunnel endpoints (VTEPs), typically located in the		(VNI). VXLAN tunnel endpoints (VTEPs), typically located in the
	hypervisor or ToR switch, with local VMs that belong to this VNI		hypervisor or ToR switch, with local VMs that belong to this VNI
	would join the multicast group and use it for the exchange of BUM		would join the multicast group and use it for the exchange of BUM
	traffic with the other VTEPs. Essentially, the VTEP would		traffic with the other VTEPs. Essentially, the VTEP would
	encapsulate any BUM traffic from attached VMs in an IP multicast		encapsulate any BUM traffic from attached VMs in an IP multicast
	packet, whose destination address is the associated multicast group		packet, whose destination address is the associated multicast group
	address, and transmit the packet to the data center fabric. Thus,		address, and transmit the packet to the data center fabric. Thus, a
	PIM must be running in the fabric to maintain a multicast		multicast routing protocol (typically PIM) must be running in the
	distribution tree per VNI.		fabric to maintain a multicast distribution tree per VNI.
	Alternatively, rather than setting up a multicast distribution tree		Alternatively, rather than setting up a multicast distribution tree
	per VNI, a tree can be set up whenever hosts within the VNI wish to		per VNI, a tree can be set up whenever hosts within the VNI wish to
	exchange multicast traffic. For example, whenever a VTEP receives an		exchange multicast traffic. For example, whenever a VTEP receives an
	IGMP report from a locally connected host, it would translate this		IGMP report from a locally connected host, it would translate this
	into a PIM join message which will be propagated into the IP fabric.		into a PIM join message which will be propagated into the IP fabric.
	In order to ensure this join message is sent to the IP fabric rather		In order to ensure this join message is sent to the IP fabric rather
	than over the VXLAN interface (since the VTEP will have a route back		than over the VXLAN interface (since the VTEP will have a route back
	to the source of the multicast packet over the VXLAN interface and so		to the source of the multicast packet over the VXLAN interface and so
	would naturally attempt to send the join over this interface) a more		would naturally attempt to send the join over this interface) a more
	skipping to change at page 14, line 17 ¶		skipping to change at page 14, line 17 ¶
	to the packet. This header contains a bit string in which each bit		to the packet. This header contains a bit string in which each bit
	maps to an egress router, known as Bit-Forwarding Egress Router		maps to an egress router, known as Bit-Forwarding Egress Router
	(BFER). If a bit is set, then the packet should be forwarded to the		(BFER). If a bit is set, then the packet should be forwarded to the
	associated BFER. The routers within the BIER domain, Bit-Forwarding		associated BFER. The routers within the BIER domain, Bit-Forwarding
	Routers (BFRs), use the BIER header in the packet and information in		Routers (BFRs), use the BIER header in the packet and information in
	the Bit Index Forwarding Table (BIFT) to carry out simple bit- wise		the Bit Index Forwarding Table (BIFT) to carry out simple bit- wise
	operations to determine how the packet should be replicated optimally		operations to determine how the packet should be replicated optimally
	so it reaches all the appropriate BFERs.		so it reaches all the appropriate BFERs.
	BIER is deemed to be attractive for facilitating one-to-many		BIER is deemed to be attractive for facilitating one-to-many
	communications in data centers [I-D.ietf-bier-use-cases]. The		communications in data centers [I-D.ietf-bier-use-cases]. The BFIRs
	deployment envisioned with overlay networks is that the the		are the encapsulation endpoints in the deployment envisioned with
	encapsulation endpoints would be the BFIR. So knowledge about the		overlay networks. So knowledge about the actual multicast groups
	actual multicast groups does not reside in the data center fabric,		does not reside in the data center fabric, improving the scalability
	improving the scalability compared to conventional IP multicast.		compared to conventional IP multicast. Additionally, a centralized
	Additionally, a centralized controller or a BGP-EVPN control plane		controller or a BGP-EVPN control plane may be used with BIER to
	may be used with BIER to ensure the BFIR have the required		ensure the BFIR have the required information. A challenge
	information. A challenge associated with using BIER is that it		associated with using BIER is that it requires changes to the
	requires changes to the forwarding behaviour of the routers used in		forwarding behaviour of the routers used in the data center IP
	the data center IP fabric.		fabric.
	4.5. Segment Routing		4.5. Segment Routing
	Segment Routing (SR) [RFC8402] is a manifestation of the source		Segment Routing (SR) [RFC8402] is a manifestation of the source
	routing paradigm, so called as the path a packet takes through a		routing paradigm, so called as the path a packet takes through a
	network is determined at the source. The source encodes this		network is determined at the source. The source encodes this
	information in the packet header as a sequence of instructions.		information in the packet header as a sequence of instructions.
	These instructions are followed by intermediate routers, ultimately		These instructions are followed by intermediate routers, ultimately
	resulting in the delivery of the packet to the desired destination.		resulting in the delivery of the packet to the desired destination.
	In SR, the instructions are known as segments and a number of		In SR, the instructions are known as segments and a number of
End of changes. 8 change blocks.
	40 lines changed or deleted		39 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/