This protocol is needed for ANY IP address that moves, no matter what type of device or layer-2 physical technology is used.
Think of the equivalent of what IGMP does for receivers (but we needed a "request-to-send" for multicast sources that was never developed it). Dino On Oct 8, 2014, at 7:51 AM, Linda Dunbar <[email protected]> wrote: > Dino, > > IEEE802.1Qbg developed this host to Edge (NVE) protocol more than 3 years > ago. The problem is that the servers/hypervisors deployed in data centers are > from many different vendors and they all have their own behavior. That is why > 802.1Qbg hasn't be widely deployed. > > Sad to say that networking is only a very small portion (<15%) of entire data > center cost. > > It is not Lack of Protocol, but it is lack of interests from server vendors. > > However, network can utilize Server Management (e.g. vCenter or SystemCenter > via NVA) to notify all the NVEs on the attached IP addresses. > > Linda > > -----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
