[nvo3] Draft NVO3 WG Charter

[Pedro Marques <[e-mail]>]

David,
In a previous message, you write:

> Incremental deployment also leaves a bit to be desired, as the
> approach described in the marques-l3vpn-end-system does not work with
> existing VM live migration implementations, because the VM's IP addressing
> ("VM route table" in the draft) has to be modified.  This has some
> consequences:

>	- Existing live VM migration implementations won't be able to move
>		a VM between VLAN and MPLS-BGP environments because they
>		don't reconfigure the VM route table.
>	- New live VM migration implementations that want to support this
>		sort of cross-environment migration will need additional
>		functionality (e.g., may need to coax the VM to go renew
>		its DHCP lease to discover what happened, and hope it copes).
>	- Cold migration of a VM between VLAN and MPLS-BGP environments
>		requires reconfiguration to change the VM route table. 
>		Similarly, use of a common VM template across both environments
>		requires an additional reconfiguration step.
David,
The draft in question suggests that the VM route table be configured with a local IP address as a /32 and a default routers (the hypervisor). However, as it has been pointed out in other mailing lists, one could also choose to configure the VM with a /24 and proxy ARP reply at the hypervisor (i.e. the VMs default router). I believe this is the "IP addressing" that you assume in your scenario above.

The document is targeted at scenarios where L3 transparency is required, but L2 transparency is not. In the environments i'm more familiar with VM migration requires L3 transparency only in order to maintain IP connectivity un-interrupted. And in this environments removing the requirement to support L2 transparency can lead to improved performance for L3 connectivity if, for instance, the L2 solution imposes convergence delays.

regards,
  Pedro.