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
