< draft-ietf-nvo3-hpvr2nve-cp-req-13.txt		draft-ietf-nvo3-hpvr2nve-cp-req-14.txt >
	NVO3 Working Group Y. Li		NVO3 Working Group Y. Li
	INTERNET-DRAFT D. Eastlake		INTERNET-DRAFT D. Eastlake
	Intended Status: Informational Huawei Technologies		Intended Status: Informational Huawei Technologies
	L. Kreeger		L. Kreeger
	Arrcus, Inc		Arrcus, Inc
	T. Narten		T. Narten
	IBM		IBM
	D. Black		D. Black
	EMC		Dell EMC
	Expires: July 28, 2018 January 24, 2018		Expires: August 12, 2018 February 8, 2018
	Split Network Virtualization Edge (Split-NVE) Control Plane Requirements		Split Network Virtualization Edge (Split-NVE) Control Plane Requirements
	draft-ietf-nvo3-hpvr2nve-cp-req-13		draft-ietf-nvo3-hpvr2nve-cp-req-14
	Abstract		Abstract
	In a Split Network Virtualization Edge (Split-NVE) architecture, the		In a Split Network Virtualization Edge (Split-NVE) architecture, the
	functions of the NVE (Network Virtualization Edge) are split across a		functions of the NVE (Network Virtualization Edge) are split across a
	server and an external network equipment which is called an external		server and an external network equipment which is called an external
	NVE. The server-resident control plane functionality resides in		NVE. The server-resident control plane functionality resides in
	control software, which may be part of hypervisor or container		control software, which may be part of hypervisor or container
	management software; for simplicity, this document refers to the		management software; for simplicity, this document refers to the
	hypervisor as the location of this software.		hypervisor as the location of this software.
	skipping to change at page 3, line 5 ¶		skipping to change at page 3, line 5 ¶
	3.2 TSI Associate and Activate . . . . . . . . . . . . . . . . . 12		3.2 TSI Associate and Activate . . . . . . . . . . . . . . . . . 12
	3.3 TSI Disassociate and Deactivate . . . . . . . . . . . . . . 15		3.3 TSI Disassociate and Deactivate . . . . . . . . . . . . . . 15
	4. Hypervisor-to-NVE Control Plane Protocol Requirements . . . . . 16		4. Hypervisor-to-NVE Control Plane Protocol Requirements . . . . . 16
	5. VDP Applicability and Enhancement Needs . . . . . . . . . . . . 17		5. VDP Applicability and Enhancement Needs . . . . . . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . . 19		6. Security Considerations . . . . . . . . . . . . . . . . . . . . 19
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 19
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	8.1 Normative References . . . . . . . . . . . . . . . . . . . 20		8.1 Normative References . . . . . . . . . . . . . . . . . . . 20
	8.2 Informative References . . . . . . . . . . . . . . . . . . 20		8.2 Informative References . . . . . . . . . . . . . . . . . . 20
	Appendix A. IEEE 802.1Qbg VDP Illustration (For information		Appendix A. IEEE 802.1Q VDP Illustration (For information only) . 20
	only) . . . . . . . . . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	In the Split-NVE architecture shown in Figure 1, the functionality of		In the Split-NVE architecture shown in Figure 1, the functionality of
	the NVE (Network Virtualization Edge) is split across an end device		the NVE (Network Virtualization Edge) is split across an end device
	supporting virtualization and an external network device which is		supporting virtualization and an external network device which is
	called an external NVE. The portion of the NVE functionality located		called an external NVE. The portion of the NVE functionality located
	on the end device is called the tNVE and the portion located on the		on the end device is called the tNVE and the portion located on the
	external NVE is called the nNVE in this document. Overlay		external NVE is called the nNVE in this document. Overlay
	skipping to change at page 5, line 5 ¶		skipping to change at page 5, line 5 ¶
	between tNVE and nNVE logical entities. This protocol is mentioned in		between tNVE and nNVE logical entities. This protocol is mentioned in
	the NVO3 problem statement [RFC7364] and appears as the third work		the NVO3 problem statement [RFC7364] and appears as the third work
	item.		item.
	Virtual machine states and state transitioning are summarized in this		Virtual machine states and state transitioning are summarized in this
	document showing events where the NVE needs to take specific actions.		document showing events where the NVE needs to take specific actions.
	Such events might correspond to actions the control plane signaling		Such events might correspond to actions the control plane signaling
	protocol(s) need to take between tNVE and nNVE in the Split-NVE		protocol(s) need to take between tNVE and nNVE in the Split-NVE
	scenario. The high level requirements to be fulfilled are stated.		scenario. The high level requirements to be fulfilled are stated.
	+-- -- -- -- Split-NVE -- -- -- --+		+------------ Split-NVE -----------+
	|		| |
	|		| |
	+---------------|-----+		+---------------|-----+ |
	| +------------- ----+| |		| +-------------|----+| |
	| | +--+ +---\|/--+|| +------ --------------+		| | +--+ +---\|/--+|| +------|--------------+
	| | |VM|---+ ||| | \|/ |		| | |VM|---+ ||| | \|/ |
	| | +--+ | ||| |+--------+ |		| | +--+ | ||| |+--------+ |
	| | +--+ | tNVE |||----- - - - - - -----|| | |		| | +--+ | tNVE |||---------------------|| | |
	| | |VM|---+ ||| || nNVE | |		| | |VM|---+ ||| || nNVE | |
	| | +--+ +--------+|| || | |		| | +--+ +--------+|| || | |
	| | || |+--------+ |		| | || |+--------+ |
	| +--Hypervisor------+| +---------------------+		| +--Hypervisor------+| +---------------------+
	+---------------------+		+---------------------+
	End Device External NVE		End Device External NVE
	Figure 1 Split-NVE structure		Figure 1 Split-NVE structure
	skipping to change at page 6, line 40 ¶		skipping to change at page 6, line 40 ¶
	VN Profile: Meta data associated with a VN (Virtual Network) that is		VN Profile: Meta data associated with a VN (Virtual Network) that is
	applied to any attachment point to the VN. That is, VAP (Virtual		applied to any attachment point to the VN. That is, VAP (Virtual
	Access Point) properties that are applied to all VAPs associated with		Access Point) properties that are applied to all VAPs associated with
	a given VN and used by an NVE when ingressing/egressing packets		a given VN and used by an NVE when ingressing/egressing packets
	to/from a specific VN. Meta data could include such information as		to/from a specific VN. Meta data could include such information as
	ACLs, QoS settings, etc. The VN Profile contains parameters that		ACLs, QoS settings, etc. The VN Profile contains parameters that
	apply to the VN as a whole. Control protocols between the NVE and		apply to the VN as a whole. Control protocols between the NVE and
	NVA (Network Virtualization Authority) could use the VN ID or VN Name		NVA (Network Virtualization Authority) could use the VN ID or VN Name
	to obtain the VN Profile.		to obtain the VN Profile.
	VSI: Virtual Station Interface. [IEEE 802.1Qbg]		VSI: Virtual Station Interface. [IEEE 802.1Q]
	VDP: VSI Discovery and Configuration Protocol [IEEE 802.1Qbg]		VDP: VSI Discovery and Configuration Protocol [IEEE 802.1Q]
	1.2 Target Scenarios		1.2 Target Scenarios
	In the Split-NVE architecture, an external NVE can provide an offload		In the Split-NVE architecture, an external NVE can provide an offload
	of the encapsulation / decapsulation functions and network policy		of the encapsulation / decapsulation functions and network policy
	enforcement as well as the VN Overlay protocol overhead. This		enforcement as well as the VN Overlay protocol overhead. This
	offloading may improve performance and/or save resources in the End		offloading may improve performance and/or save resources in the End
	Device (e.g. hypervisor) using the external NVE.		Device (e.g. hypervisor) using the external NVE.
	The following figures give example scenarios of a Split-NVE		The following figures give example scenarios of a Split-NVE
	skipping to change at page 8, line 5 ¶		skipping to change at page 8, line 5 ¶
	| |Net Service |----| / | | | |		| |Net Service |----| / | | | |
	| |Instance | | / | | | |		| |Instance | | / | | | |
	| +------------+ | / | | | |		| +------------+ | / | | | |
	+--------------------------+ +-----+-------+		+--------------------------+ +-----+-------+
	Figure 4 Physical Network Service Appliance with an External NVE		Figure 4 Physical Network Service Appliance with an External NVE
	Tenant Systems connect to external NVEs via a Tenant System Interface		Tenant Systems connect to external NVEs via a Tenant System Interface
	(TSI). The TSI logically connects to the external NVE via a Virtual		(TSI). The TSI logically connects to the external NVE via a Virtual
	Access Point (VAP) [RFC8014]. The external NVE may provide Layer 2 or		Access Point (VAP) [RFC8014]. The external NVE may provide Layer 2 or
	Layer 3 forwarding. In the Split-NVE architecture, the external NVE		Layer 3 forwarding. In the Split-NVE architecture, the external NVE
	may be able to reach multiple MAC and IP addresses via a TSI. For		may be able to reach multiple MAC and IP addresses via a TSI. An IP
	example, Tenant Systems that are providing network services (such as		address can be in either IPv4 or IPv6 format. For example, Tenant
	transparent firewall, load balancer, or VPN gateway) are likely to		Systems that are providing network services (such as transparent
	have a complex address hierarchy. This implies that if a given TSI		firewall, load balancer, or VPN gateway) are likely to have a complex
	disassociates from one VN, all the MAC and/or IP addresses are also		address hierarchy. This implies that if a given TSI disassociates
	disassociated. There is no need to signal the deletion of every MAC		from one VN, all the MAC and/or IP addresses are also disassociated.
	or IP when the TSI is brought down or deleted. In the majority of		There is no need to signal the deletion of every MAC or IP when the
	cases, a VM will be acting as a simple host that will have a single		TSI is brought down or deleted. In the majority of cases, a VM will
	TSI and single MAC and IP visible to the external NVE.		be acting as a simple host that will have a single TSI and single MAC
			and IP visible to the external NVE.
	Figures 2 through 4 show the use of VLANs to separate traffic for		Figures 2 through 4 show the use of VLANs to separate traffic for
	multiple VNs between the tNVE and nNVE; VLANs are not strictly		multiple VNs between the tNVE and nNVE; VLANs are not strictly
	necessary if only one VN is involved, but multiple VNs are expected		necessary if only one VN is involved, but multiple VNs are expected
	in most cases. Hence this draft assumes the presence of VLANs.		in most cases. Hence this draft assumes the presence of VLANs.
	2. VM Lifecycle		2. VM Lifecycle
	Figure 2 of [RFC7666] shows the state transition of a VM. Some of the		Figure 2 of [RFC7666] shows the state transition of a VM. Some of the
	VM states are of interest to the external NVE. This section		VM states are of interest to the external NVE. This section
	skipping to change at page 17, line 46 ¶		skipping to change at page 17, line 46 ¶
	Req-12: The protocol MUST be able to run over L2 links between the		Req-12: The protocol MUST be able to run over L2 links between the
	End Device and its External NVE.		End Device and its External NVE.
	Req-13: The protocol SHOULD support the End Device indicating if an		Req-13: The protocol SHOULD support the End Device indicating if an
	associate or activate request from it is the result of a VM hot		associate or activate request from it is the result of a VM hot
	migration event.		migration event.
	5. VDP Applicability and Enhancement Needs		5. VDP Applicability and Enhancement Needs
	Virtual Station Interface (VSI) Discovery and Configuration Protocol		Virtual Station Interface (VSI) Discovery and Configuration Protocol
	(VDP) [IEEE 802.1Qbg] can be the control plane protocol running		(VDP) [IEEE 802.1Q] can be the control plane protocol running between
	between the hypervisor and the external NVE. Appendix A illustrates		the hypervisor and the external NVE. Appendix A illustrates VDP for
	VDP for the reader's information.		the reader's information.
	VDP facilitates the automatic discovery and configuration of Edge		VDP facilitates the automatic discovery and configuration of Edge
	Virtual Bridging (EVB) stations and Edge Virtual Bridging (EVB)		Virtual Bridging (EVB) stations and Edge Virtual Bridging (EVB)
	bridges. An EVB station is normally an end station running multiple		bridges. An EVB station is normally an end station running multiple
	VMs. It is conceptually equivalent to a hypervisor in this document.		VMs. It is conceptually equivalent to a hypervisor in this document.
	An EVB bridge is conceptually equivalent to the external NVE.		An EVB bridge is conceptually equivalent to the external NVE.
	VDP is able to pre-associate/associate/de-associate a VSI on an EVB		VDP is able to pre-associate/associate/de-associate a VSI on an EVB
	station with a port on the EVB bridge. A VSI is approximately the		station with a port on the EVB bridge. A VSI is approximately the
	concept of a virtual port by which a VM connects to the hypervisor in		concept of a virtual port by which a VM connects to the hypervisor in
	this document's context. The EVB station and the EVB bridge can reach		this document's context. The EVB station and the EVB bridge can reach
	agreement on VLAN ID(s) assigned to a VSI via VDP message exchange.		agreement on VLAN ID(s) assigned to a VSI via VDP message exchange.
	Other configuration parameters can be exchanged via VDP as well. VDP		Other configuration parameters can be exchanged via VDP as well. VDP
	is carried over the Edge Control Protocol(ECP) [IEEE 802.1Qbg] which		is carried over the Edge Control Protocol(ECP) [IEEE 802.1Q] which
	provides a reliable transportation over a layer 2 network.		provides a reliable transportation over a layer 2 network.
	VDP protocol needs some extensions to fulfill the requirements listed		VDP protocol needs some extensions to fulfill the requirements listed
	in this document. Table 1 shows the needed extensions and/or		in this document. Table 1 shows the needed extensions and/or
	clarifications in the NVO3 context.		clarifications in the NVO3 context.
	+------+-----------+-----------------------------------------------+		+------+-----------+-----------------------------------------------+
	| Req | Supported | remarks |		| Req | Supported | remarks |
	| | by VDP? | |		| | by VDP? | |
	+------+-----------+-----------------------------------------------+		+------+-----------+-----------------------------------------------+
	skipping to change at page 20, line 16 ¶		skipping to change at page 20, line 16 ¶
	mechanism, and draft-kompella-nvo3-server2nve. Thanks to all the co-		mechanism, and draft-kompella-nvo3-server2nve. Thanks to all the co-
	authors and contributing members of those drafts.		authors and contributing members of those drafts.
	The authors would like to specially thank Lucy Yong and Jon Hudson		The authors would like to specially thank Lucy Yong and Jon Hudson
	for their generous help in improving this document.		for their generous help in improving this document.
	8. References		8. References
	8.1 Normative References		8.1 Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Rekhter, "Framework for DC Network Virtualization",
			October 2014.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC7666] Asai H., MacFaden M., Schoenwaelder J., Shima K., Tsou T.,
	2119 Key Words ", BCP 14, RFC 8174, May 2017.		"Management Information Base for Virtual Machines
			Controlled by a Hypervisor", October 2015.
			[RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., Narten,
			T., "An Architecture for Data-Center Network
			Virtualization over Layer 3 (NVO3)", December 2016.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
			Key Words ", BCP 14, RFC 8174, May 2017.
			[IEEE 802.1Q] IEEE, "Media Access Control (MAC) Bridges and Virtual
			Bridged Local Area Networks", IEEE Std 802.1Q-2014,
			November 2014.
	8.2 Informative References		8.2 Informative References
	[RFC2236] Fenner, W., "Internet Group Management Protocol, Version		[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
	2", RFC 2236, November 1997.		2", RFC 2236, November 1997.
	[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally		[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
	Unique IDentifier (UUID) URN Namespace", RFC 4122, July		Unique IDentifier (UUID) URN Namespace", RFC 4122, July
	2005.		2005.
	[RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., and		[RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., and
	M. Napierala, "Problem Statement: Overlays for Network		M. Napierala, "Problem Statement: Overlays for Network
	Virtualization", October 2014.		Virtualization", October 2014.
	[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.		Appendix A. IEEE 802.1Q VDP Illustration (For information only)
	Rekhter, "Framework for DC Network Virtualization",
	October 2014.
	[RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., Narten,
	T., "An Architecture for Data-Center Network
	Virtualization over Layer 3 (NVO3)", December 2016.
	[RFC7666] Asai H., MacFaden M., Schoenwaelder J., Shima K., Tsou T.,
	"Management Information Base for Virtual Machines
	Controlled by a Hypervisor", October 2015.
	[IEEE 802.1Qbg] IEEE, "Media Access Control (MAC) Bridges and Virtual
	Bridged Local Area Networks - Amendment 21: Edge Virtual
	Bridging", IEEE Std 802.1Qbg, 2012
	[IEEE 802.1Q] IEEE, "Media Access Control (MAC) Bridges and Virtual
	Bridged Local Area Networks", IEEE Std 802.1Q-2014,
	November 2014.
	Appendix A. IEEE 802.1Qbg VDP Illustration (For information only)
	The VDP (VSI Discovery and Discovery and Configuration Protocol [IEEE		The VDP (VSI Discovery and Discovery and Configuration Protocol [IEEE
	802.1Qbg]) can be considered as a controlling protocol running between		802.1Q]) can be considered as a controlling protocol running between
	the hypervisor and the external bridge. VDP association TLV structure		the hypervisor and the external bridge. VDP association TLV structure
	are formatted as shown in Figure A.1.		are formatted as shown in Figure A.1.
	+--------+--------+------+-----+--------+------+------+-------+------+		+--------+--------+------+-----+--------+------+------+------+------+
	|TLV type|TLV info|Status|VSI |VSI Type|VSI ID|VSI ID|Filter |Filter|		|TLV type|TLV info|Status|VSI |VSI Type|VSI ID|VSI ID|Filter|Filter|
	| |string | |Type |Version |Format| |Info |Info |		| |string | |Type |Version |Format| |Info |Info |
	| |length | |ID | | | |format | |		| |length | |ID | | | |format| |
	+--------+--------+------+-----+--------+------+------+-------+------+		+--------+--------+------+-----+--------+------+------+------+------+
	| | |<----VSI type&instance----->|<--Filter---->|		| | |<----VSI type&instance----->|<--Filter--->|
	| | |<-------------VSI attributes-------------->|		| | |<-------------VSI attributes------------->|
	|<--TLV header--->|<-----------TLV information string -------------->|		|<--TLV header--->|<-----------TLV information string ------------->|
	Figure A.1: VDP association TLV		Figure A.1: VDP association TLV
	There are basically four TLV types.		There are basically four TLV types.
	1. Pre-associate: Pre-associate is used to pre-associate a VSI instance		1. Pre-associate: Pre-associate is used to pre-associate a VSI
	with a bridge port. The bridge validates the request and returns a		instance with a bridge port. The bridge validates the request and
	failure Status in case of errors. Successful pre-associate does not		returns a failure Status in case of errors. Successful pre-associate
	imply that the indicated VSI Type or provisioning will be applied to any		does not imply that the indicated VSI Type or provisioning will be
	traffic flowing through the VSI. The pre-associate enables faster		applied to any traffic flowing through the VSI. The pre-associate
	response to an associate, by allowing the bridge to obtain the VSI Type		enables faster response to an associate, by allowing the bridge to
	prior to an association.		obtain the VSI Type prior to an association.
	2. Pre-associate with resource reservation: Pre-associate with Resource		2. Pre-associate with resource reservation: Pre-associate with
	Reservation involves the same steps as Pre-associate, but on success it		Resource Reservation involves the same steps as Pre-associate, but on
	also reserves resources in the bridge to prepare for a subsequent		success it also reserves resources in the bridge to prepare for a
	Associate request.		subsequent Associate request.
	3. Associate: Associate creates and activates an association between a		3. Associate: Associate creates and activates an association between
	VSI instance and a bridge port. An bridge allocates any required bridge		a VSI instance and a bridge port. An bridge allocates any required
	resources for the referenced VSI. The bridge activates the configuration		bridge resources for the referenced VSI. The bridge activates the
	for the VSI Type ID. This association is then applied to the traffic		configuration for the VSI Type ID. This association is then applied
	flow to/from the VSI instance.		to the traffic flow to/from the VSI instance.
	4. De-associate: The de-associate is used to remove an association		4. De-associate: The de-associate is used to remove an association
	between a VSI instance and a bridge port. Pre-associated and associated		between a VSI instance and a bridge port. Pre-associated and
	VSIs can be de-associated. De-associate releases any resources that were		associated VSIs can be de-associated. De-associate releases any
	reserved as a result of prior associate or pre-Associate operations for		resources that were reserved as a result of prior associate or pre-
	that VSI instance.		Associate operations for that VSI instance.
	De-associate can be initiated by either side and the other types can		De-associate can be initiated by either side and the other types can
	only be initiated by the server side.		only be initiated by the server side.
	Some important flag values in VDP Status field:		Some important flag values in VDP Status field:
	1. M-bit (Bit 5): Indicates that the user of the VSI (e.g., the VM) is		1. M-bit (Bit 5): Indicates that the user of the VSI (e.g., the VM)
	migrating (M-bit = 1) or provides no guidance on the migration of the		is migrating (M-bit = 1) or provides no guidance on the migration of
	user of the VSI (M-bit = 0). The M-bit is used as an indicator relative		the user of the VSI (M-bit = 0). The M-bit is used as an indicator
	to the VSI that the user is migrating to.		relative to the VSI that the user is migrating to.
	2. S-bit (Bit 6): Indicates that the VSI user (e.g., the VM) is		2. S-bit (Bit 6): Indicates that the VSI user (e.g., the VM) is
	suspended (S-bit = 1) or provides no guidance as to whether the user of		suspended (S-bit = 1) or provides no guidance as to whether the user
	the VSI is suspended (S-bit = 0). A keep-alive Associate request with		of the VSI is suspended (S-bit = 0). A keep-alive Associate request
	S-bit = 1 can be sent when the VSI user is suspended. The S-bit is used		with S-bit = 1 can be sent when the VSI user is suspended. The S-bit
	as an indicator relative to the VSI that the user is migrating from.		is used as an indicator relative to the VSI that the user is
			migrating from.
	The filter information format currently defines 4 types. Each of the		The filter information format currently defines 4 types. Each of the
	filter information is shown in details as follows.		filter information is shown in details as follows.
	1. VID Filter Info format		1. VID Filter Info format
	+---------+------+-------+--------+		+---------+------+-------+--------+
	| #of | PS | PCP | VID |		| #of | PS | PCP | VID |
	|entries |(1bit)|(3bits)|(12bits)|		|entries |(1bit)|(3bits)|(12bits)|
	|(2octets)| | | |		|(2octets)| | | |
	+---------+------+-------+--------+		+---------+------+-------+--------+
	|<--Repeated per entry->|		|<--Repeated per entry->|
	Figure A.2 VID Filter Info format		Figure A.2 VID Filter Info format
	2. MAC/VID Filter Info format		2. MAC/VID Filter Info format
	+---------+--------------+------+-------+--------+		+---------+--------------+------+-------+--------+
	| #of | MAC address | PS | PCP | VID |		| #of | MAC address | PS | PCP | VID |
	|entries | (6 octets) |(1bit)|(3bits)|(12bits)|		|entries | (6 octets) |(1bit)|(3bits)|(12bits)|
	|(2octets)| | | | |		|(2octets)| | | | |
	+---------+--------------+------+-------+--------+		+---------+--------------+------+-------+--------+
	|<--------Repeated per entry---------->|		|<--------Repeated per entry---------->|
	Figure A.3 MAC/VID filter format		Figure A.3 MAC/VID filter format
	3. GroupID/VID Filter Info format		3. GroupID/VID Filter Info format
	+---------+--------------+------+-------+--------+		+---------+--------------+------+-------+--------+
	| #of | GroupID | PS | PCP | VID |		| #of | GroupID | PS | PCP | VID |
	|entries | (4 octets) |(1bit)|(3bits)|(12bits)|		|entries | (4 octets) |(1bit)|(3bits)|(12bits)|
	|(2octets)| | | | |		|(2octets)| | | | |
	+---------+--------------+------+-------+--------+		+---------+--------------+------+-------+--------+
	|<--------Repeated per entry---------->|		|<--------Repeated per entry---------->|
	Figure A.4 GroupID/VID filter format		Figure A.4 GroupID/VID filter format
	4. GroupID/MAC/VID Filter Info format		4. GroupID/MAC/VID Filter Info format
	+---------+----------+-------------+------+-----+--------+		+---------+----------+-------------+------+-----+--------+
	| #of | GroupID | MAC address | PS | PCP | VID |		| #of | GroupID | MAC address | PS | PCP | VID |
	|entries |(4 octets)| (6 octets) |(1bit)|(3b )|(12bits)|		|entries |(4 octets)| (6 octets) |(1bit)|(3b )|(12bits)|
	|(2octets)| | | | | |		|(2octets)| | | | | |
	+---------+----------+-------------+------+-----+--------+		+---------+----------+-------------+------+-----+--------+
	|<-------------Repeated per entry------------->|		|<-------------Repeated per entry------------->|
	Figure A.5 GroupID/MAC/VID filter format		Figure A.5 GroupID/MAC/VID filter format
	The null VID can be used in the VDP Request sent from the station to the		The null VID can be used in the VDP Request sent from the station to
	external bridge. Use of the null VID indicates that the set of VID		the external bridge. Use of the null VID indicates that the set of
	values associated with the VSI is expected to be supplied by the bridge.		VID values associated with the VSI is expected to be supplied by the
	The set of VID values is returned to the station via the VDP Response.		bridge. The set of VID values is returned to the station via the VDP
	The returned VID value can be a locally significant value. When GroupID		Response. The returned VID value can be a locally significant value.
	is used, it is equivalent to the VN ID in NVO3. GroupID will be provided		When GroupID is used, it is equivalent to the VN ID in NVO3. GroupID
	by the station to the bridge. The bridge maps GroupID to a locally		will be provided by the station to the bridge. The bridge maps
	significant VLAN ID.		GroupID to a locally significant VLAN ID.
	The VSI ID in VDP association TLV that identify a VM can be one of the		The VSI ID in VDP association TLV that identify a VM can be one of
	following format: IPV4 address, IPV6 address, MAC address, UUID		the following format: IPV4 address, IPV6 address, MAC address, UUID
	[RFC4122], or locally defined.		[RFC4122], or locally defined.
	Authors' Addresses		Authors' Addresses
	Yizhou Li		Yizhou Li
	Huawei Technologies		Huawei Technologies
	101 Software Avenue,		101 Software Avenue,
	Nanjing 210012		Nanjing 210012
	China		China
	Phone: +86-25-56625409		Phone: +86-25-56625409
	skipping to change at page 24, line 12 ¶		skipping to change at page 24, line 4 ¶
	Donald Eastlake		Donald Eastlake
	Huawei R&D USA		Huawei R&D USA
	155 Beaver Street		155 Beaver Street
	Milford, MA 01757 USA		Milford, MA 01757 USA
	Phone: +1-508-333-2270		Phone: +1-508-333-2270
	EMail: d3e3e3@gmail.com		EMail: d3e3e3@gmail.com
	Lawrence Kreeger		Lawrence Kreeger
	Arrcus, Inc		Arrcus, Inc
	Email: lkreeger@gmail.com		Email: lkreeger@gmail.com
	Thomas Narten		Thomas Narten
	IBM		IBM
	Email: narten@us.ibm.com		Email: narten@us.ibm.com
	David Black		David Black
	EMC		Dell EMC
			176 South Street,
			Hopkinton, MA 01748 USA
	Email: david.black@emc.com		Email: david.black@dell.com
End of changes. 39 change blocks.
	146 lines changed or deleted		142 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/