< draft-ietf-nvo3-hpvr2nve-cp-req-01.txt   draft-ietf-nvo3-hpvr2nve-cp-req-02.txt >
NVO3 Working Group Yizhou Li NVO3 Working Group Yizhou Li
INTERNET-DRAFT Lucy Yong INTERNET-DRAFT Lucy Yong
Intended Status: Informational Huawei Technologies Intended Status: Informational Huawei Technologies
Lawrence Kreeger Lawrence Kreeger
Cisco Cisco
Thomas Narten Thomas Narten
IBM IBM
David Black David Black
EMC EMC
Expires: May 22, 2015 November 18, 2014 Expires: August 13, 2015 February 9, 2015
Hypervisor to NVE Control Plane Requirements Hypervisor to NVE Control Plane Requirements
draft-ietf-nvo3-hpvr2nve-cp-req-01 draft-ietf-nvo3-hpvr2nve-cp-req-02
Abstract Abstract
In a Split-NVE architructure, the functions of the NVE are split In a Split-NVE architructure, the functions of the NVE are split
across the hypervisor/container on a server and an external network across the hypervisor/container on a server and an external network
equipment which is called an external NVE. A control plane equipment which is called an external NVE. A control plane
protocol(s) between a hypervisor and its associated external NVE(s) protocol(s) between a hypervisor and its associated external NVE(s)
is used for the hypervisor to distribute its virtual machine is used for the hypervisor to distribute its virtual machine
networking state to the external NVE(s) for further handling. This networking state to the external NVE(s) for further handling. This
document illustrates the functionality required by this type of document illustrates the functionality required by this type of
skipping to change at page 2, line 37 skipping to change at page 2, line 37
2. VM Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. VM Lifecycle . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1 VM Creation Event . . . . . . . . . . . . . . . . . . . . . 7 2.1 VM Creation Event . . . . . . . . . . . . . . . . . . . . . 7
2.2 VM Live Migration Event . . . . . . . . . . . . . . . . . . 8 2.2 VM Live Migration Event . . . . . . . . . . . . . . . . . . 8
2.3 VM Termination Event . . . . . . . . . . . . . . . . . . . . 9 2.3 VM Termination Event . . . . . . . . . . . . . . . . . . . . 9
2.4 VM Pause, Suspension and Resumption Events . . . . . . . . . 9 2.4 VM Pause, Suspension and Resumption Events . . . . . . . . . 9
3. Hypervisor-to-NVE Control Plane Protocol Functionality . . . . 9 3. Hypervisor-to-NVE Control Plane Protocol Functionality . . . . 9
3.1 VN connect and Disconnect . . . . . . . . . . . . . . . . . 10 3.1 VN connect and Disconnect . . . . . . . . . . . . . . . . . 10
3.2 TSI Associate and Activate . . . . . . . . . . . . . . . . . 11 3.2 TSI Associate and Activate . . . . . . . . . . . . . . . . . 11
3.3 TSI Disassociate and Deactivate . . . . . . . . . . . . . . 14 3.3 TSI Disassociate and Deactivate . . . . . . . . . . . . . . 14
4. Hypervisor-to-NVE Control Plane Protocol Requirements . . . . . 15 4. Hypervisor-to-NVE Control Plane Protocol Requirements . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 16 5. VDP Applicability and Enhancement Needs . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 18
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
8.1 Normative References . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2 Informative References . . . . . . . . . . . . . . . . . . 17 8.1 Normative References . . . . . . . . . . . . . . . . . . . 19
8.2 Informative References . . . . . . . . . . . . . . . . . . 19
Appendix A. IEEE 802.1Qbg VDP Illustration (For information Appendix A. IEEE 802.1Qbg VDP Illustration (For information
only) . . . . . . . . . . . . . . . . . . . . . . . . . . 18 only) . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
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 is split across an end device supporting virtualization and
an external network device which is called an external NVE. The an external network device which is called an external NVE. The
portion of the NVE functionality located on the hypervisor/container portion of the NVE functionality located on the hypervisor/container
is called the tNVE and the portion located on the external NVE is is called the tNVE and the portion located on the external NVE is
called the nNVE in this document. Overlay encapsulation/decapsulation called the nNVE in this document. Overlay encapsulation/decapsulation
functions are normally off-loaded to the nNVE on the external NVE. functions are normally off-loaded to the nNVE on the external NVE.
skipping to change at page 16, line 36 skipping to change at page 16, line 36
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
End Device and its External NVE. End Device and its External NVE.
Req-13: The protocol SHOULD support the End Device indicating if an Req-13: The protocol SHOULD support the End Device indicating if an
associate or activate request from it results from a VM hot migration associate or activate request from it results from a VM hot migration
event. event.
VDP [IEEE 802.1Qbg] is a candidate protocol running on layer 2. 5. VDP Applicability and Enhancement Needs
Appendix A illustrates VDP for reader's information. It requires
extensions to fulfill the requirements in this document.
5. Security Considerations Virtual Station Interface (VSI) Discovery and Configuration Protocol
(VDP) [IEEE 802.1Qbg] can be the control plane protocol running
between the hypervisor and the external NVE. Appendix A illustrates
VDP for reader's information.
VDP facilitates the automatic discovery and configuration for Edge
Virtual Bridging (EVB) station and Edge Virtual Bridging (EVB)
bridge. EVB station is normally an end station running multiple VMs.
It is conceptually equivalent to hypervisor in this document. And EVB
bridge is conceptually equivalent to the external NVE.
VDP is able to pre-associate/associate/de-associate a VSI on EVB
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
context. The EVB station and the EVB bridge can reach the agreement
on VLAN ID(s) assigned to a VSI via VDP message exchange. Other
configuration parameters can be exchanged via VDP as well. VDP is
carried over Edge Control Protocol(ECP) [IEEE8021Qbg] which provides
a reliable transportation over a layer 2 network.
VDP protocol needs some extensions to fulfill the requirements listed
in this document. Table 1 shows the needed extensions and/or
clarifications in NVO3 context.
+------+-----------+-----------------------------------------------+
| Req | VDP | remarks |
| | supported?| |
+------+-----------+-----------------------------------------------+
| Req-1| |Needs extension. Dest MAC can be a specific |
+------+ Partially |unicast MAC besides Nearest Customer Bridge |
| Req-2| |group MAC |
+------+-----------+-----------------------------------------------+
| Req-3| |Needs clarification and extension for link |
| | |aggregation support. |
+------+ Partially |For req-4, (pre-)associate status needs to be |
| Req-4| |synchronized on all NVE ports. |
+------+-----------+-----------------------------------------------+
| Req-5| Yes |VN is indicated by GroupID |
+------+-----------+-----------------------------------------------+
| Req-6| Yes |Bridge sends De-Associate |
+------+-----------+------------------------+----------------------+
| Req-7| Yes |VID==NULL in request and bridge returns the |
| | |assigned value in response |
+------+-----------+------------------------+----------------------+
| | | requirements | VDP equivalence |
| | +------------------------+----------------------+
| | | associate/disassociate|pre-asso/de-associate |
| Req-8| Partially | activate/deactivate |associate/de-associate|
| | +------------------------+----------------------|
| | |Needs extension to allow associate->pre-assoc |
+------+-----------+------------------------+----------------------+
| Req-9| Yes | VDP bridge initiates de-associate |
+------+-----------+-----------------------------------------------+
|Req-10| Partially |Needs extension for IPv4/IPv6 address |
+------+-----------+-----------------------------------------------+
|Req-11| No |Needs extension for authentication |
+------+-----------+-----------------------------------------------+
|Req-12| Yes |L2 protocol naturally |
+------+-----------+-----------------------------------------------+
| | |M bit for migrated VM on destination hypervisor|
| | |and S bit for that on source hypervisor. |
|Req-13| Partially |It is indistinguishable when M/S is 0 between |
| | |no guidance and events not caused by migration |
| | |where NVE may act differently. Needs extension |
| | |to clearly define them. |
+------+-----------+-----------------------------------------------+
Table 1 Compare VDP with the requirements
Simply adding the ability to carry layer 3 addresses, VDP can serve
the Hypervisor-to-NVE control plane functions pretty well. Other
extensions are the improvement of the protocol capabilities for
better fit in NVO3 network.
6. Security Considerations
NVEs must ensure that only properly authorized Tenant Systems are NVEs must ensure that only properly authorized Tenant Systems are
allowed to join and become a part of any specific Virtual Network. In allowed to join and become a part of any specific Virtual Network. In
addition, NVEs will need appropriate mechanisms to ensure that any addition, NVEs will need appropriate mechanisms to ensure that any
hypervisor wishing to use the services of an NVE are properly hypervisor wishing to use the services of an NVE are properly
authorized to do so. One design point is whether the hypervisor authorized to do so. One design point is whether the hypervisor
should supply the NVE with necessary information (e.g., VM addresses, should supply the NVE with necessary information (e.g., VM addresses,
VN information, or other parameters) that the NVE uses directly, or VN information, or other parameters) that the NVE uses directly, or
whether the hypervisor should only supply a VN ID and an identifier whether the hypervisor should only supply a VN ID and an identifier
for the associated VM (e.g., its MAC address), with the NVE using for the associated VM (e.g., its MAC address), with the NVE using
that information to obtain the information needed to validate the that information to obtain the information needed to validate the
hypervisor-provided parameters or obtain related parameters in a hypervisor-provided parameters or obtain related parameters in a
secure manner. secure manner.
6. 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.
7. Acknowledgements 8. Acknowledgements
This document was initiated and merged from the drafts draft-kreeger- This document was initiated and merged from the drafts draft-kreeger-
nvo3-hypervisor-nve-cp, draft-gu-nvo3-tes-nve-mechanism and draft- nvo3-hypervisor-nve-cp, draft-gu-nvo3-tes-nve-mechanism and draft-
kompella-nvo3-server2nve. Thanks to all the co-authors and kompella-nvo3-server2nve. Thanks to all the co-authors and
contributing members of those drafts. contributing members of those drafts.
The authors would like to specially thank Jon Hudson for his generous The authors would like to specially thank Jon Hudson for his generous
help in improving the readability of this document. help in improving the readability of this document.
8. References 8. References
 End of changes. 8 change blocks. 
16 lines changed or deleted 89 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/