Re: [sami] : A new draft on state migration use cases is submitted.

[<[e-mail]>]

Hi Melinda,

> I still think there's a core of an interesting idea here and I'm
> pretty frustrated that on the one hand its advocates have not been
> able to make a stronger case and that on the other hand they won't
> let it stew quietly at the back of the stove for a little while.
> In particular, in a crunchy-on-the-outside network security model
> there's state associated with firewalling and with NAT *in* *network*
> *devices* that will probably need to move, but the authors haven't
> presented a case for that, the service providers are apparently not
> asking for that, and it seems to have drifted out of the picture.
> Instead, we're getting some fairly confusing (and unsupported)
> assertions about performance and DHCP sniffing and all sorts of
> things that mostly leave me doubting what I'm reading (they're
> not helped much by the early history of the cloud/datacenter
> advocacy at the IETF).

I'll go further here - having taken another detailed look, I don't see a
a DHCP snooping/sniffing problem that needs a protocol solution.  The DHCP
snooping/sniffing and related ARP filtering technology is intended to prevent
unwanted changes to MAC/IP address binding (e.g., ARP cache poisoning).  When
a VM moves, MAC/IP bindings are unaffected; what changes is the interface
that the VM's MAC(s) now reside(s) at.  It should be sufficient to ensure
that the gratuitous ARP issued after a VM moves updates not only the MAC
learning tables in the switch, but also any interface information in the
DHCP snooping/sniffing info retained by the switches.

That feels like an implementation problem:
	- Make sure the info obtained from DHCP snooping/sniffing is shared
		across the L2 network domain that supports live VM migration.
		As part of this, the entire L2 network domain should uniformly
		support DHCP snooping/sniffing, not just part of the domain.
	- Make sure that the gratuitous ARP issued after a live VM migration
		updates the interface in the DHCP snooping/sniffing info in
		addition to updating MAC learning information.

I still think there's a firewall problem, but the really compelling case may be
VM live migration across distance (different data centers), and that's still an
emerging use case.  That requires stretching an L2 domain across the data centers
- there are a number of ways to do this, including L2VPNs and OTV (see
draft-hasmit-otv for the latter).

I'm not sure about NAT state, as neither the IP nor the MAC changes when the
VM moves - for this reason, moving a VM across sides of a NAT doesn't seem like
something that's likely to work well.


Thanks,
--David

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Melinda Shore
> Sent: Wednesday, October 12, 2011 2:41 AM
> To: Juergen Schoenwaelder
> Cc: Yingjie Gu(yingjie); "'卓志强(研七 福州)'"; 'Linda Dunbar'; 'A tao'; "'刘茗(研六 福州)'";
> sami@i etf.org
> Subject: Re: [sami] 答复: A new draft on state migration use cases is submitted.
> 
> On 10/11/11 10:17 PM, Juergen Schoenwaelder wrote:
> > My understanding is that today neither hypervisors nor 'switches'
> > support the state live migration you want.
> 
> There's been some work done around a more static scenario - SCTP and
> NAT - although I'm not sure what state it's in.  Probably worth
> checking out whether anything's been done with regard to this in
> mobile IP.
> 
> I will say, based on the midcom architectural work and the follow-on
> stuff with route-coupled signaling protocols that the topology-related
> problems with moving flow-coupled state around the network is
> exceptionally difficult - sufficiently difficult, I think, that
> it really is a good idea to avoid it when possible.
> 
> I still think there's a core of an interesting idea here and I'm
> pretty frustrated that on the one hand its advocates have not been
> able to make a stronger case and that on the other hand they won't
> let it stew quietly at the back of the stove for a little while.
> In particular, in a crunchy-on-the-outside network security model
> there's state associated with firewalling and with NAT *in* *network*
> *devices* that will probably need to move, but the authors haven't
> presented a case for that, the service providers are apparently not
> asking for that, and it seems to have drifted out of the picture.
> Instead, we're getting some fairly confusing (and unsupported)
> assertions about performance and DHCP sniffing and all sorts of
> things that mostly leave me doubting what I'm reading (they're
> not helped much by the early history of the cloud/datacenter
> advocacy at the IETF).
> 
> If you can forgive a badly-mixed metaphor I think this particular
> stewpot has run out of track.
> 
> Melinda
> _______________________________________________
> sami mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sami