Somesh, Original comment is to point out a concern about some control plane solution that makes each NVE to maintain the locations of all TESes, which may be not necessary for NVO3.
Lucy From: Somesh Gupta [mailto:[email protected]] Sent: Tuesday, September 11, 2012 3:03 PM To: LASSERRE, MARC (MARC); Lucy yong Cc: [email protected] Subject: RE: comments for the framework-03 draft regarding the last point on 4.2.1; "In section 4.2.1, it only describes a concern on data plane driven, does not say anything on control plane driven. It should mention some traditional control plane dissemination protocol may bring big burden for each NVE to maintain the locations of all TESs. " I assume "control plane" means either a traditional distributed protocol or a centralized management/configuration control? I am not sure why each NVE has to maintain the locations of all TESs - especially when using a centralized management control plane that is closely coupled with the Virtual Server and VM management system. From: [email protected] [mailto:[email protected]] On Behalf Of LASSERRE, MARC (MARC) Sent: Tuesday, September 11, 2012 3:30 AM To: Lucy yong Cc: [email protected] Subject: Re: [nvo3] comments for the framework-03 draft Hi Lucy, See my comments below. Thanks, Marc ________________________________ From: Lucy yong [mailto:[email protected]] Sent: Tuesday, August 14, 2012 8:06 PM To: LASSERRE, MARC (MARC) Cc: [email protected] Subject: comments for the framework-03 draft Hi Marc, I think it is necessary to add server manger component in the section of functional components in the framework draft. As we know, one of main cases for nvo3 is to place NVE on a server. In which, there is no-wire between NVE and TESes. In DC today, a server manager is used to create vswitch/NVE and VMs, place VMs on a VN. Current draft mixes this function in the control plane component, which causes a lot of confusion as seen in the mailing list. In addition, vm placement and mobility are very critical features that nvo3 need to support and these actions are initiated by the server manger, separating control plane component and server manager component makes easy and clear for the solution development to target different parts. The intent is indeed to describe the Network Virtualization functional components independently from the server management component - as you mentioned in your last sentence, this helps identlfying the NVO3 specific management aspects from existing datacenter management functions that have to be implemented. Some text in section 3.5.1.1 can move server manager component section. I propose to add following subsections in server manager component: - NVE and a VN Creation Note: state this applying to when NVE is on server. - Provisioning one or more TESes into an NVE/VNI Note: state this applying to both NVE is on or not-on server. Another comment: It is a bit confusion in figure 4 and 5 to show multiple VNIs with one VN context (single line). What does mean? The idea is to show that several VN instances can be supported concurrently and that the overlay function relies upon a VN context identification to perform its mux/demux related functions. A sentence can be added to clarify this point. Suggest to change section 2.3 title to "virtual network type". One NVE should be able to host both L2 VN and L3 VN. so 2.3.1 and 2.3.2 title misleading. Suggest Replace "L2 NVE providing Ethernet LAN-like service" with "L2 virtual network providing Ethernet LAN-like service" Replace "L3 NVE providing IP/VRF-like service" with "L3 virtual network providing IP VPN-like service" Yes, an NVE can support both L2 and L3 VN services - like a PE can provide both L2 and L3 VPN services. The terms L2 and L3 PEs have been used extensively before, hence the L2 NVE and L3 NVE names. In section 4.2.1, it only describes a concern on data plane driven, does not say anything on control plane driven. It should mention some traditional control plane dissemination protocol may bring big burden for each NVE to maintain the locations of all TESs. Good point. We will add some text in a future revision. Regards, Lucy
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
