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
