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.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/