< draft-ietf-nvo3-hpvr2nve-cp-req-07.txt   draft-ietf-nvo3-hpvr2nve-cp-req-08.txt >
NVO3 Working Group Yizhou Li NVO3 Working Group Y. Li
INTERNET-DRAFT Lucy Yong INTERNET-DRAFT D. Eastlake
Intended Status: Informational Huawei Technologies Intended Status: Informational Huawei Technologies
Lawrence Kreeger L. Kreeger
Cisco Cisco
Thomas Narten T. Narten
IBM IBM
David Black D. Black
EMC EMC
Expires: February 24, 2018 August 23, 2017 Expires: April 29, 2018 October 26, 2017
Split-NVE Control Plane Requirements Split-NVE Control Plane Requirements
draft-ietf-nvo3-hpvr2nve-cp-req-07 draft-ietf-nvo3-hpvr2nve-cp-req-08
Abstract Abstract
In a Split-NVE architecture, the functions of the NVE are split In a Split-NVE architecture, the functions of the NVE (Network
across a server and an external network equipment which is called an Virtualization Edge) are split across a server and an external
external NVE. The server-resident control plane functionality network equipment which is called an external NVE. The server-
resides in control software, which may be part of a hypervisor or resident control plane functionality resides in control software,
container management software; for simplicity, this draft refers to which may be part of a hypervisor or container management software;
the hypervisor as the location of this software. for simplicity, this draft refers to the hypervisor as the location
of this software.
A control plane protocol(s) between a hypervisor and its associated Control plane protocol(s) between a hypervisor and its associated
external NVE(s) is used for the hypervisor to distribute its virtual external NVE(s) are used by the hypervisor to distribute its virtual
machine networking state to the external NVE(s) for further handling. machine networking state to the external NVE(s) for further handling.
This document illustrates the functionality required by this type of This document illustrates the functionality required by this type of
control plane signaling protocol and outlines the high level control plane signaling protocol and outlines the high level
requirements. Virtual machine states as well as state transitioning requirements. Virtual machine states as well as state transitioning
are summarized to help clarifying the needed protocol requirements. are summarized to help clarify the needed protocol requirements.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 38 skipping to change at page 2, line 39
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 Target Scenarios . . . . . . . . . . . . . . . . . . . . . 6 1.2 Target Scenarios . . . . . . . . . . . . . . . . . . . . . 6
2. VM Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. VM Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1 VM Creation Event . . . . . . . . . . . . . . . . . . . . . 8 2.1 VM Creation Event . . . . . . . . . . . . . . . . . . . . . 8
2.2 VM Live Migration Event . . . . . . . . . . . . . . . . . . 9 2.2 VM Live Migration Event . . . . . . . . . . . . . . . . . . 9
2.3 VM Termination Event . . . . . . . . . . . . . . . . . . . . 10 2.3 VM Termination Event . . . . . . . . . . . . . . . . . . . . 10
2.4 VM Pause, Suspension and Resumption Events . . . . . . . . . 10 2.4 VM Pause, Suspension and Resumption Events . . . . . . . . . 10
3. Hypervisor-to-NVE Control Plane Protocol Functionality . . . . 10 3. Hypervisor-to-NVE Control Plane Protocol Functionality . . . . 10
3.1 VN connect and Disconnect . . . . . . . . . . . . . . . . . 11 3.1 VN Connect and Disconnect . . . . . . . . . . . . . . . . . 11
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
skipping to change at page 3, line 4 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.1Qbg VDP Illustration (For information
only) . . . . . . . . . . . . . . . . . . . . . . . . . . 20 only) . . . . . . . . . . . . . . . . . . . . . . . . . . 20
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 is split across an end device supporting virtualization and the NVE (Network Virtualization Edge) is split across an end device
an external network device which is called an external NVE. The supporting virtualization and an external network device which is
portion of the NVE functionality located on the end device is called called an external NVE. The portion of the NVE functionality located
the tNVE and the portion located on the external NVE is called the on the end device is called the tNVE and the portion located on the
nNVE in this document. Overlay encapsulation/decapsulation functions external NVE is called the nNVE in this document. Overlay
are normally off-loaded to the nNVE on the external NVE. encapsulation/decapsulation functions are normally off-loaded to the
nNVE on the external NVE.
The tNVE is normally implemented as a part of hypervisor or container The tNVE is normally implemented as a part of hypervisor or container
and/or virtual switch in an virtualized end device. This document and/or virtual switch in an virtualized end device. This document
uses the term "hypervisor" throughout when describing the Split-NVE uses the term "hypervisor" throughout when describing the Split-NVE
scenario where part of the NVE functionality is off-loaded to a scenario where part of the NVE functionality is off-loaded to a
separate device from the "hypervisor" that contains a VM connected to separate device from the "hypervisor" that contains a VM connected to
a VN. In this context, the term "hypervisor" is meant to cover any a VN. In this context, the term "hypervisor" is meant to cover any
device type where part of the NVE functionality is off-loaded in this device type where part of the NVE functionality is off-loaded in this
fashion, e.g.,a Network Service Appliance, Linux Container. fashion, e.g.,a Network Service Appliance or Linux Container.
The problem statement [RFC7364], discusses the needs for a control The problem statement [RFC7364], discusses the needs for a control
plane protocol (or protocols) to populate each NVE with the state plane protocol (or protocols) to populate each NVE with the state
needed to perform the required functions. In one scenario, an NVE needed to perform the required functions. In one scenario, an NVE
provides overlay encapsulation/decapsulation packet forwarding provides overlay encapsulation/decapsulation packet forwarding
services to Tenant Systems (TSs) that are co-resident within the NVE services to Tenant Systems (TSs) that are co-resident within the NVE
on the same End Device (e.g. when the NVE is embedded within a on the same End Device (e.g. when the NVE is embedded within a
hypervisor or a Network Service Appliance). In such cases, there is hypervisor or a Network Service Appliance). In such cases, there is
no need for a standardized protocol between the hypervisor and NVE, no need for a standardized protocol between the hypervisor and NVE,
as the interaction is implemented via software on a single device. as the interaction is implemented via software on a single device.
While in the Split-NVE architecture scenarios, as shown in figure 2 While in the Split-NVE architecture scenarios, as shown in figure 2
to figure 4, a control plane protocol(s) between a hypervisor and its to figure 4, control plane protocol(s) between a hypervisor and its
associated external NVE(s) is required for the hypervisor to associated external NVE(s) are required for the hypervisor to
distribute the virtual machines networking states to the NVE(s) for distribute the virtual machines networking states to the NVE(s) for
further handling. The protocol indeed is an NVE-internal protocol and further handling. The protocol is an NVE-internal protocol and runs
runs between tNVE and nNVE logical entities. This protocol is between tNVE and nNVE logical entities. This protocol is mentioned in
mentioned in NVO3 problem statement [RFC7364] and appears as the NVO3 problem statement [RFC7364] and appears as the third work item.
third work item.
Virtual machine states and state transitioning are summarized in this Virtual machine states and state transitioning are summarized in this
document to show events where the NVE needs to take specific actions. document to show 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
protocols between the hypervisor and external NVE will need to take. protocol(s) need to take between the hypervisor and external NVE
Then the high level requirements to be fulfilled are outlined. will. Then the high level requirements to be fulfilled are
satisfied.
+-- -- -- -- Split-NVE -- -- -- --+ +-- -- -- -- Split-NVE -- -- -- --+
| |
| |
+---------------|-----+ +---------------|-----+
| +------------- ----+| | | +------------- ----+| |
| | +--+ +---\|/--+|| +------ --------------+ | | +--+ +---\|/--+|| +------ --------------+
| | |VM|---+ ||| | \|/ | | | |VM|---+ ||| | \|/ |
| | +--+ | ||| |+--------+ | | | +--+ | ||| |+--------+ |
| | +--+ | tNVE |||----- - - - - - -----|| | | | | +--+ | tNVE |||----- - - - - - -----|| | |
skipping to change at page 5, line 29 skipping to change at page 5, line 29
End Device External NVE End Device External NVE
Figure 1 Split-NVE structure Figure 1 Split-NVE structure
This document uses VMs as an example of Tenant Systems (TSs) in order This document uses VMs as an example of Tenant Systems (TSs) in order
to describe the requirements, even though a VM is just one type of to describe the requirements, even though a VM is just one type of
Tenant System that may connect to a VN. For example, a service Tenant System that may connect to a VN. For example, a service
instance within a Network Service Appliance is another type of TS, as instance within a Network Service Appliance is another type of TS, as
are systems running on an OS-level virtualization technologies like are systems running on an OS-level virtualization technologies like
containers. The fact that VMs have lifecycles(e.g., can be created containers. The fact that VMs have lifecycles (e.g., can be created
and destroyed), can be moved, and can be started or stopped results and destroyed, can be moved, and can be started or stopped) results
in a general set of protocol requirements, most of which are in a general set of protocol requirements, most of which are
applicable to other forms of TSs. It should also be noted that not applicable to other forms of TSs. Note that not all of the
all of the requirements are applicable to all forms of TSs. requirements are applicable to all forms of TSs.
Section 2 describes VM states and state transitioning in its Section 2 describes VM states and state transitioning in the VM's
lifecycle. Section 3 introduces Hypervisor-to-NVE control plane lifecycle. Section 3 introduces Hypervisor-to-NVE control plane
protocol functionality derived from VM operations and network events. protocol functionality derived from VM operations and network events.
Section 4 outlines the requirements of the control plane protocol to Section 4 outlines the requirements of the control plane protocol to
achieve the required functionality. achieve the required functionality.
1.1 Terminology 1.1 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 6, line 44 skipping to change at page 6, line 44
protocols between the NVE and NVA could use the VN ID or VN Name to protocols between the NVE and NVA could use the VN ID or VN Name to
obtain the VN Profile. obtain the VN Profile.
VSI: Virtual Station Interface. [IEEE 802.1Qbg] VSI: Virtual Station Interface. [IEEE 802.1Qbg]
VDP: VSI Discovery and Configuration Protocol [IEEE 802.1Qbg] VDP: VSI Discovery and Configuration Protocol [IEEE 802.1Qbg]
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 function, 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 provide performance improvements and/or resource offloading may provide performance improvements and/or resource
savings to the End Device (e.g. hypervisor) making use of the savings to the End Device (e.g. hypervisor) making use of the
external NVE. external NVE.
The following figures give example scenarios of a Split-NVE The following figures give example scenarios of a Split-NVE
architecture. architecture.
Hypervisor Access Switch Hypervisor Access Switch
+------------------+ +-----+-------+ +------------------+ +-----+-------+
| +--+ +-------+ | | | | | +--+ +-------+ | | | |
skipping to change at page 7, line 47 skipping to change at page 7, line 47
| +------------+ | / | | | | | +------------+ | / | | | |
+--------------------------+ +-----+-------+ +--------------------------+ +-----+-------+
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) [I-D.ietf-nvo3-arch]. The external NVE may provide Access Point (VAP) [I-D.ietf-nvo3-arch]. The external NVE may provide
Layer 2 or Layer 3 forwarding. In the Split-NVE architecture, the Layer 2 or Layer 3 forwarding. In the Split-NVE architecture, the
external NVE may be able to reach multiple MAC and IP addresses via a external NVE may be able to reach multiple MAC and IP addresses via a
TSI. For example, Tenant Systems that are providing network services TSI. For example, Tenant Systems that are providing network services
(such as transparent firewall, load balancer, VPN gateway) are likely (such as transparent firewall, load balancer, or VPN gateway) are
to have complex address hierarchy. This implies that if a given TSI likely to have a complex address hierarchy. This implies that if a
disassociates from one VN, all the MAC and/or IP addresses are also given TSI disassociates from one VN, all the MAC and/or IP addresses
disassociated. There is no need to signal the deletion of every MAC are also disassociated. There is no need to signal the deletion of
or IP when the TSI is brought down or deleted. In the majority of every MAC or IP when the TSI is brought down or deleted. In the
cases, a VM will be acting as a simple host that will have a single majority of cases, a VM will be acting as a simple host that will
TSI and single MAC and IP visible to the external NVE. have a single TSI and single MAC and IP visible to the external NVE.
Figures 2-4 show the use of VLANs to separate traffic for multiple Figures 2 through 4 show the use of VLANs to separate traffic for
VNs between the tNVE and nNVE; VLANs are not strictly necessary if multiple VNs between the tNVE and nNVE; VLANs are not strictly
only one VN is involved, but multiple VNs are expected in most cases, necessary if only one VN is involved, but multiple VNs are expected
and hence this draft assumes their presence. in most cases, and hence this draft assumes their presence.
2. VM Lifecycle 2. VM Lifecycle
Figure 2 of [I-D.ietf-opsawg-vmm-mib] shows the state transition of a Figure 2 of [I-D.ietf-opsawg-vmm-mib] shows the state transition of a
VM. Some of the VM states are of interest to the external NVE. This VM. Some of the VM states are of interest to the external NVE. This
section illustrates the relevant phases and events in the VM section illustrates the relevant phases and events in the VM
lifecycle. It should be noted that the following subsections do not lifecycle. Note that the following subsections do not give an
give an exhaustive traversal of VM lifecycle state. They are intended exhaustive traversal of VM lifecycle state. They are intended as the
as the illustrative examples which are relevant to Split-NVE illustrative examples which are relevant to Split-NVE architecture,
architecture, not as prescriptive text; the goal is to capture not as prescriptive text; the goal is to capture sufficient detail to
sufficient detail to set a context for the signaling protocol set a context for the signaling protocol functionality and
functionality and requirements described in the following sections. requirements described in the following sections.
2.1 VM Creation Event 2.1 VM Creation Event
VM creation event makes the VM state transiting from Preparing to The VM creation event causes the VM state transition from Preparing
Shutdown and then to Running [I-D.ietf-opsawg-vmm-mib]. The end to Shutdown and then to Running [I-D.ietf-opsawg-vmm-mib]. The end
device allocates and initializes local virtual resources like storage device allocates and initializes local virtual resources like storage
in the VM Preparing state. In Shutdown state, the VM has everything in the VM Preparing state. In the Shutdown state, the VM has
ready except that CPU execution is not scheduled by the hypervisor everything ready except that CPU execution is not scheduled by the
and VM's memory is not resident in the hypervisor. From the Shutdown hypervisor and VM's memory is not resident in the hypervisor. From
state to Running state, normally it requires the human execution or the Shutdown state to the Running state, normally it requires human
system triggered event. Running state indicates the VM is in the action or a system triggered event. Running state indicates the VM is
normal execution state. As part of transitioning the VM to the in the normal execution state. As part of transitioning the VM to the
Running state, the hypervisor must also provision network Running state, the hypervisor must also provision network
connectivity for the VM's TSI(s) so that Ethernet frames can be sent connectivity for the VM's TSI(s) so that Ethernet frames can be sent
and received correctly. No ongoing migration, suspension or shutdown and received correctly. No ongoing migration, suspension or shutdown
is in process. is in process.
In the VM creation phase, the VM's TSI has to be associated with the In the VM creation phase, the VM's TSI has to be associated with the
external NVE. Association here indicates that hypervisor and the external NVE. Association here indicates that hypervisor and the
external NVE have signaled each other and reached some agreement. external NVE have signaled each other and reached some agreement.
Relevant networking parameters or information have been provisioned Relevant networking parameters or information have been provisioned
properly. The External NVE should be informed of the VM's TSI MAC properly. The External NVE SHOULD be informed of the VM's TSI MAC
address and/or IP address. In addition to external network address and/or IP address. In addition to external network
connectivity, the hypervisor may provide local network connectivity connectivity, the hypervisor may provide local network connectivity
between the VM's TSI and other VM's TSI that are co-resident on the between the VM's TSI and other VM's TSI that are co-resident on the
same hypervisor. When the intra or inter-hypervisor connectivity is same hypervisor. When the intra or inter-hypervisor connectivity is
extended to the external NVE, a locally significant tag, e.g. VLAN extended to the external NVE, a locally significant tag, e.g. VLAN
ID, should be used between the hypervisor and the external NVE to ID, SHOULD be used between the hypervisor and the external NVE to
differentiate each VN's traffic. Both the hypervisor and external NVE differentiate each VN's traffic. Both the hypervisor and external NVE
sides must agree on that tag value for traffic identification, sides must agree on that tag value for traffic identification,
isolation and forwarding. isolation, and forwarding.
The external NVE may need to do some preparation work before it The external NVE may need to do some preparation before it signals
signals successful association with TSI. Such preparation work may successful association with TSI. Such preparation may include locally
include locally saving the states and binding information of the saving the states and binding information of the tenant system
tenant system interface and its VN, communicating with the NVA for interface and its VN, communicating with the NVA for network
network provisioning, etc. provisioning, etc.
Tenant System interface association should be performed before the VM Tenant System interface association SHOULD be performed before the VM
enters running state, preferably in Shutdown state. If association enters the Running state, preferably in the Shutdown state. If
with external NVE fails, the VM should not go into running state. association with external NVE fails, the VM SHOULD NOT go into the
Running state.
2.2 VM Live Migration Event 2.2 VM Live Migration Event
Live migration is sometimes referred to as "hot" migration, in that Live migration is sometimes referred to as "hot" migration in that,
from an external viewpoint, the VM appears to continue to run while from an external viewpoint, the VM appears to continue to run while
being migrated to another server (e.g., TCP connections generally being migrated to another server (e.g., TCP connections generally
survive this class of migration). In contrast, "cold" migration survive this class of migration). In contrast, "cold" migration
consists of shutdown VM execution on one server and restart it on consists of shutting down VM execution on one server and restarting
another. For simplicity, the following abstract summary about live it on another. For simplicity, the following abstract summary about
migration assumes shared storage, so that the VM's storage is live migration assumes shared storage, so that the VM's storage is
accessible to the source and destination servers. Assume VM live accessible to the source and destination servers. Assume VM live
migrates from hypervisor 1 to hypervisor 2. Such migration event migrates from hypervisor 1 to hypervisor 2. Such migration event
involves the state transition on both hypervisors, source hypervisor involves the state transition on both hypervisors, source hypervisor
1 and destination hypervisor 2. VM state on source hypervisor 1 1 and destination hypervisor 2. VM state on source hypervisor 1
transits from Running to Migrating and then to Shutdown [I-D.ietf- transits from Running to Migrating and then to Shutdown [I-D.ietf-
opsawg-vmm-mib]. VM state on destination hypervisor 2 transits from opsawg-vmm-mib]. VM state on destination hypervisor 2 transits from
Shutdown to Migrating and then Running. Shutdown to Migrating and then Running.
The external NVE connected to destination hypervisor 2 has to The external NVE connected to destination hypervisor 2 has to
associate the migrating VM's TSI with it by discovering the TSI's MAC associate the migrating VM's TSI with it by discovering the TSI's MAC
and/or IP addresses, its VN, locally significant VID if any, and and/or IP addresses, its VN, locally significant VLAN ID if any, and
provisioning other network related parameters of the TSI. The provisioning other network related parameters of the TSI. The
external NVE may be informed about the VM's peer VMs, storage devices external NVE may be informed about the VM's peer VMs, storage devices
and other network appliances with which the VM needs to communicate and other network appliances with which the VM needs to communicate
or is communicating. The migrated VM on destination hypervisor 2 or is communicating. The migrated VM on destination hypervisor 2
SHOULD not go to Running state before all the network provisioning SHOULD not go to Running state before all the network provisioning
and binding has been done. and binding has been done.
The migrating VM SHOULD not be in Running state at the same time on The migrating VM SHOULD not be in Running state at the same time on
the source hypervisor and destination hypervisor during migration. the source hypervisor and destination hypervisor during migration.
The VM on the source hypervisor does not transition into Shutdown The VM on the source hypervisor does not transition into Shutdown
state until the VM successfully enters the Running state on the state until the VM successfully enters the Running state on the
destination hypervisor. It is possible that VM on the source destination hypervisor. It is possible that VM on the source
hypervisor stays in Migrating state for a while after VM on the hypervisor stays in Migrating state for a while after VM on the
destination hypervisor is in Running state. destination hypervisor is in Running state.
2.3 VM Termination Event 2.3 VM Termination Event
VM termination event is also referred to as "powering off" a VM. VM VM termination event is also referred to as "powering off" a VM. VM
termination event leads to its state going to Shutdown. There are two termination event leads to its state going to Shutdown. There are two
possible causes to terminate a VM [I-D.ietf-opsawg-vmm-mib], one is possible causes of VM termination [I-D.ietf-opsawg-vmm-mib]. One is
the normal "power off" of a running VM; the other is that VM has been the normal "power off" of a running VM; the other is that VM has been
migrated to another hypervisor and the VM image on the source migrated to another hypervisor and the VM image on the source
hypervisor has to stop executing and to be shutdown. hypervisor has to stop executing and to be shutdown.
In VM termination, the external NVE connecting to that VM needs to In VM termination, the external NVE connecting to that VM needs to
deprovision the VM, i.e. delete the network parameters associated deprovision the VM, i.e. delete the network parameters associated
with that VM. In other words, the external NVE has to de-associate with that VM. In other words, the external NVE has to de-associate
the VM's TSI. the VM's TSI.
2.4 VM Pause, Suspension and Resumption Events 2.4 VM Pause, Suspension and Resumption Events
skipping to change at page 11, line 5 skipping to change at page 11, line 5
paused or suspended VM in association as the VM can return to Running paused or suspended VM in association as the VM can return to Running
state at any time. state at any time.
3. Hypervisor-to-NVE Control Plane Protocol Functionality 3. Hypervisor-to-NVE Control Plane Protocol Functionality
The following subsections show the illustrative examples of the state The following subsections show the illustrative examples of the state
transitions on external NVE which are relevant to Hypervisor-to-NVE transitions on external NVE which are relevant to Hypervisor-to-NVE
Signaling protocol functionality. It should be noted they are not Signaling protocol functionality. It should be noted they are not
prescriptive text for full state machines. prescriptive text for full state machines.
3.1 VN connect and Disconnect 3.1 VN Connect and Disconnect
In Split-NVE scenario, a protocol is needed between the End In Split-NVE scenario, a protocol is needed between the End Device
Device(e.g. Hypervisor) making use of the external NVE and the (e.g. Hypervisor) making use of the external NVE and the external NVE
external NVE in order to make the external NVE aware of the changing in order to make the external NVE aware of the changing VN membership
VN membership requirements of the Tenant Systems within the End requirements of the Tenant Systems within the End Device.
Device.
A key driver for using a protocol rather than using static A key driver for using a protocol rather than using static
configuration of the external NVE is because the VN connectivity configuration of the external NVE is because the VN connectivity
requirements can change frequently as VMs are brought up, moved and requirements can change frequently as VMs are brought up, moved, and
brought down on various hypervisors throughout the data center or brought down on various hypervisors throughout the data center or
external cloud. external cloud.
+---------------+ Recv VN_connect; +-------------------+ +---------------+ Recv VN_connect; +-------------------+
|VN_Disconnected| return Local_Tag value |VN_Connected | |VN_Disconnected| return Local_Tag value |VN_Connected |
+---------------+ for VN if successful; +-------------------+ +---------------+ for VN if successful; +-------------------+
|VN_ID; |-------------------------->|VN_ID; | |VN_ID; |-------------------------->|VN_ID; |
|VN_State= | |VN_State=connected;| |VN_State= | |VN_State=connected;|
|disconnected; | |Num_TSI_Associated;| |disconnected; | |Num_TSI_Associated;|
| |<----Recv VN_disconnect----|Local_Tag; | | |<----Recv VN_disconnect----|Local_Tag; |
+---------------+ |VN_Context; | +---------------+ |VN_Context; |
+-------------------+ +-------------------+
Figure 5 State Transition Example of a VAP Instance Figure 5. State Transition Example of a VAP Instance
on an External NVE on an External NVE
Figure 5 shows the state transition for a VAP on the external NVE. An Figure 5 shows the state transition for a VAP on the external NVE. An
NVE that supports the hypervisor to NVE control plane protocol should NVE that supports the hypervisor to NVE control plane protocol should
support one instance of the state machine for each active VN. The support one instance of the state machine for each active VN. The
state transition on the external NVE is normally triggered by the state transition on the external NVE is normally triggered by the
hypervisor-facing side events and behaviors. Some of the interleaved hypervisor-facing side events and behaviors. Some of the interleaved
interaction between NVE and NVA will be illustrated for better interaction between NVE and NVA will be illustrated for better
understanding of the whole procedure; while others of them may not be understanding of the whole procedure; while others of them may not be
shown. More detailed information regarding that is available in [I- shown. More detailed information regarding that is available in [I-
D.ietf-nvo3-nve-nva-cp-req]. D.ietf-nvo3-nve-nva-cp-req].
The external NVE must be notified when an End Device requires The external NVE MUST be notified when an End Device requires
connection to a particular VN and when it no longer requires connection to a particular VN and when it no longer requires
connection. In addition, the external NVE must provide a local tag connection. In addition, the external NVE must provide a local tag
value for each connected VN to the End Device to use for exchange of value for each connected VN to the End Device to use for exchange of
packets between the End Device and the external NVE (e.g. a locally packets between the End Device and the external NVE (e.g. a locally
significant 802.1Q tag value). How "local" the significance is significant 802.1Q tag value). How "local" the significance is
depends on whether the Hypervisor has a direct physical connection to depends on whether the Hypervisor has a direct physical connection to
the external NVE (in which case the significance is local to the the external NVE (in which case the significance is local to the
physical link), or whether there is an Ethernet switch (e.g. a blade physical link), or whether there is an Ethernet switch (e.g. a blade
switch) connecting the Hypervisor to the NVE (in which case the switch) connecting the Hypervisor to the NVE (in which case the
significance is local to the intervening switch and all the links significance is local to the intervening switch and all the links
skipping to change at page 12, line 27 skipping to change at page 12, line 26
The Identification of the VN in this protocol could either be through The Identification of the VN in this protocol could either be through
a VN Name or a VN ID. A globally unique VN Name facilitates a VN Name or a VN ID. A globally unique VN Name facilitates
portability of a Tenant's Virtual Data Center. Once an external NVE portability of a Tenant's Virtual Data Center. Once an external NVE
receives a VN connect indication, the NVE needs a way to get a VN receives a VN connect indication, the NVE needs a way to get a VN
Context allocated (or receive the already allocated VN Context) for a Context allocated (or receive the already allocated VN Context) for a
given VN Name or ID (as well as any other information needed to given VN Name or ID (as well as any other information needed to
transmit encapsulated packets). How this is done is the subject of transmit encapsulated packets). How this is done is the subject of
the NVE-to-NVA protocol which are part of work items 1 and 2 in the NVE-to-NVA protocol which are part of work items 1 and 2 in
[RFC7364]. [RFC7364].
VN_connect message can be explicit or implicit. Explicit means the The VN_connect message can be explicit or implicit. Explicit means
hypervisor sending a message explicitly to request for the connection the hypervisor sending a message explicitly to request for the
to a VN. Implicit means the external NVE receives other messages, connection to a VN. Implicit means the external NVE receives other
e.g. very first TSI associate message (see the next subsection) for a messages, e.g. very first TSI associate message (see the next
given VN, to implicitly indicate its interest to connect to a VN. subsection) for a given VN, to implicitly indicate its interest to
connect to a VN.
A VN_disconnect message will indicate that the NVE can release all A VN_disconnect message will indicate that the NVE can release all
the resources for that disconnected VN and transit to VN_disconnected the resources for that disconnected VN and transit to VN_disconnected
state. The local tag assigned for that VN can possibly be reclaimed state. The local tag assigned for that VN can possibly be reclaimed
by other VN. by another VN.
3.2 TSI Associate and Activate 3.2 TSI Associate and Activate
Typically, a TSI is assigned a single MAC address and all frames Typically, a TSI is assigned a single MAC address and all frames
transmitted and received on that TSI use that single MAC address. As transmitted and received on that TSI use that single MAC address. As
mentioned earlier, it is also possible for a Tenant System to mentioned earlier, it is also possible for a Tenant System to
exchange frames using multiple MAC addresses or packets with multiple exchange frames using multiple MAC addresses or packets with multiple
IP addresses. IP addresses.
Particularly in the case of a TS that is forwarding frames or packets Particularly in the case of a TS that is forwarding frames or packets
from other TSs, the external NVE will need to communicate the mapping from other TSs, the external NVE will need to communicate the mapping
between the NVE's IP address (on the underlying network) and ALL the between the NVE's IP address (on the underlying network) and ALL the
addresses the TS is forwarding on behalf of for the corresponding VN addresses the TS is forwarding on behalf of for the corresponding VN
to the NVA. to the NVA.
The NVE has two ways in which it can discover the tenant addresses The NVE has two ways in which it can discover the tenant addresses
for which frames must be forwarded to a given End Device (and for which frames are to be forwarded to a given End Device (and
ultimately to the TS within that End Device). ultimately to the TS within that End Device).
1. It can glean the addresses by inspecting the source addresses in 1. It can glean the addresses by inspecting the source addresses in
packets it receives from the End Device. packets it receives from the End Device.
2. The hypervisor can explicitly signal the address associations of 2. The hypervisor can explicitly signal the address associations of
a TSI to the external NVE. The address association includes all the a TSI to the external NVE. The address association includes all the
MAC and/or IP addresses possibly used as source addresses in a packet MAC and/or IP addresses possibly used as source addresses in a packet
sent from the hypervisor to external NVE. The external NVE may sent from the hypervisor to external NVE. The external NVE may
further use this information to filter the future traffic from the further use this information to filter the future traffic from the
skipping to change at page 14, line 36 skipping to change at page 14, line 36
| +--------------------+ +---------------------+ | | +--------------------+ +---------------------+ |
| /|\ /|\ | | /|\ /|\ |
| | | | | | | |
+---------------------+ +-------------------+ +---------------------+ +-------------------+
add/remove/updt addr; add/remove/updt addr; add/remove/updt addr; add/remove/updt addr;
or update port; or update port; or update port; or update port;
Figure 6 State Transition Example of a TSI Instance Figure 6 State Transition Example of a TSI Instance
on an External NVE on an External NVE
Associated state of a TSI instance on an external NVE indicates all The Associated state of a TSI instance on an external NVE indicates
the addresses for that TSI have already associated with the VAP of all the addresses for that TSI have already associated with the VAP
the external NVE on port p for a given VN but no real traffic to and of the external NVE on port p for a given VN but no real traffic to
from the TSI is expected and allowed to pass through. An NVE has and from the TSI is expected and allowed to pass through. An NVE has
reserved all the necessary resources for that TSI. An external NVE reserved all the necessary resources for that TSI. An external NVE
may report the mappings of its' underlay IP address and the may report the mappings of its' underlay IP address and the
associated TSI addresses to NVA and relevant network nodes may save associated TSI addresses to NVA and relevant network nodes may save
such information to its mapping table but not forwarding table. A NVE such information to its mapping table but not forwarding table. A NVE
may create ACL or filter rules based on the associated TSI addresses may create ACL or filter rules based on the associated TSI addresses
on the attached port p but not enable them yet. Local tag for the VN on the attached port p but not enable them yet. Local tag for the VN
corresponding to the TSI instance should be provisioned on port p to corresponding to the TSI instance should be provisioned on port p to
receive packets. receive packets.
VM migration event(discussed section 2) may cause the hypervisor to VM migration event (discussed section 2) may cause the hypervisor to
send an associate message to the NVE connected to the destination send an associate message to the NVE connected to the destination
hypervisor the VM migrates to. VM creation event may also lead to the hypervisor the VM migrates to. VM creation event may also lead to the
same practice. same practice.
The Activated state of a TSI instance on an external NVE indicates The Activated state of a TSI instance on an external NVE indicates
that all the addresses for that TSI functioning correctly on port p that all the addresses for that TSI are functioning correctly on port
and traffic can be received from and sent to that TSI via the NVE. p and traffic can be received from and sent to that TSI via the NVE.
The mappings of the NVE's underlay IP address and the associated TSI The mappings of the NVE's underlay IP address and the associated TSI
addresses should be put into the forwarding table rather than the addresses should be put into the forwarding table rather than the
mapping table on relevant network nodes. ACL or filter rules based on mapping table on relevant network nodes. ACL or filter rules based on
the associated TSI addresses on the attached port p in NVE are the associated TSI addresses on the attached port p in NVE are
enabled. Local tag for the VN corresponding to the TSI instance MUST enabled. The local tag for the VN corresponding to the TSI instance
be provisioned on port p to receive packets. MUST be provisioned on port p to receive packets.
The Activate message makes the state transit from Init or Associated The Activate message makes the state transit from Init or Associated
to Activated. VM creation, VM migration and VM resumption events to Activated. VM creation, VM migration and VM resumption events
discussed in section 4 may trigger the Activate message to be sent discussed in Section 4 may trigger the Activate message to be sent
from the hypervisor to the external NVE. from the hypervisor to the external NVE.
TSI information may get updated either in Associated or Activated TSI information may get updated either in Associated or Activated
state. The following are considered updates to the TSI information: state. The following are considered updates to the TSI information:
add or remove the associated addresses, update current associated add or remove the associated addresses, update current associated
addresses (for example updating IP for a given MAC), update NVE port addresses (for example updating IP for a given MAC), update NVE port
information based on where the NVE receives messages. Such updates do information based on where the NVE receives messages. Such updates do
not change the state of TSI. When any address associated to a given not change the state of TSI. When any address associated to a given
TSI changes, the NVE should inform the NVA to update the mapping TSI changes, the NVE should inform the NVA to update the mapping
information on NVE's underlying address and the associated TSI information on NVE's underlying address and the associated TSI
skipping to change at page 15, line 50 skipping to change at page 15, line 50
the addresses associated to the TSI are not functioning and no the addresses associated to the TSI are not functioning and no
traffic to and from the TSI is expected and allowed to pass through. traffic to and from the TSI is expected and allowed to pass through.
For example, the NVE needs to inform the NVA to remove the relevant For example, the NVE needs to inform the NVA to remove the relevant
addresses mapping information from forwarding or routing table. ACL addresses mapping information from forwarding or routing table. ACL
or filtering rules regarding the relevant addresses should be or filtering rules regarding the relevant addresses should be
disabled. From Associated or Activated state to the Init state, the disabled. From Associated or Activated state to the Init state, the
NVE will release all the resources relevant to TSI instances. The NVE NVE will release all the resources relevant to TSI instances. The NVE
should also inform the NVA to remove the relevant entries from should also inform the NVA to remove the relevant entries from
mapping table. ACL or filtering rules regarding the relevant mapping table. ACL or filtering rules regarding the relevant
addresses should be removed. Local tag provisioning on the connecting addresses should be removed. Local tag provisioning on the connecting
port on NVE should be cleared. port on NVE SHOULD be cleared.
A VM suspension event(discussed in section 2) may cause the relevant A VM suspension event (discussed in section 2) may cause the relevant
TSI instance(s) on the NVE to transit from Activated to Associated TSI instance(s) on the NVE to transit from Activated to Associated
state. A VM pause event normally does not affect the state of the state. A VM pause event normally does not affect the state of the
relevant TSI instance(s) on the NVE as the VM is expected to run relevant TSI instance(s) on the NVE as the VM is expected to run
again soon. The VM shutdown event will normally cause the relevant again soon. The VM shutdown event will normally cause the relevant
TSI instance(s) on NVE transit to Init state from Activated state. TSI instance(s) on NVE transition to Init state from Activated state.
All resources should be released. All resources should be released.
A VM migration will lead the TSI instance on the source NVE to leave A VM migration will lead the TSI instance on the source NVE to leave
Activated state. When a VM migrates to another hypervisor connecting Activated state. When a VM migrates to another hypervisor connecting
to the same NVE, i.e. source and destination NVE are the same, NVE to the same NVE, i.e. source and destination NVE are the same, NVE
should use TSI_ID and incoming port to differentiate two TSI should use TSI_ID and incoming port to differentiate two TSI
instance. instance.
Although the triggering messages for state transition shown in Figure Although the triggering messages for state transition shown in Figure
6 does not indicate the difference between VM creation/shutdown event 6 does not indicate the difference between VM creation/shutdown event
and VM migration arrival/departure event, the external NVE can make and VM migration arrival/departure event, the external NVE can make
optimizations if it is notified of such information. For example, if optimizations if it is notified of such information. For example, if
the NVE knows the incoming activate message is caused by migration the NVE knows the incoming activate message is caused by migration
rather than VM creation, some mechanisms may be employed or triggered rather than VM creation, some mechanisms may be employed or triggered
to make sure the dynamic configurations or provisionings on the to make sure the dynamic configurations or provisionings on the
destination NVE are the same as those on the source NVE for the destination NVE are the same as those on the source NVE for the
migrated VM. For example IGMP query [RFC2236] can be triggered by the migrated VM. For example an IGMP query [RFC2236] can be triggered by
destination external NVE to the migrated VM on destination hypervisor the destination external NVE to the migrated VM on destination
so that the VM is forced to answer an IGMP report to the multicast hypervisor so that the VM is forced to answer an IGMP report to the
router. Then multicast router can correctly send the multicast multicast router. Then a multicast router can correctly send the
traffic to the new external NVE for those multicast groups the VM had multicast traffic to the new external NVE for those multicast groups
joined before the migration. the VM had joined before the migration.
4. Hypervisor-to-NVE Control Plane Protocol Requirements 4. Hypervisor-to-NVE Control Plane Protocol Requirements
Req-1: The protocol MUST support a bridged network connecting End Req-1: The protocol MUST support a bridged network connecting End
Devices to External NVE. Devices to External NVE.
Req-2: The protocol MUST support multiple End Devices sharing the Req-2: The protocol MUST support multiple End Devices sharing the
same External NVE via the same physical port across a bridged same External NVE via the same physical port across a bridged
network. network.
skipping to change at page 17, line 41 skipping to change at page 17, line 41
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 results from a VM hot migration associate or activate request from it results from a VM hot migration
event. 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.1Qbg] can be the control plane protocol running
between the hypervisor and the external NVE. Appendix A illustrates between the hypervisor and the external NVE. Appendix A illustrates
VDP for reader's information. VDP for the reader's information.
VDP facilitates the automatic discovery and configuration for Edge VDP facilitates the automatic discovery and configuration for Edge
Virtual Bridging (EVB) station and Edge Virtual Bridging (EVB) Virtual Bridging (EVB) station and Edge Virtual Bridging (EVB)
bridge. EVB station is normally an end station running multiple VMs. bridge. EVB station is normally an end station running multiple VMs.
It is conceptually equivalent to hypervisor in this document. And EVB It is conceptually equivalent to hypervisor in this document. And EVB
bridge is conceptually equivalent to the external NVE. bridge is conceptually equivalent to the external NVE.
VDP is able to pre-associate/associate/de-associate a VSI on EVB VDP is able to pre-associate/associate/de-associate a VSI on an EVB
station to a port on the EVB bridge. VSI is approximately the concept station to a port on the EVB bridge. VSI is approximately the concept
of a virtual port a VM connects to the hypervisor in this document of a virtual port a VM connects to the hypervisor in this document
context. The EVB station and the EVB bridge can reach the agreement context. The EVB station and the EVB bridge can reach agreement on
on VLAN ID(s) assigned to a VSI via VDP message exchange. Other VLAN ID(s) assigned to a VSI via VDP message exchange. Other
configuration parameters can be exchanged via VDP as well. VDP is configuration parameters can be exchanged via VDP as well. VDP is
carried over Edge Control Protocol(ECP) [IEEE8021Qbg] which provides carried over the Edge Control Protocol(ECP) [IEEE8021Qbg] which
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 NVO3 context. clarifications in the NVO3 context.
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
| Req | VDP | remarks | | Req | VDP | remarks |
| | supported?| | | | supported?| |
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
| Req-1| | | | Req-1| | |
+------+ |Needs extension. Must be able to send to a | +------+ |Needs extension. Must be able to send to a |
| Req-2| |specific unicast MAC and should be able to send| | Req-2| |specific unicast MAC and should be able to send|
+------+ Partially |to a non-reserved well known multicast address | +------+ Partially |to a non-reserved well known multicast address |
| Req-3| |other than the nearest customer bridge address | | Req-3| |other than the nearest customer bridge address |
skipping to change at page 18, line 49 skipping to change at page 18, line 49
| Req-8| Partially | activate/deactivate |associate/de-associate| | Req-8| Partially | activate/deactivate |associate/de-associate|
| | +------------------------+----------------------| | | +------------------------+----------------------|
| | |Needs extension to allow associate->pre-assoc | | | |Needs extension to allow associate->pre-assoc |
+------+-----------+------------------------+----------------------+ +------+-----------+------------------------+----------------------+
| Req-9| Yes | VDP bridge initiates de-associate | | Req-9| Yes | VDP bridge initiates de-associate |
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
|Req-10| Partially |Needs extension for IPv4/IPv6 address. Add a | |Req-10| Partially |Needs extension for IPv4/IPv6 address. Add a |
| | |new "filter info format" type | | | |new "filter info format" type |
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
|Req-11| No |Out-of-band mechanism is preferred, e.g. MACSec| |Req-11| No |Out-of-band mechanism is preferred, e.g. MACSec|
| | |or 802.1x. | | | |or 802.1X. |
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
|Req-12| Yes |L2 protocol naturally | |Req-12| Yes |L2 protocol naturally |
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
| | |M bit for migrated VM on destination hypervisor| | | |M bit for migrated VM on destination hypervisor|
| | |and S bit for that on source hypervisor. | | | |and S bit for that on source hypervisor. |
|Req-13| Partially |It is indistinguishable when M/S is 0 between | |Req-13| Partially |It is indistinguishable when M/S is 0 between |
| | |no guidance and events not caused by migration | | | |no guidance and events not caused by migration |
| | |where NVE may act differently. Needs new | | | |where NVE may act differently. Needs new |
| | |New bits for migration indication in new | | | |New bits for migration indication in new |
| | |"filter info format" type | | | |"filter info format" type |
skipping to change at page 19, line 44 skipping to change at page 19, line 44
hypervisor-provided parameters or obtain related parameters in a hypervisor-provided parameters or obtain related parameters in a
secure manner. secure manner.
7. IANA Considerations 7. IANA Considerations
No IANA action is required. RFC Editor: please delete this section No IANA action is required. RFC Editor: please delete this section
before publication. before publication.
8. Acknowledgements 8. Acknowledgements
This document was initiated and merged from the drafts draft-kreeger- This document was initiated based on the merger from the drafts
nvo3-hypervisor-nve-cp, draft-gu-nvo3-tes-nve-mechanism and draft- draft-kreeger-nvo3-hypervisor-nve-cp, draft-gu-nvo3-tes-nve-
kompella-nvo3-server2nve. Thanks to all the co-authors and mechanism, and draft-kompella-nvo3-server2nve. Thanks to all the co-
contributing members of those drafts. authors and contributing members of those drafts.
The authors would like to specially thank Jon Hudson for his generous The authors would like to specially thank Lucy Yong and Jon Hudson
help in improving the readability of 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2 Informative References 8.2 Informative References
skipping to change at page 20, line 46 skipping to change at page 20, line 46
[IEEE 802.1Qbg] IEEE, "Media Access Control (MAC) Bridges and Virtual [IEEE 802.1Qbg] IEEE, "Media Access Control (MAC) Bridges and Virtual
Bridged Local Area Networks - Amendment 21: Edge Virtual Bridged Local Area Networks - Amendment 21: Edge Virtual
Bridging", IEEE Std 802.1Qbg, 2012 Bridging", IEEE Std 802.1Qbg, 2012
[8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual Bridged [8021Q] IEEE, "Media Access Control (MAC) Bridges and Virtual Bridged
Local Area Networks", IEEE Std 802.1Q-2011, August, 2011 Local Area Networks", IEEE Std 802.1Q-2011, August, 2011
Appendix A. IEEE 802.1Qbg VDP Illustration (For information only) Appendix A. IEEE 802.1Qbg VDP Illustration (For information only)
VDP has the format shown in Figure A.1. Virtual Station Interface (VSI) VDP (VSI Discovery and Discovery and Configuration Protocol) messages
is an interface to a virtual station that is attached to a downlink port are formatted as a TLV as shown in Figure A.1. Virtual Station Interface
of an internal bridging function in server. VSI's VDP packet will be (VSI) is an interface to a virtual station that is attached to a
handled by an external bridge. VDP is the controlling protocol running downlink port of an internal bridging function in a server. VSI's VDP
between the hypervisor and the external bridge. packet will be handled by an external bridge. VDP is the controlling
protocol running between the hypervisor and the external bridge.
+--------+--------+------+----+----+------+------+------+-----------+ +--------+--------+------+----+----+------+------+------+-----------+
|TLV type|TLV info|Status|VSI |VSI |VSIID | VSIID|Filter|Filter Info| |TLV type|TLV info|Status|VSI |VSI |VSIID | VSIID|Filter|Filter Info|
| 7b |str len | |Type|Type|Format| | Info | | | 7b |str len | |Type|Type|Format| | Info | |
| | 9b | 1oct |ID |Ver | | |format| | | | 9b | 1oct |ID |Ver | | |format| |
| | | |3oct|1oct| 1oct |16oct |1oct | M oct | | | | |3oct|1oct| 1oct |16oct |1oct | M oct |
+--------+--------+------+----+----+------+------+------+-----------+ +--------+--------+------+----+----+------+------+------+-----------+
| | | | | | | | | |
| | |<--VSI type&instance-->|<----Filter------>| | | |<--VSI type&instance-->|<----Filter------>|
| | |<------------VSI attributes-------------->| | | |<------------VSI attributes-------------->|
skipping to change at page 23, line 40 skipping to change at page 23, line 40
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
EMail: liyizhou@huawei.com EMail: liyizhou@huawei.com
Lucy Yong Donald Eastlake
Huawei Technologies, USA Huawei R&D USA
155 Beaver Street
Milford, MA 01757 USA
Email: lucy.yong@huawei.com Phone: +1-508-333-2270
EMail: d3e3e3@gmail.com
Lawrence Kreeger Lawrence Kreeger
Cisco Cisco
Email: kreeger@cisco.com Email: kreeger@cisco.com
Thomas Narten Thomas Narten
IBM IBM
Email: narten@us.ibm.com Email: narten@us.ibm.com
David Black David Black
EMC EMC
Email: david.black@emc.com Email: david.black@emc.com
 End of changes. 63 change blocks. 
139 lines changed or deleted 146 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/