Not exactly. The orchestration system could allocate network and VM related 
provisioning tasks to the Network manager and the VM manager respectively which 
in turn perform the corresponding provisioning task since network managers from 
many vendors have already been able to support 
northward interfaces. Furthermore, if DC operators want standard northward 
interfaces, should the to-be-formed SDN (note that the SDN here doesn't mean 
Openflow) WG or other WG be responsible for such standardization work.

Best regards,
Xiaohu
________________________________________
发件人: Jon Hudson [[email protected]]
发送时间: 2012年8月1日 2:49
到: Xuxiaohu
Cc: [email protected]; [email protected]
主题: Re: [nvo3] draft-kompella-nvo3-server2nve

You are assuming a single vendor hypervisor environment with a single 
management tool.

This is not a safe assumption

On Jul 31, 2012, at 11:22 AM, Xuxiaohu <[email protected]> wrote:

>
> Thinks like tenant virtualization local VLAN assignments are already
> provided today by DC orchestration system when the VM is created. I do
> not think that asking NVE TOR for this information as well as other
> network information of VMs is a good direction at all.
>
> [Xiaohu] I have the same concern. If somebody believes it's worthwhile to 
> pursue this direction, It would be better to prove what distinct advantages 
> this NVE-ToR signalling can provide compared to the orchestration system 
> based approach. In addition, I disgree to the claim made in this draft that 
> ARP is not a starting point. If the VM profile has already been provisioned 
> by some means, e.g., using the orchestration system, the gratuitous ARP 
> packet generated by the moved VM could actually be interpreted as a 
> notification of VM attachment event.  As for the claim that ARP can not 
> realize VM detachment notification, IMHO, it heavily depends on what specific 
> NV technology is used. Take the VPLS as an example, the flooding of the 
> gratiutous ARP packet could be interpreted by the old NVE to which the moved 
> VM was previously attached as a implicit withdraw.
>
> Best regards,
> Xiaohu
>
> Best regards,
> R.
>
>
> _______________________________________________
> nvo3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3
> _______________________________________________
> nvo3 mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to