> > The common element in both cases is the network address movement - > > That's precisely the IP Mobility protocols that are out there are designed > for. IP address state is moved and we make the network aware of that.
Fair enough, but they are not the only to move IP addresses. I'm not advocating any new protocol for moving IP addresses - speaking for myself, the techniques that I'm most interested in move IP addresses as a side effect of moving layer 2 MACs (e.g., "gratuitous ARP"). There is an enormous amount of deployed "running code" that does that without using mobile IP; the techniques used by that "running code" fall squarely into the "ain't broken" category, and I see no need to replace them with IP mobility protocols. The nvo3 work is of interest to me because in its most basic form, it can extend those layer-2-based techniques to work across IP forwarding hops in the underlay by providing effective layer-2 adjacency in the overlay, and more sophisticated forms can optimize those techniques based on NVA knowledge of what's going on. Thanks, --David > -----Original Message----- > From: Sri Gundavelli (sgundave) [mailto:[email protected]] > Sent: Wednesday, October 08, 2014 12:27 AM > To: Black, David > Cc: [email protected] > Subject: Re: [nvo3] Poll for a better name for draft-merged-nvo3-vm-mobility- > scheme-00.txt > > David, > > Ok. Fair enough. Any transient, ephemeral and hardware-specific state does > not go with it. But, the question comes back, how much of that state is > relevant for the forwarding plane in the network. May be the applications > will rebuild that state on the target node. Why should a layer-3 mobility > protocol care about that state ? So, if there be a definition of a new > protocol, is there an assumption that the new protocol will be aware of > such state ? > > > > The common element in both cases is the network address movement - > > That's precisely the IP Mobility protocols that are out there are designed > for. IP address state is moved and we make the network aware of that. > > > > Regards > Sri > > > > On 10/7/14 9:07 PM, "Black, David" <[email protected]> wrote: > > >Sri, > > > >> On 10/7/14 8:32 PM, "Tom Herbert" <[email protected]> wrote: > >> > >> >You've reverted to posing the networking virtualization problem in > >> >terms of virtual machines which leads to a use case specific > >> >solution-- this is exactly the reason I suggested to not use the term. > >> >The general problem is not (virtual) machine migration, it is a > >> >problem of moving networking state between hosts and adapting the > >> >network to be aware of this. > >> > >> That "networking" state when it is migrated from physical device-1 to > >> device-2, does not migrate alone; It takes along with it, all the > >> applications, connections and forwarding states. Those application > >>expect > >> IP mobility and that moves the problem to the general category of > >> (virtual) machine migration. > > > >No, it does not take all that with it, sorry. As I wrote earlier ... > > > >------------ > >... both ends of the spectrum of connection state preservation are > >reasonable and used in practice: > > > >- VM live migration preserves TCP connections and the like. > >- IP address takeover on hardware failure doesn't preserve > > anything whose state was solely on the hardware that's now a > > smoking pile of parts. > >------------ > > > >The common element in both cases is the network address movement - > >what other state also moves depends on why the network address(es) > >are being moved. > > > >If you disagree, please explain how to extract TCP connection > >state from "a smoking pile of parts" ;-). > > > >Thanks, > >--David > >---------------------------------------------------- > >David L. Black, Distinguished Engineer > >EMC Corporation, 176 South St., Hopkinton, MA 01748 > >+1 (508) 293-7953 FAX: +1 (508) 293-7786 > >[email protected] Mobile: +1 (978) 394-7754 > >---------------------------------------------------- > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
