I think this is exactly the point. There are IP address mobility protocols which requires concentrated anchors so the internet doesn't think they move
This approach is not usable in a Datacenter because you can't create anchor bottlenecks. What does work is not the "gratuitous arp" per say, but the two tier ID-Location network aka the NVE. This enables the dynamic allocation of distributed mobility anchors, albeit this requires some mechanism to distribute context aka the NVA. Some "working code" defacto NVA mechanisms out there assume very few addresses can move e.g. just the servers on VMs. Some defacto NVAs out there Don't assume that, and allow Any IP address can move, server Or Client. The WG insists on treating these two different defacto code bases the same eg the BGP and LISP text. But they are not the same. As we dive into the all these detailed issues it will become further evident. --szb On Oct 7, 2014, at 9:58 PM, Black, David <[email protected]> wrote: >>> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
