1 / 9

Hypervisor to NVE Control Plane Requirements

Hypervisor to NVE Control Plane Requirements. draft-ietf-nvo3-hpvr2nve-cp-req-00. Yizhou Li, Lucy Yong, Lawrence Kreeger Thomas Narten, David Black. Draft History. The draft was a merge from three drafts draft-kreeger-nvo3-hypervisor-nve-cp, draft-gu-nvo3-tes-nve-mechanism

kaethe
Download Presentation

Hypervisor to NVE Control Plane Requirements

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Hypervisor to NVE Control Plane Requirements draft-ietf-nvo3-hpvr2nve-cp-req-00 Yizhou Li, Lucy Yong, Lawrence Kreeger Thomas Narten, David Black

  2. Draft History • The draft was a merge from three drafts • draft-kreeger-nvo3-hypervisor-nve-cp, • draft-gu-nvo3-tes-nve-mechanism • draft-kompella-nvo3-server2nve • Adopted into a WG draft in June 2014

  3. Overview • Hypervisor: a container running a control plane protocol on an end device signaling w/ its external NVE. • Hypervisor to NVE control plane protocol applicability: split NVE architecture only, i.e. external NVE case • Purpose of the protocol • Populate external NVE with the states needed to perform NVO functions • Trigger NVE-NVA, NVE-NVE, or local NVE events

  4. VM lifecycle (taken from ietf-opsawg-vmm-mib fig 2) • FYI only. Events triggering a signal to its external NVE VM migration on dst VM migration on src VM creation

  5. Protocol Functionality • VN connect/disconnect • make the NVE aware of the changing of VN membership from a TS • NVE returns: a VAP ID for that VN, e.g. local VLAN tag • TSI associate/disassociate: asso./disasso. TSI address(s) to a VAP on port p (No real traffic expected yet) • TSI activate/deactivate: act./deact. TSI address(s) to a VAP on port p (allow real traffic) Init asso disasso clear activate Associated activate Activated deactivate State Summary of TSI association on a VAP

  6. Protocol Requirements • The protocol is able to run between the hypervisor and its external NVE which may directly connected or bridged in split-NVE architecture. • The protocol MUST support the hypervisor initiating a request to its external NVE to be connected/disconnected to a given VN. • In response to the connection request to a given VN received on NVE's port p as per Req-2, the protocol SHOULD support NVE replying a locally significant tag assigned, for example 802.1Q tag value, to each of the VN it is member of. NVE should keep the record of VN ID, local tag assigned and port p triplet. • The protocol MUST support the hypervisor initiating a request to associate/disassociate, activate/deactive or clear address(es) of a TSI instance to a VN on an NVE port. All requests should be logically consistent with text in section 5.2 & 5.3. • The protocol MUST support the hypervisor initiating a request to add, remove or update address(es) associated with a TSI instance on the external NVE. Addresses can be expressed in different formats, for example, MAC, IP or pair of IP and MAC. • When any request of the protocol fails, a reason code MUST be provided in the reply. • The protocol MAY support the hypervisor explicitly informing NVE when a migration starts. It may help NVE to differentiate a new associated/activated TSI resulting from VM creation or VM migration. • The protocol SHOULD be extensible to carry more parameters to meet future requirements, for example, QoS settings.

  7. Clarifications • Is L3 connectivity between hypervisor & NVE excluded? • No. Address registration include both MAC and IP • Server without a hypervisor case • Hypervisor is defined as a generic terminology • A non-virtualization server is not an end device in this context and this protocol does not apply such server • Is VDP in appendix appropriate? • Information only. Kept in current version.

  8. Clarifications (Cont.) • If a TS runs as a transparent appliance and connects to an external NVE, how it register addresses? NVE 10 NVE1 NVE2 FW (transparent? ) VM1 VM2 • What is transparent? Invisible to src and dst VMs. Tunnel directly between NVE1 & NVE2 • How to make sure the traffic go to the transparent appliance on remote NVE? • Transparent appliances need to co-locate with ingress/egress NVE. (i.e. NVE1 & NVE2) • If an appliance connects to a remote NVE, i.e. NVE10, such appliance is not considered as transparent, and has gateway function.

  9. Next Steps • Next revision: • add security requirement for protocol to the list • make definition of “hypervisor”generic or use “end device” instead • Addresscomments and suggestions from the WG

More Related