< draft-ietf-nvo3-hpvr2nve-cp-req-10.txt   draft-ietf-nvo3-hpvr2nve-cp-req-11.txt >
NVO3 Working Group Y. Li NVO3 Working Group Y. Li
INTERNET-DRAFT D. Eastlake INTERNET-DRAFT D. Eastlake
Intended Status: Informational Huawei Technologies Intended Status: Informational Huawei Technologies
L. Kreeger L. Kreeger
Arrcus, Inc Arrcus, Inc
T. Narten T. Narten
IBM IBM
D. Black D. Black
EMC EMC
Expires: April 30, 2018 October 27, 2017 Expires: July 12, 2018 January 8, 2018
Split-NVE Control Plane Requirements Split-NVE Control Plane Requirements
draft-ietf-nvo3-hpvr2nve-cp-req-10 draft-ietf-nvo3-hpvr2nve-cp-req-11
Abstract Abstract
In a Split-NVE architecture, the functions of the NVE (Network In a Split-NVE architecture, the functions of the NVE (Network
Virtualization Edge) are split across a server and an external Virtualization Edge) are split across a server and an external
network equipment which is called an external NVE. The server- network equipment which is called an external NVE. The server-
resident control plane functionality resides in control software, resident control plane functionality resides in control software,
which may be part of a hypervisor or container management software; which may be part of a hypervisor or container management software;
for simplicity, this draft refers to the hypervisor as the location for simplicity, this draft refers to the hypervisor as the location
of this software. of this software.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 45 skipping to change at page 4, line 45
to figure 4, 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) are 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 is an NVE-internal protocol and runs further handling. The protocol is an NVE-internal protocol and runs
between tNVE and nNVE logical entities. This protocol is mentioned in between tNVE and nNVE logical entities. This protocol is mentioned in
NVO3 problem statement [RFC7364] and appears as the third work item. NVO3 problem statement [RFC7364] and appears as the 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
protocol(s) need to take between the hypervisor and external NVE protocol(s) need to take between tNVE and nNVE in Split-NVE scenario.
will. Then the high level requirements to be fulfilled are The high level requirements to be fulfilled are stated.
satisfied.
+-- -- -- -- Split-NVE -- -- -- --+ +-- -- -- -- Split-NVE -- -- -- --+
| |
| |
+---------------|-----+ +---------------|-----+
| +------------- ----+| | | +------------- ----+| |
| | +--+ +---\|/--+|| +------ --------------+ | | +--+ +---\|/--+|| +------ --------------+
| | |VM|---+ ||| | \|/ | | | |VM|---+ ||| | \|/ |
| | +--+ | ||| |+--------+ | | | +--+ | ||| |+--------+ |
| | +--+ | tNVE |||----- - - - - - -----|| | | | | +--+ | tNVE |||----- - - - - - -----|| | |
skipping to change at page 5, line 45 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", "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] and
RFC 8174 [RFC8174].
This document uses the same terminology as found in [RFC7365] and [I- This document uses the same terminology as found in [RFC7365]. This
D.ietf-nvo3-nve-nva-cp-req]. This section defines additional section defines additional terminology used by this document.
terminology used by this document.
Split-NVE: a type of NVE that the functionalities of it are split Split-NVE: a type of NVE (Network Virtualization Edge) that the
across an end device supporting virtualization and an external functionalities of it are split across an end device supporting
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 tenant system by device supporting virtualization. It interacts with tenant system by
internal interface in end device. internal interface in end device.
nNVE: the portion of Split-NVE functionalities located on the network nNVE: the portion of Split-NVE functionalities located on the network
device which is directly or indirectly connects to the end device device which is directly or indirectly connects to the end device
holding the corresponding tNVE. nNVE normally performs encapsulation holding the corresponding tNVE. nNVE normally performs encapsulation
and decapsulation to the overlay network. and decapsulation to the overlay network.
External NVE: the physical network device holding nNVE External NVE: the physical network device holding nNVE
Hypervisor/Container: the logical collection of software, firmware Hypervisor: the logical collection of software, firmware and/or
and/or hardware that allows the creation and running of server or hardware that allows the creation and running of server or service
service appliance virtualization. tNVE is located on appliance virtualization. tNVE is located on Hypervisor. It is
Hypervisor/Container. It is loosely used in this document to refer to loosely used in this document to refer to the end device supporting
the end device supporting the virtualization. For simplicity, we also the virtualization. For simplicity, we also use Hypervisor in this
use Hypervisor in this document to represent both hypervisor and document to represent both hypervisor and container.
container.
VN Profile: Meta data associated with a VN that is applied to any Container: Please refer to Hypervisor. This document use hypervisors
attachment point to the VN. That is, VAP properties that are appliaed to represent both hypervisor and container for simplicity.
to all VAPs associated with a given VN and used by an NVE when
ingressing/egressing packets to/from a specific VN. Meta data could VN Profile: Meta data associated with a VN (Virtual Network) that is
include such information as ACLs, QoS settings, etc. The VN Profile applied to any attachment point to the VN. That is, VAP (Virtual
contains parameters that apply to the VN as a whole. Control Access Point) properties that are applied to all VAPs associated with
protocols between the NVE and NVA could use the VN ID or VN Name to a given VN and used by an NVE when ingressing/egressing packets
obtain the VN Profile. to/from a specific VN. Meta data could include such information as
ACLs, QoS settings, etc. The VN Profile contains parameters that
apply to the VN as a whole. Control protocols between the NVE and
NVA (Network Virtualization Authority) could use the VN ID or VN Name
to 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 functions and network policy of the encapsulation / decapsulation functions and network policy
enforcement as well as the VN Overlay protocol overhead. This enforcement as well as the VN Overlay protocol overhead. This
skipping to change at page 7, line 43 skipping to change at page 7, line 46
| +------------+ |tNVE| |------+nNVE | +--- Underlying | +------------+ |tNVE| |------+nNVE | +--- Underlying
| +------------+ | | | Trunk| | | Network | +------------+ | | | Trunk| | | Network
| |Net Service |----| / | | | | | |Net Service |----| / | | | |
| |Instance | | / | | | | | |Instance | | / | | | |
| +------------+ | / | | | | | +------------+ | / | | | |
+--------------------------+ +-----+-------+ +--------------------------+ +-----+-------+
Figure 4 Physical Network Service Appliance with an External NVE Figure 4 Physical Network Service Appliance with an External NVE
Tenant Systems connect to external NVEs via a Tenant System Interface Tenant Systems connect to external NVEs via a Tenant System Interface
(TSI). The TSI logically connects to the external NVE via a Virtual (TSI). The TSI logically connects to the external NVE via a Virtual
Access Point (VAP) [I-D.ietf-nvo3-arch]. The external NVE may provide Access Point (VAP) [RFC8014]. The external NVE may provide Layer 2 or
Layer 2 or Layer 3 forwarding. In the Split-NVE architecture, the Layer 3 forwarding. In the Split-NVE architecture, the external NVE
external NVE may be able to reach multiple MAC and IP addresses via a may be able to reach multiple MAC and IP addresses via a TSI. For
TSI. For example, Tenant Systems that are providing network services example, Tenant Systems that are providing network services (such as
(such as transparent firewall, load balancer, or VPN gateway) are transparent firewall, load balancer, or VPN gateway) are likely to
likely to have a complex address hierarchy. This implies that if a have a complex address hierarchy. This implies that if a given TSI
given TSI disassociates from one VN, all the MAC and/or IP addresses disassociates from one VN, all the MAC and/or IP addresses are also
are also disassociated. There is no need to signal the deletion of disassociated. There is no need to signal the deletion of every MAC
every MAC or IP when the TSI is brought down or deleted. In the or IP when the TSI is brought down or deleted. In the majority of
majority of cases, a VM will be acting as a simple host that will cases, a VM will be acting as a simple host that will have a single
have a single TSI and single MAC and IP visible to the external NVE. TSI and single MAC and IP visible to the external NVE.
Figures 2 through 4 show the use of VLANs to separate traffic for Figures 2 through 4 show the use of VLANs to separate traffic for
multiple VNs between the tNVE and nNVE; VLANs are not strictly multiple VNs between the tNVE and nNVE; VLANs are not strictly
necessary if only one VN is involved, but multiple VNs are expected necessary if only one VN is involved, but multiple VNs are expected
in most cases, 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 [RFC7666] shows the state transition of a VM. Some of the
VM. Some of the VM states are of interest to the external NVE. This VM states are of interest to the external NVE. This section
section illustrates the relevant phases and events in the VM illustrates the relevant phases and events in the VM lifecycle. Note
lifecycle. Note that the following subsections do not give an that the following subsections do not give an exhaustive traversal of
exhaustive traversal of VM lifecycle state. They are intended as the VM lifecycle state. They are intended as the illustrative examples
illustrative examples which are relevant to Split-NVE architecture, which are relevant to Split-NVE architecture, not as prescriptive
not as prescriptive text; the goal is to capture sufficient detail to text; the goal is to capture sufficient detail to set a context for
set a context for the signaling protocol functionality and the signaling protocol functionality and requirements described in
requirements described in the following sections. the following sections.
2.1 VM Creation Event 2.1 VM Creation Event
The VM creation event causes the VM state transition from Preparing The VM creation event causes the VM state transition from Preparing
to Shutdown and then to Running [I-D.ietf-opsawg-vmm-mib]. The end to Shutdown and then to Running [RFC7666]. The end device allocates
device allocates and initializes local virtual resources like storage and initializes local virtual resources like storage in the VM
in the VM Preparing state. In the Shutdown state, the VM has Preparing state. In the Shutdown state, the VM has everything ready
everything ready except that CPU execution is not scheduled by the except that CPU execution is not scheduled by the hypervisor and VM's
hypervisor and VM's memory is not resident in the hypervisor. From memory is not resident in the hypervisor. From the Shutdown state to
the Shutdown state to the Running state, normally it requires human the Running state, normally it requires human action or a system
action or a system triggered event. Running state indicates the VM is triggered event. Running state indicates the VM is in the normal
in the normal execution state. As part of transitioning the VM to the execution state. As part of transitioning the VM to the Running
Running state, the hypervisor must also provision network state, the hypervisor must also provision network connectivity for
connectivity for the VM's TSI(s) so that Ethernet frames can be sent the VM's TSI(s) so that Ethernet frames can be sent and received
and received correctly. No ongoing migration, suspension or shutdown correctly. No ongoing migration, suspension or shutdown is in
is in process. 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
skipping to change at page 9, line 37 skipping to change at page 9, line 41
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 shutting down VM execution on one server and restarting consists of shutting down VM execution on one server and restarting
it on another. For simplicity, the following abstract summary about it on another. For simplicity, the following abstract summary about
live 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 [RFC7666]. VM
opsawg-vmm-mib]. VM state on destination hypervisor 2 transits from state on destination hypervisor 2 transits from Shutdown to Migrating
Shutdown to Migrating and then Running. 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 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 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.
skipping to change at page 10, line 17 skipping to change at page 10, line 20
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 of VM termination [I-D.ietf-opsawg-vmm-mib]. One is possible causes of VM termination [RFC7666]. One is the normal "power
the normal "power off" of a running VM; the other is that VM has been off" of a running VM; the other is that VM has been migrated to
migrated to another hypervisor and the VM image on the source another hypervisor and the VM image on the source hypervisor has to
hypervisor has to stop executing and to be shutdown. 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
The VM pause event leads to the VM transiting from Running state to The VM pause event leads to the VM transiting from Running state to
Paused state. The Paused state indicates that the VM is resident in Paused state. The Paused state indicates that the VM is resident in
memory but no longer scheduled to execute by the hypervisor [I- memory but no longer scheduled to execute by the hypervisor
D.ietf-opsawg-vmm-mib]. The VM can be easily re-activated from Paused [RFC7666]. The VM can be easily re-activated from Paused state to
state to Running state. Running state.
The VM suspension event leads to the VM transiting from Running state The VM suspension event leads to the VM transiting from Running state
to Suspended state. The VM resumption event leads to the VM to Suspended state. The VM resumption event leads to the VM
transiting state from Suspended state to Running state. Suspended transiting state from Suspended state to Running state. Suspended
state means the memory and CPU execution state of the virtual machine state means the memory and CPU execution state of the virtual machine
are saved to persistent store. During this state, the virtual are saved to persistent store. During this state, the virtual
machine is not scheduled to execute by the hypervisor [I-D.ietf- machine is not scheduled to execute by the hypervisor [RFC7666].
opsawg-vmm-mib].
In the Split-NVE architecture, the external NVE should keep any In the Split-NVE architecture, the external NVE should not
paused or suspended VM in association as the VM can return to Running disassociate the paused or suspended VM as the VM can return to
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 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
skipping to change at page 11, line 38 skipping to change at page 11, line 41
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.
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
skipping to change at page 17, line 14 skipping to change at page 17, line 14
Req-6: The protocol MUST allow an External NVE initiating a request Req-6: The protocol MUST allow an External NVE initiating a request
to its connected End Devices to be disconnected to a given VN. to its connected End Devices to be disconnected to a given VN.
Req-7: When a TS attaches to a VN, the protocol MUST allow for an End Req-7: When a TS attaches to a VN, the protocol MUST allow for an End
Device and its external NVE to negotiate one or more locally- Device and its external NVE to negotiate one or more locally-
significant tag(s) for carrying traffic associated with a specific VN significant tag(s) for carrying traffic associated with a specific VN
(e.g., 802.1Q tags). (e.g., 802.1Q tags).
Req-8: The protocol MUST allow an End Device initiating a request to Req-8: The protocol MUST allow an End Device initiating a request to
associate/disassociate and/or activate/deactive address(es) of a TSI associate/disassociate and/or activate/deactive some or all
instance to a VN on an NVE port. address(es) of a TSI instance to a VN on an NVE port.
Req-9: The protocol MUST allow the External NVE initiating a request Req-9: The protocol MUST allow the External NVE initiating a request
to disassociate and/or deactivate address(es) of a TSI instance to a to disassociate and/or deactivate some or all address(es) of a TSI
VN on an NVE port. instance to a VN on an NVE port.
Req-10: The protocol MUST allow an End Device initiating a request to Req-10: The protocol MUST allow an End Device initiating a request to
add, remove or update address(es) associated with a TSI instance on add, remove or update address(es) associated with a TSI instance on
the external NVE. Addresses can be expressed in different formats, the external NVE. Addresses can be expressed in different formats,
for example, MAC, IP or pair of IP and MAC. for example, MAC, IP or pair of IP and MAC.
Req-11: The protocol MUST allow the External NVE to authenticate the Req-11: The protocol MUST allow the External NVE to authenticate the
End Device connected. End Device connected.
Req-12: The protocol MUST be able to run over L2 links between the Req-12: The protocol MUST be able to run over L2 links between the
skipping to change at page 18, line 16 skipping to change at page 18, line 16
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 the Edge Control Protocol(ECP) [IEEE8021Qbg] which carried over the Edge Control Protocol(ECP) [IEEE8021Qbg] which
provides a reliable transportation over a layer 2 network. provides a reliable transportation over a layer 2 network.
VDP protocol needs some extensions to fulfill the requirements listed VDP protocol needs some extensions to fulfill the requirements listed
in this document. Table 1 shows the needed extensions and/or in this document. Table 1 shows the needed extensions and/or
clarifications in the NVO3 context. clarifications in the NVO3 context.
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
| Req | VDP | remarks | | Req | Supported | remarks |
| | supported?| | | | by VDP? | |
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
| 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 |
+------+ | | +------+ | |
| Req-4| | | | Req-4| | |
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
| Req-5| Yes |VN is indicated by GroupID | | Req-5| Yes |VN is indicated by GroupID |
skipping to change at page 20, line 13 skipping to change at page 20, line 13
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.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words ", BCP 14, RFC 8174, May 2017.
8.2 Informative References 8.2 Informative References
[RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., and [RFC7364] Narten, T., Gray, E., Black, D., Fang, L., Kreeger, L., and
M. Napierala, "Problem Statement: Overlays for Network M. Napierala, "Problem Statement: Overlays for Network
Virtualization", October 2014. Virtualization", October 2014.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for DC Network Virtualization", Rekhter, "Framework for DC Network Virtualization",
October 2014. October 2014.
[I-D.ietf-nvo3-nve-nva-cp-req] Kreeger, L., Dutt, D., Narten, T., and [RFC8014] Black, D., Hudson, J., Kreeger, L., Lasserre, M., Narten,
D. Black, "Network Virtualization NVE to NVA Control T., "An Architecture for Data-Center Network
Protocol Requirements", draft-ietf-nvo3-nve-nva-cp-req-01 Virtualization over Layer 3 (NVO3)", December 2016.
(work in progress), October 2013.
[I-D.ietf-nvo3-arch] Black, D., Narten, T., et al, "An Architecture
for Overlay Networks (NVO3)", draft-narten-nvo3-arch, work
in progress.
[I-D.ietf-opsawg-vmm-mib] Asai H., MacFaden M., Schoenwaelder J., [RFC7666] Asai H., MacFaden M., Schoenwaelder J., Shima K., Tsou T.,
Shima K., Tsou T., "Management Information Base for "Management Information Base for Virtual Machines
Virtual Machines Controlled by a Hypervisor", draft-ietf- Controlled by a Hypervisor", October 2015.
opsawg-vmm-mib-00 (work in progress), February 2014.
[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)
 End of changes. 24 change blocks. 
95 lines changed or deleted 92 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/