< draft-ietf-nvo3-use-case-14.txt		draft-ietf-nvo3-use-case-15.txt >
	Network Working Group L. Yong		Network Working Group L. Yong
	Internet Draft L. Dunbar		Internet Draft L. Dunbar
	Category: Informational Huawei		Category: Informational Huawei
	M. Toy		M. Toy
	Verizon		Verizon
	A. Isaac		A. Isaac
	Juniper Networks		Juniper Networks
	V. Manral		V. Manral
	Ionos Networks		Ionos Networks
	Expires: June 2017 December 8, 2016		Expires: June 2017 December 21, 2016
	Use Cases for Data Center Network Virtualization Overlay Networks		Use Cases for Data Center Network Virtualization Overlay Networks
	draft-ietf-nvo3-use-case-14		draft-ietf-nvo3-use-case-15
	Abstract		Abstract
	This document describes data center network virtualization overlay		This document describes data center network virtualization overlay
	(NVO3) network use cases that can be deployed in various data		(NVO3) network use cases that can be deployed in various data
	centers and serve different data center applications.		centers and serve different data center applications.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with		This Internet-Draft is submitted to IETF in full conformance with
	skipping to change at page 1, line 45 ¶		skipping to change at page 1, line 45 ¶
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	at any time. It is inappropriate to use Internet-Drafts as reference		at any 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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on June 8, 2017.		This Internet-Draft will expire on June 21, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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		(http://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 27 ¶		skipping to change at page 2, line 27 ¶
	Section 4.e of the Trust Legal Provisions and are provided without		Section 4.e of the Trust Legal Provisions and are provided without
	warranty as described in the Simplified BSD License.		warranty as described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction...................................................3		1. Introduction...................................................3
	1.1. Terminology...............................................4		1.1. Terminology...............................................4
	2. Basic NVO3 Networks............................................5		2. Basic NVO3 Networks............................................5
	3. DC NVO3 Network and External Network Interconnection...........6		3. DC NVO3 Network and External Network Interconnection...........6
	3.1. DC NVO3 Network Access via the Internet...................6		3.1. DC NVO3 Network Access via the Internet...................6
	3.2. DC NVO3 Network and SP WAN VPN Interconnection............8		3.2. DC NVO3 Network and SP WAN VPN Interconnection............7
	4. DC Applications Using NVO3.....................................8		4. DC Applications Using NVO3.....................................8
	4.1. Supporting Multiple Technologies..........................9		4.1. Supporting Multiple Technologies..........................9
	4.2. DC Application with Multiple Virtual Networks.............9		4.2. DC Application with Multiple Virtual Networks.............9
	4.3. Virtual Data Center (vDC)................................10		4.3. Virtual Data Center (vDC)................................10
	5. Summary.......................................................12		5. Summary.......................................................12
	6. Security Considerations.......................................12		6. Security Considerations.......................................12
	7. IANA Considerations...........................................12		7. IANA Considerations...........................................12
	8. Informative References........................................13		8. Informative References........................................13
	Contributors.....................................................14		Contributors.....................................................14
	Acknowledgements.................................................14		Acknowledgements.................................................14
	skipping to change at page 3, line 21 ¶		skipping to change at page 3, line 21 ¶
	cloud applications and multi tenant networks [RFC7364]. The goal of		cloud applications and multi tenant networks [RFC7364]. The goal of
	data center network virtualization overlay (NVO3) networks is to		data center network virtualization overlay (NVO3) networks is to
	decouple the communication among tenant systems from DC physical		decouple the communication among tenant systems from DC physical
	infrastructure networks and to allow one physical network		infrastructure networks and to allow one physical network
	infrastructure:		infrastructure:
	o Carry many NVO3 networks and isolate different NVO3 network		o Carry many NVO3 networks and isolate different NVO3 network
	traffic on a physical network that carries NVO3 network traffic.		traffic on a physical network that carries NVO3 network traffic.
	o Independent address spaces in individual NVO3 networks such as		o Independent address spaces in individual NVO3 networks such as
	MAC, IP, TCP/UDP etc.		MAC and IP.
	o Flexible Virtual Machines (VM) and/or workload placement		o Flexible Virtual Machines (VM) and/or workload placement
	including the ability to move them from one server to another		including the ability to move them from one server to another
	without requiring VM address changes and physical infrastructure		without requiring VM address changes and physical infrastructure
	network configuration changes, and the ability to perform a "hot		network configuration changes, and the ability to perform a "hot
	move" with no disruption to the live application running on VMs.		move" with no disruption to the live application running on VMs.
	These characteristics of NVO3 networks help address the issues that		These characteristics of NVO3 networks help address the issues that
	cloud applications face in data centers [RFC7364].		cloud applications face in data centers [RFC7364].
	skipping to change at page 4, line 21 ¶		skipping to change at page 4, line 21 ¶
	o A virtual network that spans across multiple Data Centers and/or		o A virtual network that spans across multiple Data Centers and/or
	to customer premises where NVO3 networks are constructed and		to customer premises where NVO3 networks are constructed and
	interconnect another virtual or physical network outside the data		interconnect another virtual or physical network outside the data
	center. An enterprise customer may use a traditional carrier VPN		center. An enterprise customer may use a traditional carrier VPN
	or an IPsec tunnel over the Internet to communicate with its		or an IPsec tunnel over the Internet to communicate with its
	systems in the DC. This is described in Section 3.		systems in the DC. This is described in Section 3.
	o DC applications or services require an advanced network that		o DC applications or services require an advanced network that
	contains several NVO3 networks that are interconnected by the		contains several NVO3 networks that are interconnected by the
	gateways. Three scenarios are described in Section 4: 1)		gateways. Three scenarios are described in Section 4.1)
	supporting multiple technologies; 2) constructing several virtual		supporting multiple technologies; 2) constructing several virtual
	networks as a tenant network; 3) applying NVO3 to a virtual Data		networks as a tenant network; 3) applying NVO3 to a virtual Data
	Center (vDC).		Center (vDC).
	The document uses the architecture reference model defined in		The document uses the architecture reference model defined in
	[RFC7365] to describe the use cases.		[RFC7365] to describe the use cases.
	1.1. Terminology		1.1. Terminology
	This document uses the terminologies defined in [RFC7365] and		This document uses the terminologies defined in [RFC7365] and
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 27 ¶
	traffic in inbound direction [NVO3ARCH]. A Network Virtualization		traffic in inbound direction [NVO3ARCH]. A Network Virtualization
	Authority (NVA) is another NVO3 architecture component [RFC7365]. An		Authority (NVA) is another NVO3 architecture component [RFC7365]. An
	NVE obtains the reachability information of tenant systems in a NVO3		NVE obtains the reachability information of tenant systems in a NVO3
	network from the NVA. The tenant systems attached to the same NVE		network from the NVA. The tenant systems attached to the same NVE
	may belong to a same or different NVO3 networks.		may belong to a same or different NVO3 networks.
	The network virtualization overlay in this context means that a		The network virtualization overlay in this context means that a
	virtual network is implemented with an overlay technology, i.e.,		virtual network is implemented with an overlay technology, i.e.,
	within a DC, NVO3 traffic is encapsulated at an NVE and carried by a		within a DC, NVO3 traffic is encapsulated at an NVE and carried by a
	tunnel to another NVE where the packet is decapsulated and sent to a		tunnel to another NVE where the packet is decapsulated and sent to a
	target tenant system [NVO3ARCH]. This architecture decouples a NVO3		target tenant system [NVO3ARCH]. This architecture decouples an NVO3
	network construction from the DC physical network configuration,		network construction from the DC physical network configuration,
	which provides the flexibility for VM placement and mobility. It		which provides the flexibility for VM placement and mobility. The
	also means that the nodes in the infrastructure network (except		architecture supports one tunnel to carry NVO3 traffic belonging to
	tunnel end point nodes) carry encapsulated NVO3 traffic but not		different NVO3 networks; thus the NVO3 encapsulation header carries
	aware of the existence of NVO3 networks. In the architecture		a virtual network identifier to differentiate NVO3 traffic in a
	[NVO3ARCH], one tunnel can carry NVO3 traffic belonging to different		tunnel.
	NVO3 networks; a virtual network identifier is used in an NVO3
	encapsulation protocol to differentiate NVO3 traffic.
	An NVO3 network may be an L2 or L3 domain. The network provides		An NVO3 network may be an L2 or L3 domain. The network provides
	switching (L2) or routing (L3) capability to support host (i.e.		switching (L2) or routing (L3) capability to support host (i.e.
	tenent systems) communications. An NVO3 network may required to		tenent systems) communications. An NVO3 network may required to
	carry unicast traffic and/or multicast, broadcast/unknown (for L2		carry unicast traffic and/or multicast, broadcast/unknown (for L2
	only) traffic from/to tenant systems. There are several ways to		only) traffic from/to tenant systems. There are several ways to
	transport NVO3 network BUM traffic [NVO3MCAST].		transport NVO3 network BUM traffic [NVO3MCAST].
	It is worth mentioning two distinct cases regarding to NVE location.		It is worth mentioning two distinct cases regarding to NVE location.
	The first is where TSs and an NVE are co-located on a single end		The first is where TSs and an NVE are co-located on a single end
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 14 ¶
	physical networks and/or virtual networks in the DC for a reason.		physical networks and/or virtual networks in the DC for a reason.
	This section highlights some use cases for this goal.		This section highlights some use cases for this goal.
	4.1. Supporting Multiple Technologies		4.1. Supporting Multiple Technologies
	Servers deployed in a large data center are often installed at		Servers deployed in a large data center are often installed at
	different times, and may have different capabilities/features. Some		different times, and may have different capabilities/features. Some
	servers may be virtualized, while others may not; some may be		servers may be virtualized, while others may not; some may be
	equipped with virtual switches, while others may not. For the		equipped with virtual switches, while others may not. For the
	servers equipped with Hypervisor-based virtual switches, some may		servers equipped with Hypervisor-based virtual switches, some may
	support VxLAN [RFC7348] encapsulation, some may support NVGRE		support a standardized NVO3 encapsulation, some may not support any
	encapsulation [RFC7637], and some may not support any encapsulation.		encapsulation, and some may support a documented encapsulation
	To construct a tenant network among these servers and the ToR		protocol (e.g. VxLAN [RFC7348], NVGRE [RFC7637]) or proprietary
	switches, operators can construct one traditional VLAN network and		encapsulations. To construct a tenant network among these servers
	two virtual networks where one uses VxLAN encapsulation and the		and the ToR switches, operators can construct one traditional VLAN
	other uses NVGRE, and interconnect these three networks via a		network and two virtual networks where one uses VxLAN encapsulation
	gateway or virtual GW. The GW performs packet		and the other uses NVGRE, and interconnect these three networks via
			a gateway or virtual GW. The GW performs packet
	encapsulation/decapsulation translation between the networks.		encapsulation/decapsulation translation between the networks.
	Another case is that some software of a tenant is high CPU and		Another case is that some software of a tenant is high CPU and
	memory consumption, which only makes a sense to run on metal servers;		memory consumption, which only makes a sense to run on metal servers;
	other software of the tenant may be good to run on VMs. However		other software of the tenant may be good to run on VMs. However
	provider DC infrastructure is configured to use NVO3 to connect to		provider DC infrastructure is configured to use NVO3 to connect to
	VMs and VLAN [IEEE802.1Q] connect to metal services. The tenant		VMs and VLAN [IEEE802.1Q] connect to metal services. The tenant
	network requires interworking between NVO3 and traditional VLAN.		network requires interworking between NVO3 and traditional VLAN.
	4.2. DC Application with Multiple Virtual Networks		4.2. DC Application with Multiple Virtual Networks
	skipping to change at page 14, line 33 ¶		skipping to change at page 14, line 33 ¶
	Juniper Networks		Juniper Networks
	1133 Innovation Way		1133 Innovation Way
	Sunnyvale, CA 94089		Sunnyvale, CA 94089
	Phone: +1-408-745-2000		Phone: +1-408-745-2000
	Email: kmilne@juniper.net		Email: kmilne@juniper.net
	Acknowledgements		Acknowledgements
	Authors like to thank Sue Hares, Young Lee, David Black, Pedro		Authors like to thank Sue Hares, Young Lee, David Black, Pedro
	Marques, Mike McBride, David McDysan, Randy Bush, Uma Chunduri, Eric		Marques, Mike McBride, David McDysan, Randy Bush, Uma Chunduri, Eric
	Gray, David Allan, Joe Touch, Olufemi Komolafe, and Matthew Bocci		Gray, David Allan, Joe Touch, Olufemi Komolafe, Matthew Bocci, and
	for the review, comments, and suggestions.		Alia Atlas for the review, comments, and suggestions.
	Authors' Addresses		Authors' Addresses
	Lucy Yong		Lucy Yong
	Huawei Technologies		Huawei Technologies
	Phone: +1-918-808-1918		Phone: +1-918-808-1918
	Email: lucy.yong@huawei.com		Email: lucy.yong@huawei.com
	Linda Dunbar		Linda Dunbar
	Huawei Technologies,		Huawei Technologies,
	5340 Legacy Dr.		5340 Legacy Dr.
	Plano, TX 75025 US		Plano, TX 75025 US
	Phone: +1-469-277-5840		Phone: +1-469-277-5840
	Email: linda.dunbar@huawei.com		Email: linda.dunbar@huawei.com
	Mehmet Toy		Mehmet Toy
	Verizon		Verizon
	Phone : +1-856-792-2801
	E-mail : mtoy054@yahoo.com		E-mail : mtoy054@yahoo.com
	Aldrin Isaac		Aldrin Isaac
	Juniper Networks		Juniper Networks
	E-mail: aldrin.isaac@gmail.com		E-mail: aldrin.isaac@gmail.com
	Vishwas Manral		Vishwas Manral
	Email: vishwas@ionosnetworks.com		Email: vishwas@ionosnetworks.com
End of changes. 11 change blocks.
	24 lines changed or deleted		23 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/