< draft-ietf-nvo3-hpvr2nve-cp-req-15.txt   draft-ietf-nvo3-hpvr2nve-cp-req-16.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
Dell EMC Dell EMC
Expires: August 13, 2018 February 9, 2018 Expires: August 29, 2018 February 25, 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-15 draft-ietf-nvo3-hpvr2nve-cp-req-16
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 2, line 38 skipping to change at page 2, line 38
Table of Contents Table of Contents
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 . . . . 11
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 . . . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
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 . . . . . . . . . . . . . . . . . . 21
Appendix A. IEEE 802.1Q VDP Illustration (For information only) . 21 Appendix A. IEEE 802.1Q VDP Illustration (For information 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 (terminal-side NVE) and the
external NVE is called the nNVE in this document. Overlay portion located on the external NVE is called the nNVE (network-side
encapsulation/decapsulation functions are normally off-loaded to the NVE) in this document. Overlay encapsulation/decapsulation functions
nNVE on the external NVE. 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 (Virtual separate device from the "hypervisor" that contains a VM (Virtual
Machine) connected to a VN (Virutal Network). In this context, the Machine) connected to a VN (Virutal Network). In this context, the
term "hypervisor" is meant to cover any device type where part of the term "hypervisor" is meant to cover any device type where part of the
NVE functionality is off-loaded in this fashion, e.g.,a Network NVE functionality is off-loaded in this fashion, e.g.,a Network
Service Appliance or Linux Container. Service Appliance or Linux Container.
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|---+ ||| | \|/ | | | |V |TSI +-------+ || +------|-------------+
| | +--+ | ||| |+--------+ | | | |M |-----+ | || | \|/ |
| | +--+ | tNVE |||---------------------|| | | | | +--+ | | || |+--------+ |
| | |VM|---+ ||| || nNVE | | | | +--+ | tNVE | ||-------------------|| | |
| | +--+ +--------+|| || | | | | |V |TSI | | || || nNVE | |
| | || |+--------+ | | | |M |-----| | || || | |
| +--Hypervisor------+| +---------------------+ | | +--+ +-------+ || |+--------+ |
+---------------------+ | | || +--------------------+
| +-----Hypervisor-----+|
+-----------------------+
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
skipping to change at page 5, line 44 skipping to change at page 5, line 45
Section 2 describes VM states and state transitioning in the VM's 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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119] and "OPTIONAL" in this document are to be interpreted as described in BCP
RFC 8174 [RFC8174]. 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
This document uses the same terminology as found in [RFC7365]. This This document uses the same terminology as found in [RFC7365]. This
section defines additional terminology used by this document. section defines additional terminology used by this document.
Split-NVE: a type of NVE (Network Virtualization Edge) where the Split-NVE: a type of NVE (Network Virtualization Edge) where the
functionalities are split across an end device supporting functionalities are split across an end device supporting
virtualization and an external network device. virtualization and an external network device.
tNVE: the portion of Split-NVE functionalities located on the end tNVE: the portion of Split-NVE functionalities located on the end
device supporting virtualization. It interacts with a tenant system device supporting virtualization. It interacts with a tenant system
skipping to change at page 10, line 9 skipping to change at page 10, line 12
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 VLAN ID 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 until all the network provisioning and should not go to Running state until all the network provisioning and
binding has been done. binding has been done.
The migrating VM should not be in Running state at the same time on The states of VM on the source and destination hypervisors both are
the source hypervisor and destination hypervisor during migration. Migrating during transfer of migration execution. The migrating VM
The VM on the source hypervisor does not transition into Shutdown should not be in Running state at the same time on the source
state until the VM successfully enters the Running state on the hypervisor and destination hypervisor during migration. The VM on the
destination hypervisor. It is possible that the VM on the source source hypervisor does not transition into Shutdown state until the
hypervisor stays in Migrating state for a while after the VM on the VM successfully enters the Running state on the destination
destination hypervisor enters Running state. hypervisor. It is possible that the VM on the source hypervisor stays
in Migrating state for a while after the VM on the destination
hypervisor enters Running state.
2.3 VM Termination Event 2.3 VM Termination Event
A VM termination event is also referred to as "powering off" a VM. A A VM termination event is also referred to as "powering off" a VM. A
VM termination event leads to its state becoming Shutdown. There are VM termination event leads to its state becoming Shutdown. There are
two possible causes of VM termination [RFC7666]. One is the normal two possible causes of VM termination [RFC7666]. One is the normal
"power off" of a running VM; the other is that the VM has been "power off" of a running VM; the other is that the 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 be shutdown. hypervisor has to stop executing and be shutdown.
skipping to change at page 10, line 46 skipping to change at page 10, line 51
[RFC7666]. The VM can be easily re-activated from Paused state to [RFC7666]. The VM can be easily re-activated from Paused state to
Running state. Running state.
A VM suspension event leads to the VM transiting from Running state A VM suspension event leads to the VM transiting from Running state
to Suspended state. A VM resumption event leads to the VM transiting to Suspended state. A VM resumption event leads to the VM transiting
state from Suspended state to Running state. Suspended state means state from Suspended state to Running state. Suspended state means
the memory and CPU execution state of the virtual machine are saved the memory and CPU execution state of the virtual machine are saved
to persistent store. During this state, the virtual machine is not to persistent store. During this state, the virtual machine is not
scheduled to execute by the hypervisor [RFC7666]. scheduled to execute by the hypervisor [RFC7666].
In the Split-NVE architecture, the external NVE SHOULD NOT In the Split-NVE architecture, the external NVE should not
disassociate the paused or suspended VM as the VM can return to disassociate the paused or suspended VM as the VM can return to
Running state at any time. Running state at any time.
3. Hypervisor-to-NVE Control Plane Protocol Functionality 3. Hypervisor-to-NVE Control Plane Protocol Functionality
The following subsections show illustrative examples of the state The following subsections show illustrative examples of the state
transitions of an external NVE which are relevant to Hypervisor-to- transitions of an external NVE which are relevant to Hypervisor-to-
NVE Signaling protocol functionality. It should be noted this is not NVE Signaling protocol functionality. It should be noted this is not
prescriptive text for the full state machine. prescriptive text for the full state machine.
3.1 VN Connect and Disconnect 3.1 VN Connect and Disconnect
In the Split-NVE scenario, a protocol is needed between the End In the Split-NVE scenario, a protocol is needed between the End
Device (e.g. Hypervisor) and the external NVE it is using in order to Device (e.g. Hypervisor) and the external NVE it is using in order to
make the external NVE aware of the changing VN membership make the external NVE aware of the changing VN membership
skipping to change at page 11, line 43 skipping to change at page 12, line 5
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 to better explain interaction between NVE and NVA will be illustrated to better explain
the whole procedure; while others of them may not be shown. the whole procedure; while others of them may not be shown.
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. Connection clean up for the failed devices should be
value for each connected VN to the End Device to use for exchanging employed which is out of the scope of the protocol specified in this
packets between the End Device and the external NVE (e.g. a locally document.
In addition, the external NVE should provide a local tag value for
each connected VN to the End Device to use for exchanging packets
between the End Device and the external NVE (e.g. a locally
significant [IEEE 802.1Q] tag value). How "local" the significance is significant [IEEE 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
connected to it). connected to it).
These VLAN tags are used to differentiate between different VNs as These VLAN tags are used to differentiate between different VNs as
packets cross the shared access network to the external NVE. When the packets cross the shared access network to the external NVE. When the
skipping to change at page 12, line 27 skipping to change at page 12, line 37
corresponding remote NVE across the underlying IP network. corresponding remote NVE across the underlying IP network.
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]. The external NVE needs to synchronize the mapping
information of the local tag and VN Name or VN ID with NVA.
The VN_connect message can be explicit or implicit. Explicit means The VN_connect message can be explicit or implicit. Explicit means
the hypervisor sends a request message explicitly for the connection the hypervisor sends a request message explicitly for the connection
to a VN. Implicit means the external NVE receives other messages, to a VN. Implicit means the external NVE receives other messages,
e.g. very first TSI associate message (see the next subsection) for a e.g. very first TSI associate message (see the next subsection) for a
given VN, that implicitly indicate its interest in connecting to a given VN, that implicitly indicate its interest in connecting to a
VN. VN.
A VN_disconnect message indicates that the NVE can release all the A VN_disconnect message indicates that the NVE can release all the
resources for that disconnected VN and transit to VN_disconnected resources for that disconnected VN and transit to VN_disconnected
skipping to change at page 15, line 14 skipping to change at page 15, line 14
the same practice. the 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 are functioning correctly on a that all the addresses for that TSI are functioning correctly on a
given port e.g. port p and traffic can be received from and sent to given port e.g. port p and traffic can be received from and sent to
that TSI via the NVE. The mappings of the NVE's underlay IP address that TSI via the NVE. The mappings of the NVE's underlay IP address
and the associated TSI addresses should be put into the forwarding and the associated TSI addresses should be put into the forwarding
table rather than the mapping table on relevant network nodes. ACL or table rather than the mapping table on relevant network nodes. ACL or
filter rules based on the associated TSI addresses on the attached filter rules based on the associated TSI addresses on the attached
port p in the NVE are enabled. The local tag for the VN corresponding port p in the NVE are enabled. The local tag for the VN corresponding
to the TSI instance MUST be provisioned on port p to receive packets. to the TSI instance 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 sending the Activate message from discussed in Section 4 may trigger sending the Activate message from
the hypervisor to the external NVE. the hypervisor to the external NVE.
TSI information may get updated in either the Associated or Activated TSI information may get updated in either the 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 the current associated add or remove the associated addresses, update the current associated
addresses (for example updating IP for a given MAC), and update the addresses (for example updating IP for a given MAC), and update the
skipping to change at page 16, line 5 skipping to change at page 16, line 5
TSI is expected or allowed to pass through. For example, the NVE TSI is expected or allowed to pass through. For example, the NVE
needs to tell the NVA to remove the relevant addresses mapping needs to tell the NVA to remove the relevant addresses mapping
information from forwarding and routing tables. ACL and filtering information from forwarding and routing tables. ACL and filtering
rules regarding the relevant addresses should be disabled. rules regarding the relevant addresses should be disabled.
From Associated or Activated state to the Init state, the NVE From Associated or Activated state to the Init state, the NVE
releases all the resources relevant to TSI instances. The NVE should releases all the resources relevant to TSI instances. The NVE should
also inform the NVA to remove the relevant entries from mapping also inform the NVA to remove the relevant entries from mapping
table. ACL or filtering rules regarding the relevant addresses should table. ACL or filtering rules regarding the relevant addresses should
be removed. Local tag provisioning on the connecting port on NVE be removed. Local tag provisioning on the connecting port on NVE
SHOULD be cleared. 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. state.
A VM pause event normally does not affect the state of the relevant 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 again soon. TSI instance(s) on the NVE as the VM is expected to run again soon.
A VM shutdown event will normally cause the relevant TSI instance(s) A VM shutdown event will normally cause the relevant TSI instance(s)
on the NVE to transition to Init state from Activated state. All on the NVE to transition to Init state from Activated state. All
skipping to change at page 19, line 31 skipping to change at page 19, line 31
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
Table 1 Compare VDP with the requirements Table 1 Compare VDP with the requirements
Simply adding the ability to carry layer 3 addresses, VDP can serve Simply adding the ability to carry layer 3 addresses, VDP can serve
the Hypervisor-to-NVE control plane functions pretty well. Other the Hypervisor-to-NVE control plane functions pretty well. Other
extensions are the improvement of the protocol capabilities for extensions are the improvement of the protocol capabilities for
better fit in an NVO3 network. better fit in an NVO3 network.
6. Security Considerations 6. Security Considerations
NVEs must ensure that only properly authorized Tenant Systems are External NVEs must ensure that only properly authorized Tenant
allowed to join and become a part of any particular Virtual Network. Systems are allowed to join and become a part of any particular
In addition, NVEs will need appropriate mechanisms to ensure that any Virtual Network. In some cases, tNVE may want to connect to the
hypervisor wishing to use the services of an NVE are properly authenticated nNVE for provisioning purpose. Then a mutual
authorized to do so. One design point is whether the hypervisor authentication between tNVE tand nNVE is required. If a secure
should supply the NVE with necessary information (e.g., VM addresses, channel is required between tNVE and nNVE to carry encrypted split-
VN information, or other parameters) that the NVE uses directly, or NVE control plane protocol payload, the existing mechanisms like
whether the hypervisor should only supply a VN ID and an identifier MACsec [IEEE 802.1AE] can be used.
for the associated VM (e.g., its MAC address), with the NVE using
that information to obtain the information needed to validate the In addition, external NVEs will need appropriate mechanisms to ensure
hypervisor-provided parameters or obtain related parameters in a that any hypervisor wishing to use the services of an NVE is properly
secure manner. authorized to do so. One design point is whether the hypervisor
should supply the external NVE with necessary information (e.g., VM
addresses, VN information, or other parameters) that the external NVE
uses directly, or whether the hypervisor should only supply a VN ID
and an identifier for the associated VM (e.g., its MAC address), with
the external NVE using that information to obtain the information
needed to validate the hypervisor-provided parameters or obtain
related parameters in a secure manner. The former approach can be
used in a trusted environment so that the external NVE can directly
use all the information retrieved from the hypervisor for local
configuration. It saves the effort on the external NVE side from
information retrieval and/or validation. The latter approach gives
more reliable information as the external NVE needs to retrieve them
from some management system database. Especially some network related
parameters like VLAN IDs can be passed back to hypervisor to be used
as a more authoritative provisioning. However in certain cases, it is
difficult or inefficient for an external NVE to have access or query
on some information to those management systems. Then the external
NVE has to obtain those information from hypervisor.
7. IANA Considerations 7. IANA Considerations
No IANA action is required. RFC Editor: please delete this section No IANA action is required.
before publication.
8. Acknowledgements 8. Acknowledgements
This document was initiated based on the merger from the drafts
draft-kreeger-nvo3-hypervisor-nve-cp, draft-gu-nvo3-tes-nve- This document was initiated based on the merger of the drafts draft-
mechanism, and draft-kompella-nvo3-server2nve. Thanks to all the co- kreeger-nvo3-hypervisor-nve-cp, draft-gu-nvo3-tes-nve-mechanism, and
authors and contributing members of those drafts. draft-kompella-nvo3-server2nve. Thanks to all the co-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 [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.
skipping to change at page 21, line 5 skipping to change at page 21, line 22
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.
[IEEE 802.1AE] IEEE, "MAC Security (MACsec)", IEEE Std 802.1AE-2006,
August 2006.
Appendix A. IEEE 802.1Q VDP Illustration (For information only) Appendix A. IEEE 802.1Q VDP Illustration (For information only)
The VDP (VSI Discovery and Discovery and Configuration Protocol, The VDP (VSI Discovery and Discovery and Configuration Protocol,
clause 41 of [IEEE 802.1Q]) can be considered as a controlling clause 41 of [IEEE 802.1Q]) can be considered as a controlling
protocol running between the hypervisor and the external bridge. VDP protocol running between the hypervisor and the external bridge. VDP
association TLV structure are formatted as shown in Figure A.1. association TLV structure 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 |
 End of changes. 21 change blocks. 
62 lines changed or deleted 93 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/