< draft-ietf-nvo3-overlay-problem-statement-01.txt		draft-ietf-nvo3-overlay-problem-statement-02.txt >
	Internet Engineering Task Force T. Narten, Ed.		Internet Engineering Task Force T. Narten, Ed.
	Internet-Draft IBM		Internet-Draft IBM
	Intended status: Informational E. Gray, Ed.		Intended status: Informational E. Gray, Ed.
	Expires: April 26, 2013 Ericsson		Expires: August 11, 2013 Ericsson
	D. Black		D. Black
	EMC		EMC
	D. Dutt		D. Dutt
			Cumulus Networks
	L. Fang		L. Fang
	Cisco Systems		Cisco Systems
	L. Kreeger		L. Kreeger
	Cisco		Cisco
	M. Napierala		M. Napierala
	AT&T		AT&T
	M. Sridharan		M. Sridharan
	Microsoft		Microsoft
	October 23, 2012		February 7, 2013
	Problem Statement: Overlays for Network Virtualization		Problem Statement: Overlays for Network Virtualization
	draft-ietf-nvo3-overlay-problem-statement-01		draft-ietf-nvo3-overlay-problem-statement-02
	Abstract		Abstract
	This document describes issues associated with providing multi-		This document describes issues associated with providing multi-
	tenancy in large data center networks and how these issues may be		tenancy in large data center networks and how these issues may be
	addressed using an overlay-based network virtualization approach. A		addressed using an overlay-based network virtualization approach. A
	key multi-tenancy requirement is traffic isolation, so that one		key multi-tenancy requirement is traffic isolation, so that one
	tenant's traffic is not visible to any other tenant. Another		tenant's traffic is not visible to any other tenant. Another
	requirement is address space isolation, so that different tenants can		requirement is address space isolation, so that different tenants can
	use the same address space within different virtual networks.		use the same address space within different virtual networks.
	skipping to change at page 2, line 13 ¶		skipping to change at page 2, line 13 ¶
	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 http://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 April 26, 2013.		This Internet-Draft will expire on August 11, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2013 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
	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 3, line 19 ¶		skipping to change at page 3, line 19 ¶
	3. Problem Areas . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Problem Areas . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Need For Dynamic Provisioning . . . . . . . . . . . . . . 6		3.1. Need For Dynamic Provisioning . . . . . . . . . . . . . . 6
	3.2. Virtual Machine Mobility Limitations . . . . . . . . . . . 6		3.2. Virtual Machine Mobility Limitations . . . . . . . . . . . 6
	3.3. Inadequate Forwarding Table Sizes . . . . . . . . . . . . 7		3.3. Inadequate Forwarding Table Sizes . . . . . . . . . . . . 7
	3.4. Need to Decouple Logical and Physical Configuration . . . 7		3.4. Need to Decouple Logical and Physical Configuration . . . 7
	3.5. Need For Address Separation Between Virtual Networks . . . 8		3.5. Need For Address Separation Between Virtual Networks . . . 8
	3.6. Need For Address Separation Between Virtual Networks		3.6. Need For Address Separation Between Virtual Networks
	and Infrastructure . . . . . . . . . . . . . . . . . . . . 8		and Infrastructure . . . . . . . . . . . . . . . . . . . . 8
	3.7. Optimal Forwarding . . . . . . . . . . . . . . . . . . . . 8		3.7. Optimal Forwarding . . . . . . . . . . . . . . . . . . . . 8
	4. Using Network Overlays to Provide Virtual Networks . . . . . . 9		4. Using Network Overlays to Provide Virtual Networks . . . . . . 9
	4.1. Overview of Network Overlays . . . . . . . . . . . . . . . 9		4.1. Overview of Network Overlays . . . . . . . . . . . . . . . 10
	4.2. Communication Between Virtual and Non-virtualized		4.2. Communication Between Virtual and Non-virtualized
	Networks . . . . . . . . . . . . . . . . . . . . . . . . . 11		Networks . . . . . . . . . . . . . . . . . . . . . . . . . 11
	4.3. Communication Between Virtual Networks . . . . . . . . . . 11		4.3. Communication Between Virtual Networks . . . . . . . . . . 12
	4.4. Overlay Design Characteristics . . . . . . . . . . . . . . 12		4.4. Overlay Design Characteristics . . . . . . . . . . . . . . 12
	4.5. Control Plane Overlay Networking Work Areas . . . . . . . 13		4.5. Control Plane Overlay Networking Work Areas . . . . . . . 13
	4.6. Data Plane Work Areas . . . . . . . . . . . . . . . . . . 14		4.6. Data Plane Work Areas . . . . . . . . . . . . . . . . . . 14
	5. Related IETF and IEEE Work . . . . . . . . . . . . . . . . . . 14		5. Related IETF and IEEE Work . . . . . . . . . . . . . . . . . . 15
	5.1. BGP/MPLS IP VPNs . . . . . . . . . . . . . . . . . . . . . 15		5.1. BGP/MPLS IP VPNs . . . . . . . . . . . . . . . . . . . . . 15
	5.2. BGP/MPLS Ethernet VPNs . . . . . . . . . . . . . . . . . . 15		5.2. BGP/MPLS Ethernet VPNs . . . . . . . . . . . . . . . . . . 15
	5.3. 802.1 VLANs . . . . . . . . . . . . . . . . . . . . . . . 15		5.3. 802.1 VLANs . . . . . . . . . . . . . . . . . . . . . . . 16
	5.4. IEEE 802.1aq - Shortest Path Bridging . . . . . . . . . . 16		5.4. IEEE 802.1aq - Shortest Path Bridging . . . . . . . . . . 16
	5.5. ARMD . . . . . . . . . . . . . . . . . . . . . . . . . . . 16		5.5. ARMD . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.6. TRILL . . . . . . . . . . . . . . . . . . . . . . . . . . 17		5.6. TRILL . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.7. L2VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . 17		5.7. L2VPNs . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	5.8. Proxy Mobile IP . . . . . . . . . . . . . . . . . . . . . 17		5.8. Proxy Mobile IP . . . . . . . . . . . . . . . . . . . . . 18
	5.9. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . . 17		5.9. LISP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	5.10. VDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		5.10. VDP . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6. Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 18		6. Further Work . . . . . . . . . . . . . . . . . . . . . . . . . 18
	7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 19		10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	11. Informative References . . . . . . . . . . . . . . . . . . . . 19		11. Informative References . . . . . . . . . . . . . . . . . . . . 20
	Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 20		Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 21
	A.1. Changes From -00 to -01 . . . . . . . . . . . . . . . . . 20		A.1. Changes From -01 to -02 . . . . . . . . . . . . . . . . . 21
	A.2. Changes from		A.2. Changes From -00 to -01 . . . . . . . . . . . . . . . . . 21
	draft-narten-nvo3-overlay-problem-statement-04.txt . . . . 21		A.3. Changes from
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		draft-narten-nvo3-overlay-problem-statement-04.txt . . . . 22
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	Data Centers are increasingly being consolidated and outsourced in an		Data Centers are increasingly being consolidated and outsourced in an
	effort to improve the deployment time of applications and reduce		effort to improve the deployment time of applications and reduce
	operational costs. This coincides with an increasing demand for		operational costs. This coincides with an increasing demand for
	compute, storage, and network resources from applications. In order		compute, storage, and network resources from applications. In order
	to scale compute, storage, and network resources, physical resources		to scale compute, storage, and network resources, physical resources
	are being abstracted from their logical representation, in what is		are being abstracted from their logical representation, in what is
	referred to as server, storage, and network virtualization.		referred to as server, storage, and network virtualization.
	skipping to change at page 7, line 51 ¶		skipping to change at page 7, line 51 ¶
	to migrate compute workloads to any server anywhere in the network		to migrate compute workloads to any server anywhere in the network
	while retaining the workload's addresses. In networks using VLANs,		while retaining the workload's addresses. In networks using VLANs,
	moving servers elsewhere in the network may require expanding the		moving servers elsewhere in the network may require expanding the
	scope of the VLAN beyond its original boundaries. While this can be		scope of the VLAN beyond its original boundaries. While this can be
	done, it requires potentially complex network configuration changes		done, it requires potentially complex network configuration changes
	and can conflict with the desire to bound the size of broadcast		and can conflict with the desire to bound the size of broadcast
	domains, especially in larger data centers. In addition, when VMs		domains, especially in larger data centers. In addition, when VMs
	migrate, the physical network (e.g., access lists) may need to be		migrate, the physical network (e.g., access lists) may need to be
	reconfigured which can be time consuming and error prone.		reconfigured which can be time consuming and error prone.
	In order to limit the broadcast domain of each VLAN, multi-
	destination frames within a VLAN should optimally flow only to those
	devices that have that VLAN configured. When workloads migrate, the
	physical network (e.g., access lists) may need to be reconfigured
	which is typically time consuming and error prone.
	An important use case is cross-pod expansion. A pod typically		An important use case is cross-pod expansion. A pod typically
	consists of one or more racks of servers with associated network and		consists of one or more racks of servers with associated network and
	storage connectivity. A tenant's virtual network may start off on a		storage connectivity. A tenant's virtual network may start off on a
	pod and, due to expansion, require servers/VMs on other pods,		pod and, due to expansion, require servers/VMs on other pods,
	especially the case when other pods are not fully utilizing all their		especially the case when other pods are not fully utilizing all their
	resources. This use case requires that virtual networks span		resources. This use case requires that virtual networks span
	multiple pods in order to provide connectivity to all of its tenant's		multiple pods in order to provide connectivity to all of its tenant's
	servers/VMs. Such expansion can be difficult to achieve when tenant		servers/VMs. Such expansion can be difficult to achieve when tenant
	addressing is tied to the addressing used by the underlay network or		addressing is tied to the addressing used by the underlay network or
	when the expansion requires that the scope of the underlying L2 VLAN		when the expansion requires that the scope of the underlying L2 VLAN
	skipping to change at page 8, line 44 ¶		skipping to change at page 8, line 38 ¶
	As in the previous case, a tenant needs to be able to use whatever		As in the previous case, a tenant needs to be able to use whatever
	addresses it wants in a virtual network independent of what addresses		addresses it wants in a virtual network independent of what addresses
	the underlying data center network is using. Tenants (and the		the underlying data center network is using. Tenants (and the
	underlay infrastructure provider) should be able use whatever		underlay infrastructure provider) should be able use whatever
	addresses make sense for them, without having to worry about address		addresses make sense for them, without having to worry about address
	collisions between addresses used by tenants and those used by the		collisions between addresses used by tenants and those used by the
	underlay data center network.		underlay data center network.
	3.7. Optimal Forwarding		3.7. Optimal Forwarding
	Another problem area relates to the changing of optimal paths when a		Another problem area relates to the routing of traffic into and out
	VM moves from one location to another. In the simplest case, a		of a virtual network. A virtual network may have two routers for
	virtual network may have 2 external routers (whether for inter-VN		traffic to/from other VNs or external to all VNs, and the optimal
	traffic, or traffic external to all VNs). When a VM migrates to a		choice of router may depend on where the VM is located. The two
	new location within the data center, the closest router may change,		routers may not be equally "close" to a given VM. The issue appears
	i.e., the VM may get better service by switching to the "closer"		both when a VM is initially instantiated on a virtual network or when
	router. But IP does not normally distinguish between multiple		a VM migrates or is moved to a different location. After a
	routers on the same subnet. All routers are considered one-hop away.		migration, the VM's closest router for such traffic may change, i.e.,
			the VM may get better service by switching to the "closer" router,
			and this may improve the utilization of network resources.
			IP implementations in network endpoints typically do not distinguish
			between multiple routers on the same subnet - there may only be a
			single default gateway in use, and any use of multiple routers
			usually considers all of them to be one-hop away. Routing protocol
			functionality is constrained by the requirement to cope with these
			endpoint limitations - for example VRRP has one router serve as the
			master to handle all outbound traffic. This problem can be
			particularly acute when the virtual network spans multiple data
			centers, as a VM is likely to receive significantly better service
			when forwarding external traffic through a local router by comparison
			to using a router at a remote data center.
			The optimal forwarding problem applies to both outbound and inbound
			traffic. For outbound traffic, the choice of outbound router
			determines the path of outgoing traffic from the VM, which may be
			sub-optimal after a VM move. For inbound traffic, the location of
			the VM within the IP subnet for the VM is not visible to the routers
			beyond the virtual network. Thus, the routing infrastructure will
			have no information as to which of the two externally visible
			gateways leading into the virtual network would be the better choice
			for reaching a particular VM.
	The issue is further complicated when middleboxes (e.g., load-		The issue is further complicated when middleboxes (e.g., load-
	balancers, firewalls, etc.) must be traversed. Middle boxes may have		balancers, firewalls, etc.) must be traversed. Middle boxes may have
	session state that must be preserved for ongoing communication, and		session state that must be preserved for ongoing communication, and
	traffic must continue to flow through the middle box, regardless of		traffic must continue to flow through the middle box, regardless of
	which router is "closest".		which router is "closest".
	4. Using Network Overlays to Provide Virtual Networks		4. Using Network Overlays to Provide Virtual Networks
	Virtual Networks are used to isolate a tenant's traffic from that of		Virtual Networks are used to isolate a tenant's traffic from that of
	skipping to change at page 10, line 33 ¶		skipping to change at page 10, line 52 ¶
	Each of the above steps is logically distinct, though an		Each of the above steps is logically distinct, though an
	implementation might combine them for efficiency or other reasons.		implementation might combine them for efficiency or other reasons.
	It should be noted that in L3 BGP/VPN terminology, the above steps		It should be noted that in L3 BGP/VPN terminology, the above steps
	are commonly known as "forwarding" or "virtual forwarding".		are commonly known as "forwarding" or "virtual forwarding".
	The first hop network NVE device can be a traditional switch or		The first hop network NVE device can be a traditional switch or
	router or the virtual switch residing inside a hypervisor.		router or the virtual switch residing inside a hypervisor.
	Furthermore, the endpoint can be a VM or it can be a physical server.		Furthermore, the endpoint can be a VM or it can be a physical server.
	Examples of architectures based on network overlays include BGP/MPLS		Examples of architectures based on network overlays include BGP/MPLS
	VPNs [RFC4364], TRILL [RFC6325], LISP [I-D.ietf-lisp], and Shortest		VPNs [RFC4364], TRILL [RFC6325], LISP [RFC6830], and Shortest Path
	Path Bridging (SPBM) [SPBM].		Bridging (SPB) [SPB].
	In the data plane, an overlay header provides a place to carry either		In the data plane, an overlay header provides a place to carry either
	the virtual network identifier, or an identifier that is locally-		the virtual network identifier, or an identifier that is locally-
	significant to the edge device. In both cases, the identifier in the		significant to the edge device. In both cases, the identifier in the
	overlay header specifies which specific virtual network the data		overlay header specifies which specific virtual network the data
	packet belongs to. Since both routed and bridged semantics can be		packet belongs to. Since both routed and bridged semantics can be
	supported by a virtual data center, the original packet carried		supported by a virtual data center, the original packet carried
	within the overlay header can be an Ethernet frame or just the IP		within the overlay header can be an Ethernet frame or just the IP
	packet.		packet.
	A key aspect of overlays is the decoupling of the "virtual" MAC		A key aspect of overlays is the decoupling of the "virtual" MAC
	and/or IP addresses used by VMs from the physical network		and/or IP addresses used by VMs from the physical network
	infrastructure and the infrastructure IP addresses used by the data		infrastructure and the infrastructure IP addresses used by the data
	center. If a VM changes location, the overlay edge devices simply		center. If a VM changes location, the overlay edge devices simply
	update their mapping tables to reflect the new location of the VM		update their mapping tables to reflect the new location of the VM
	within the data center's infrastructure space. Because an overlay		within the data center's infrastructure space. Because an overlay
	network is used, a VM can now be located anywhere in the data center		network is used, a VM can now be located anywhere in the data center
	that the overlay reaches without regards to traditional constraints		that the overlay reaches without regards to traditional constraints
	implied by L2 properties such as VLAN numbering, or L3 properties as		imposed by the underlay network such as the L2 VLAN scope, or the IP
	the IP subnet number.		subnet scope.
	Multi-tenancy is supported by isolating the traffic of one virtual		Multi-tenancy is supported by isolating the traffic of one virtual
	network instance from traffic of another. Traffic from one virtual		network instance from traffic of another. Traffic from one virtual
	network instance cannot be delivered to another instance without		network instance cannot be delivered to another instance without
	(conceptually) exiting the instance and entering the other instance		(conceptually) exiting the instance and entering the other instance
	via an entity (e.g., a gateway) that has connectivity to both virtual		via an entity (e.g., a gateway) that has connectivity to both virtual
	network instances. Without the existence of a gateway entity, tenant		network instances. Without the existence of a gateway entity, tenant
	traffic remains isolated within each individual virtual network		traffic remains isolated within each individual virtual network
	instance.		instance.
	skipping to change at page 16, line 16 ¶		skipping to change at page 16, line 34 ¶
	within the VLAN it originates from. Traffic forwarded from one VLAN		within the VLAN it originates from. Traffic forwarded from one VLAN
	to another typically involves router (L3) processing. The forwarding		to another typically involves router (L3) processing. The forwarding
	table look up operation may be keyed on {VLAN, MAC address} tuples.		table look up operation may be keyed on {VLAN, MAC address} tuples.
	VLANs are a pure L2 bridging construct and VLAN identifiers are		VLANs are a pure L2 bridging construct and VLAN identifiers are
	carried along with data frames to allow each forwarding point to know		carried along with data frames to allow each forwarding point to know
	what VLAN the frame belongs to. Various types of VLANs are available		what VLAN the frame belongs to. Various types of VLANs are available
	today, which can be used for network virtualization even together.		today, which can be used for network virtualization even together.
	The C-VLAN, S-VLAN and B-VLAN IDs are 12 bits. The 24-bit I-SID		The C-VLAN, S-VLAN and B-VLAN IDs are 12 bits. The 24-bit I-SID
	allows the support of more than 16 million virtual networks.		allows the support of more than 16 million virtual networks.
	Altogether, 60 bits are available for network virtualization in the
	Ethernet header today.
	5.4. IEEE 802.1aq - Shortest Path Bridging		5.4. IEEE 802.1aq - Shortest Path Bridging
	Shortest Path Bridging (SPBM) [SPBM] is an IS-IS based overlay that		Shortest Path Bridging (SPB) [SPB] is an IS-IS based overlay that
	operates over L2 Ethernets. SPBM supports multi-pathing and		operates over L2 Ethernets. SPB supports multi-pathing and addresses
	addresses a number of shortcoming in the original Ethernet Spanning		a number of shortcomings in the original Ethernet Spanning Tree
	Tree Protocol. SPBM uses IEEE 802.1ah PBB (MAC-in-MAC) encapsulation		Protocol. Shortest Path Bridging Mac (SPBM) uses IEEE 802.1ah PBB
	and supports a 24-bit I-SID, which can be used to identify virtual		(MAC-in-MAC) encapsulation and supports a 24-bit I-SID, which can be
	network instances. SPBM provides multi-pathing and supports easy		used to identify virtual network instances. SPBM provides multi-
	virtual network creation or update.		pathing and supports easy virtual network creation or update.
	SPB extends IS-IS in order to perform link-state routing among core		SPBM extends IS-IS in order to perform link-state routing among core
	SPBM nodes, obviating the need for learning for communication among		SPBM nodes, obviating the need for learning for communication among
	core SPBM nodes. Learning is still used to build and maintain the		core SPBM nodes. Learning is still used to build and maintain the
	mapping tables of edge nodes to encapsulate Tenant System traffic for		mapping tables of edge nodes to encapsulate Tenant System traffic for
	transport across the SPBM core.		transport across the SPBM core.
	SPB is compatible with all other 802.1 standards thus allows		SPB is compatible with all other 802.1 standards thus allows
	leveraging of other features, e.g., VSI Discovery Protocol (VDP), OAM		leveraging of other features, e.g., VSI Discovery Protocol (VDP), OAM
	or scalability solutions.		or scalability solutions.
	5.5. ARMD		5.5. ARMD
	The ARMD WG examined data center scaling issues with a focus on		The ARMD WG examined data center scaling issues with a focus on
	address resolution and developed a problem statement document		address resolution and developed a problem statement document
	[I-D.ietf-armd-problem-statement]. While an overlay-based approach		[RFC6820]. While an overlay-based approach may address some of the
	may address some of the "pain points" that were raised in ARMD (e.g.,		"pain points" that were raised in ARMD (e.g., better support for
	better support for multi-tenancy), an overlay approach may also push		multi-tenancy), an overlay approach may also push some of the L2
	some of the L2 scaling concerns (e.g., excessive flooding) to the IP		scaling concerns (e.g., excessive flooding) to the IP level (flooding
	level (flooding via IP multicast). Analysis will be needed to		via IP multicast). Analysis will be needed to understand the scaling
	understand the scaling tradeoffs of an overlay based approach		tradeoffs of an overlay based approach compared with existing
	compared with existing approaches. On the other hand, existing IP-		approaches. On the other hand, existing IP-based approaches such as
	based approaches such as proxy ARP may help mitigate some concerns.		proxy ARP may help mitigate some concerns.
	5.6. TRILL		5.6. TRILL
	TRILL is a network protocol that provides an Ethernet L2 service to		TRILL is a network protocol that provides an Ethernet L2 service to
	end systems and is designed to operate over any L2 link type. TRILL		end systems and is designed to operate over any L2 link type. TRILL
	establishes forwarding paths using IS-IS routing and encapsulates		establishes forwarding paths using IS-IS routing and encapsulates
	traffic within its own TRILL header. TRILL as defined today,		traffic within its own TRILL header. TRILL as defined today,
	supports only the standard (and limited) 12-bit C-VID identifier.		supports only the standard (and limited) 12-bit C-VID identifier.
	Approaches to extend TRILL to support more than 4094 VLANs are		Approaches to extend TRILL to support more than 4094 VLANs are
	currently under investigation [I-D.ietf-trill-fine-labeling]		currently under investigation [I-D.ietf-trill-fine-labeling]
	skipping to change at page 17, line 46 ¶		skipping to change at page 18, line 13 ¶
	part of the overlay network and be responsible for encapsulating and		part of the overlay network and be responsible for encapsulating and
	decapsulating packets.		decapsulating packets.
	5.8. Proxy Mobile IP		5.8. Proxy Mobile IP
	Proxy Mobile IP [RFC5213] [RFC5844] makes use of the GRE Key Field		Proxy Mobile IP [RFC5213] [RFC5844] makes use of the GRE Key Field
	[RFC5845] [RFC6245], but not in a way that supports multi-tenancy.		[RFC5845] [RFC6245], but not in a way that supports multi-tenancy.
	5.9. LISP		5.9. LISP
	LISP[I-D.ietf-lisp] essentially provides an IP over IP overlay where		LISP[RFC6830] essentially provides an IP over IP overlay where the
	the internal addresses are end station Identifiers and the outer IP		internal addresses are end station Identifiers and the outer IP
	addresses represent the location of the end station within the core		addresses represent the location of the end station within the core
	IP network topology. The LISP overlay header uses a 24-bit Instance		IP network topology. The LISP overlay header uses a 24-bit Instance
	ID used to support overlapping inner IP addresses.		ID used to support overlapping inner IP addresses.
	5.10. VDP		5.10. VDP
	VDP is the Virtual Station Interface (VSI) Discovery and		VDP is the Virtual Station Interface (VSI) Discovery and
	Configuration Protocol specified by IEEE P802.1Qbg [Qbg]. VDP is a		Configuration Protocol specified by IEEE P802.1Qbg [Qbg]. VDP is a
	protocol that supports the association of a VSI with a port. VDP is		protocol that supports the association of a VSI with a port. VDP is
	run between the end system (e.g., a hypervisor) and its adjacent		run between the end system (e.g., a hypervisor) and its adjacent
	skipping to change at page 18, line 36 ¶		skipping to change at page 19, line 4 ¶
	requirements.		requirements.
	7. Summary		7. Summary
	This document has argued that network virtualization using overlays		This document has argued that network virtualization using overlays
	addresses a number of issues being faced as data centers scale in		addresses a number of issues being faced as data centers scale in
	size. In addition, careful study of current data center problems is		size. In addition, careful study of current data center problems is
	needed for development of proper requirements and standard solutions.		needed for development of proper requirements and standard solutions.
	This document identified three potential control protocol work areas.		This document identified three potential control protocol work areas.
	The first involves a backend "oracle" and how it learns and		The first involves a backend "oracle" and how it learns and
	distributes the mapping information NVEs use when processing tenant		distributes the mapping information NVEs use when processing tenant
	traffic. A second involves the protocol an NVE would use to		traffic. A second involves the protocol an NVE would use to
	communicate with the backend oracle to obtain the mapping		communicate with the backend oracle to obtain the mapping
	information. The third potential work concerns the interactions that		information. The third potential work concerns the interactions that
	take place when a VM attaches or detaches from an specific virtual		take place when a VM attaches or detaches from an specific virtual
	network instance.		network instance.
	8. Acknowledgments		8. Acknowledgments
	Helpful comments and improvements to this document have come from		Helpful comments and improvements to this document have come from Lou
	John Drake, Janos Farkas, Ilango Ganga, Ariel Hendel, Vinit Jain,		Berger, John Drake, Janos Farkas, Ilango Ganga, Ariel Hendel, Vinit
	Petr Lapukhov, Thomas Morin, Benson Schliesser, Lucy Yong and many		Jain, Petr Lapukhov, Thomas Morin, Benson Schliesser, Xiaohu Xu, Lucy
	others on the NVO3 mailing list.		Yong and many others on the NVO3 mailing list.
	9. IANA Considerations		9. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	10. Security Considerations		10. Security Considerations
	Because this document describes the problem space associated with the		Because this document describes the problem space associated with the
	need for virtualization of networks in complex, large-scale, data-		need for virtualization of networks in complex, large-scale, data-
	center networks, it does not itself introduce any security risks.		center networks, it does not itself introduce any security risks.
	However, it is clear that security concerns need to be a		However, it is clear that security concerns need to be a
	consideration of any solutions proposed to address this problem		consideration of any solutions proposed to address this problem
	space.		space.
	11. Informative References		Solutions will need to address both data plane and control plane
			security concerns. In the data plane, isolation between NVO3 domains
			is a primary concern. Assurances against spoofing, snooping, transit
			modification and denial of service are examples of other important
			considerations. Some limited environments may even require
			confidentially within domains.
	[I-D.ietf-armd-problem-statement]		In the control plane, the primary security concern is ensuring that
	Narten, T., Karir, M., and I. Foo, "Address Resolution		unauthorized control information is not installed for use in the data
	Problems in Large Data Center Networks",		plane. The prevention of the installation of improper control
	draft-ietf-armd-problem-statement-04 (work in progress),		information, and other forms of denial of service are also concerns.
	October 2012.		Hereto, some environments may also be concerned about confidentiality
			of the control plane.
			11. Informative References
	[I-D.ietf-l2vpn-evpn]		[I-D.ietf-l2vpn-evpn]
	Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F.,		Sajassi, A., Aggarwal, R., Henderickx, W., Balus, F.,
	Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN",		Isaac, A., and J. Uttaro, "BGP MPLS Based Ethernet VPN",
	draft-ietf-l2vpn-evpn-01 (work in progress), July 2012.		draft-ietf-l2vpn-evpn-02 (work in progress), October 2012.
	[I-D.ietf-lisp]
	Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-23 (work in progress), May 2012.
	[I-D.ietf-trill-fine-labeling]		[I-D.ietf-trill-fine-labeling]
	Eastlake, D., Zhang, M., Agarwal, P., Perlman, R., and D.		Eastlake, D., Zhang, M., Agarwal, P., Perlman, R., and D.
	Dutt, "TRILL: Fine-Grained Labeling",		Dutt, "TRILL: Fine-Grained Labeling",
	draft-ietf-trill-fine-labeling-02 (work in progress),		draft-ietf-trill-fine-labeling-04 (work in progress),
	October 2012.		December 2012.
	[I-D.lasserre-nvo3-framework]		[I-D.lasserre-nvo3-framework]
	Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.		Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
	Rekhter, "Framework for DC Network Virtualization",		Rekhter, "Framework for DC Network Virtualization",
	draft-lasserre-nvo3-framework-03 (work in progress),		draft-lasserre-nvo3-framework-03 (work in progress),
	July 2012.		July 2012.
	[I-D.marques-l3vpn-end-system]		[I-D.marques-l3vpn-end-system]
	Marques, P., Fang, L., Pan, P., Shukla, A., Napierala, M.,		Marques, P., Fang, L., Pan, P., Shukla, A., Napierala, M.,
	and N. Bitar, "BGP-signaled end-system IP/VPNs.",		and N. Bitar, "BGP-signaled end-system IP/VPNs.",
	draft-marques-l3vpn-end-system-07 (work in progress),		draft-marques-l3vpn-end-system-07 (work in progress),
	August 2012.		August 2012.
	[I-D.raggarwa-data-center-mobility]		[I-D.raggarwa-data-center-mobility]
	Aggarwal, R., Rekhter, Y., Henderickx, W., Shekhar, R.,		Aggarwal, R., Rekhter, Y., Henderickx, W., Shekhar, R.,
	and L. Fang, "Data Center Mobility based on BGP/MPLS, IP		Fang, L., and A. Sajassi, "Data Center Mobility based on
	Routing and NHRP", draft-raggarwa-data-center-mobility-03		E-VPN, BGP/MPLS IP VPN, IP Routing and NHRP",
	(work in progress), June 2012.		draft-raggarwa-data-center-mobility-04 (work in progress),
			December 2012.
	[Qbg] "IEEE P802.1Qbg Edge Virtual Bridging", February 2012.		[Qbg] "IEEE P802.1Qbg Edge Virtual Bridging", February 2012.
	[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling		[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
	Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.		Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
	[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private		[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
	Networks (VPNs)", RFC 4364, February 2006.		Networks (VPNs)", RFC 4364, February 2006.
	[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,		[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
	skipping to change at page 20, line 39 ¶		skipping to change at page 21, line 14 ¶
	Mobile IPv6", RFC 5845, June 2010.		Mobile IPv6", RFC 5845, June 2010.
	[RFC6245] Yegani, P., Leung, K., Lior, A., Chowdhury, K., and J.		[RFC6245] Yegani, P., Leung, K., Lior, A., Chowdhury, K., and J.
	Navali, "Generic Routing Encapsulation (GRE) Key Extension		Navali, "Generic Routing Encapsulation (GRE) Key Extension
	for Mobile IPv4", RFC 6245, May 2011.		for Mobile IPv4", RFC 6245, May 2011.
	[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.		[RFC6325] Perlman, R., Eastlake, D., Dutt, D., Gai, S., and A.
	Ghanwani, "Routing Bridges (RBridges): Base Protocol		Ghanwani, "Routing Bridges (RBridges): Base Protocol
	Specification", RFC 6325, July 2011.		Specification", RFC 6325, July 2011.
	[SPBM] "IEEE P802.1aq/D4.5 Draft Standard for Local and		[RFC6820] Narten, T., Karir, M., and I. Foo, "Address Resolution
			Problems in Large Data Center Networks", RFC 6820,
			January 2013.
			[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
			Locator/ID Separation Protocol (LISP)", RFC 6830,
			January 2013.
			[SPB] "IEEE P802.1aq/D4.5 Draft Standard for Local and
	Metropolitan Area Networks -- Media Access Control (MAC)		Metropolitan Area Networks -- Media Access Control (MAC)
	Bridges and Virtual Bridged Local Area Networks,		Bridges and Virtual Bridged Local Area Networks,
	Amendment 8: Shortest Path Bridging", February 2012.		Amendment 8: Shortest Path Bridging", February 2012.
	Appendix A. Change Log		Appendix A. Change Log
	A.1. Changes From -00 to -01		A.1. Changes From -01 to -02
			1. Security Considerations changes (Lou Berger)
			2. Changes to section on Optimal Forwarding (Xuxiaohu)
			3. More wording improvements in L2 details (Janos Farkas)
			4. Referennces to ARMD and LISP documets are now RFCs.
			A.2. Changes From -00 to -01
	1. Numerous editorial and clarity improvements.		1. Numerous editorial and clarity improvements.
	2. Picked up updated terminology from the framework document (e.g.,		2. Picked up updated terminology from the framework document (e.g.,
	Tenant System).		Tenant System).
	3. Significant changes regarding IEEE 802.1 Ethernets and VLANs.		3. Significant changes regarding IEEE 802.1 Ethernets and VLANs.
	All text moved to the Related Work section, where the technology		All text moved to the Related Work section, where the technology
	is summarized.		is summarized.
	skipping to change at page 21, line 28 ¶		skipping to change at page 22, line 21 ¶
	that IP is assumed as the underlay transport in the data center.		that IP is assumed as the underlay transport in the data center.
	6. Added new section (2.6) on Optimal Forwarding.		6. Added new section (2.6) on Optimal Forwarding.
	7. Added a section on Data Plane issues.		7. Added a section on Data Plane issues.
	8. Significant improvement to Section describing SPBM.		8. Significant improvement to Section describing SPBM.
	9. Added sub-section on VDP in "Related Work"		9. Added sub-section on VDP in "Related Work"
	A.2. Changes from draft-narten-nvo3-overlay-problem-statement-04.txt		A.3. Changes from draft-narten-nvo3-overlay-problem-statement-04.txt
	1. This document has only one substantive change relative to		1. This document has only one substantive change relative to
	draft-narten-nvo3-overlay-problem-statement-04.txt. Two		draft-narten-nvo3-overlay-problem-statement-04.txt. Two
	sentences were removed per the discussion that led to WG adoption		sentences were removed per the discussion that led to WG adoption
	of this document.		of this document.
	Authors' Addresses		Authors' Addresses
	Thomas Narten (editor)		Thomas Narten (editor)
	IBM		IBM
	skipping to change at page 22, line 4 ¶		skipping to change at page 22, line 39 ¶
	Thomas Narten (editor)		Thomas Narten (editor)
	IBM		IBM
	Email: narten@us.ibm.com		Email: narten@us.ibm.com
	Eric Gray (editor)		Eric Gray (editor)
	Ericsson		Ericsson
	Email: eric.gray@ericsson.com		Email: eric.gray@ericsson.com
	David Black		David Black
	EMC		EMC
	Email: david.black@emc.com		Email: david.black@emc.com
	Dinesh Dutt		Dinesh Dutt
			Cumulus Networks
	Email: ddutt.ietf@hobbesdutt.com		Email: ddutt.ietf@hobbesdutt.com
	Luyuan Fang		Luyuan Fang
	Cisco Systems		Cisco Systems
	111 Wood Avenue South		111 Wood Avenue South
	Iselin, NJ 08830		Iselin, NJ 08830
	USA		USA
	Email: lufang@cisco.com		Email: lufang@cisco.com
End of changes. 36 change blocks.
	83 lines changed or deleted		124 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/