Agree what you said. If NVE resides on the End device (host in your term), internal states can serve the purpose of the protocol. In the split-NVE case, i.e. use external NVE, such protocol between end device and external NVE is necessary. The protocol requirements are described in draft-ietf-nvo3-hyrv2nve-cp-req.
Lucy -----Original Message----- From: nvo3 [mailto:[email protected]] On Behalf Of Dino Farinacci Sent: Wednesday, October 08, 2014 8:28 AM To: Black, David Cc: [email protected]; Sri Gundavelli (sgundave) Subject: Re: [nvo3] Poll for a better name for draft-merged-nvo3-vm-mobility-scheme-00.txt There is a real problem that this working group could work on. It has been a problem with VM-mobility for a while now (4 years now). The fact that when the IP address moves and doesn't signal to the network is a REAL problem. Come up with a protocol that says "hi-I-have-arrived" as well as "bye-I-am-leaving". This protocol needs to be explicit. In the VM-mobility use-cases I have been involved in, you cannot depend on ARP because not all hypervisors will ARP when they come and go. The only solution today, when there is no involvement from the IP address entity, is to listen to the MAC address it is sending on. This is kludgy and causes all sorts of hoops the implementation has to jump through. So focus on a "host to NVE" protocol would bring something to the table. Dino 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
