draft-ietf-nvo3-hpvr2nve-cp-req-16.txt   draft-ietf-nvo3-hpvr2nve-cp-req-17.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 29, 2018 February 25, 2018 Expires: September 14, 2018 March 13, 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-16 draft-ietf-nvo3-hpvr2nve-cp-req-17
Abstract Abstract
In a Split Network Virtualization Edge (Split-NVE) architecture, the In a Split Network Virtualization Edge (Split-NVE) architecture, the
functions of the NVE (Network Virtualization Edge) are split across a functions of the NVE (Network Virtualization Edge) are split across a
server and an external network equipment which is called an external server and an external network equipment which is called an external
NVE. The server-resident control plane functionality resides in NVE. The server-resident control plane functionality resides in
control software, which may be part of hypervisor or container control software, which may be part of hypervisor or container
management software; for simplicity, this document refers to the management software; for simplicity, this document refers to the
hypervisor as the location of this software. hypervisor as the location of this software.
skipping to change at page 3, line 6 skipping to change at page 3, line 6
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 . . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
8.1 Normative References . . . . . . . . . . . . . . . . . . . 20 8.1 Normative References . . . . . . . . . . . . . . . . . . . 20
8.2 Informative References . . . . . . . . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . . 24
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 (terminal-side NVE) and the on the end device is called the tNVE (terminal-side NVE) and the
portion located on the external NVE is called the nNVE (network-side portion located on the external NVE is called the nNVE (network-side
NVE) in this document. Overlay encapsulation/decapsulation functions NVE) in this document. Overlay encapsulation/decapsulation functions
skipping to change at page 17, line 33 skipping to change at page 17, line 33
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 some or all address(es) of a TSI to disassociate and/or deactivate some or all address(es) of a TSI
instance to a 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 and the connected
End Device connected. End Device to authenticate each other.
Req-12: The protocol MUST be able to run over L2 links between the Req-12: The protocol MUST be able to run over L2 links between the
End Device and its External NVE. End Device and its External NVE.
Req-13: The protocol SHOULD support the End Device indicating if an Req-13: The protocol SHOULD support the End Device indicating if an
associate or activate request from it is the result of a VM hot associate or activate request from it is the result of a VM hot
migration event. migration event.
5. VDP Applicability and Enhancement Needs 5. VDP Applicability and Enhancement Needs
skipping to change at page 19, line 10 skipping to change at page 19, line 10
| 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. Implicit authentication based on |
| | |control of physical connectivity exists in VDP |
| | |when the External NVE connects to the End |
| | |Device directly and is reachable with the |
| | |nearest customer bridge address. |
+------+-----------+-----------------------------------------------+ +------+-----------+-----------------------------------------------+
|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 33 skipping to change at page 19, line 37
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
External NVEs must ensure that only properly authorized Tenant External NVEs must ensure that only properly authorized Tenant
Systems are allowed to join and become a part of any particular Systems are allowed to join and become a part of any particular
Virtual Network. In some cases, tNVE may want to connect to the Virtual Network. In some cases, tNVE may want to connect to the nNVE
authenticated nNVE for provisioning purpose. Then a mutual for provisioning purposes. This may require that the tNVE
authentication between tNVE tand nNVE is required. If a secure authenticate the nNVE in addition to the nNVE authenticating the
channel is required between tNVE and nNVE to carry encrypted split- tNVE. If a secure channel is required between tNVE and nNVE to carry
NVE control plane protocol payload, the existing mechanisms like encrypted split-NVE control plane protocol, then existing mechanisms
MACsec [IEEE 802.1AE] can be used. such as MACsec [IEEE 802.1AE] can be used. In some deployments,
authentication may be implicit based on control of physical
connectivity, e.g., if the nNVE is located in the bridge that is
directly connected to the server that contains the tNVE. Use of
"nearest customer bridge address" in VDP [IEEE 802.1Q] is an example
where this sort of implicit authentication is possible, although
explicit authentication also applies in that case.
As the control plane protocol results in configuration changes for
both the tNVE and nNVE, tNVE and nNVE implementations should log all
state changes, including those described in Section 3.
Implementations should also log significant protocol events, such as
establishment or loss of control plane protocol connectivity between
the tNVE and nNVE and authentication results.
In addition, external NVEs will need appropriate mechanisms to ensure In addition, external NVEs will need appropriate mechanisms to ensure
that any hypervisor wishing to use the services of an NVE is properly that any hypervisor wishing to use the services of an NVE is 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 external NVE with necessary information (e.g., VM should supply the external NVE with necessary information (e.g., VM
addresses, VN information, or other parameters) that the external NVE addresses, VN information, or other parameters) that the external NVE
uses directly, or whether the hypervisor should only supply a VN ID 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 and an identifier for the associated VM (e.g., its MAC address), with
the external NVE using that information to obtain the information the external NVE using that information to obtain the information
needed to validate the hypervisor-provided parameters or obtain needed to validate the hypervisor-provided parameters or obtain
 End of changes. 6 change blocks. 
12 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/