On Mon, Apr 4, 2016 at 5:13 PM, Behcet Sarikaya <[email protected]> wrote:
> On Mon, Apr 4, 2016 at 2:28 PM, Nicolas Bouliane <[email protected]> > wrote: > > Hello Authors of of draft-sarikaya-nvo3-vmm-dmm-pmip, > > > > In chapter 5: "Handling Packets in Flight" it is written: > > > > "Stop Tunneling Packets When source NVE stops receiving packets > > destined to the virtual machine that has just moved to the > > destination NVE." > > > > > > How can you know that the source NVE won't receive packets destined to > the > > virtual machine anymore ? > > > > As we mentioned, it takes a few seconds to move a VM and during that > time period, the packets in flight should be tunneled. > We could define a protocol configuration variable with a default value > of 5seconds, if you like? > > After that time the source NVE stops tunneling. > > What do you think? > Please correct me if I'm wrong but, or if I misunderstood something. In Chapter 4 it is written: "All NVEs communicating with this virtual machine uses the old ARP entry. If any VM in those NVEs need to talk to the new VM in the destination NVE, it uses the old ARP entry. Thus the packets are delivered to the source NVE. The source NVE MUST tunnel these in- flight packets to the destination NVE. When an ARP entry in those VMs times out, their corresponding NVEs should access the NVA for an update." If the VM is a FreeBSD machine, the entry is held in the cache for 1200seconds by default. So I would think that 5sec is too short. In Chapter 8 it is written: "Virtual machine sends a gratuitous Address Resolution Protocol or unsolicited Neighbor Advertisement message upstream after each move." Does that gratuitous ARP will reach the VMs connected to the source NVE ? If so, that way it would force all VMs to refresh their cache. I presume that once every VMs have received it, we could assume that the source NVE won't receive packets destined to the virtual machine anymore ? > > Regards, > > Behcet > > Thank you, > > Nicolas > > > > On Sun, Mar 6, 2016 at 8:43 PM, B. Khasnabish <[email protected]> wrote: > >> > >> > >> Dear All, > >> > >> We have addressed all of the outstanding issues, comments, > >> and suggestions in the latest version (ver-08) of this > >> draft on Virtual Machine Mobility > >> (VMM, > https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-vmm-dmm-pmip/) > >> and look forward to your support for WG adoption and subsequent > >> publication. > >> > >> Many thanks in advance. > >> > >> Best. > >> > >> Bhumip > >> > >> > >> > >> ---------- Forwarded message ---------- > >> From: <[email protected]> > >> Date: Thu, Mar 3, 2016 at 7:28 PM > >> Subject: New Version Notification for > >> draft-sarikaya-nvo3-vmm-dmm-pmip-08.txt > >> To: Bhumip Khasnabish <[email protected]>, Linda Dunbar > >> <[email protected]>, Behcet Sarikaya <[email protected]>, Frank > Xia > >> <[email protected]>, Linda Dunbar <[email protected]> > >> > >> > >> > >> A new version of I-D, draft-sarikaya-nvo3-vmm-dmm-pmip-08.txt > >> has been successfully submitted by Behcet Sarikaya and posted to the > >> IETF repository. > >> > >> Name: draft-sarikaya-nvo3-vmm-dmm-pmip > >> Revision: 08 > >> Title: Virtual Machine Mobility Protocol for Overlay Networks > >> Document date: 2016-03-03 > >> Group: Individual Submission > >> Pages: 11 > >> URL: > >> > https://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-vmm-dmm-pmip-08.txt > >> Status: > >> https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-vmm-dmm-pmip/ > >> Htmlized: > >> https://tools.ietf.org/html/draft-sarikaya-nvo3-vmm-dmm-pmip-08 > >> Diff: > >> https://www.ietf.org/rfcdiff?url2=draft-sarikaya-nvo3-vmm-dmm-pmip-08 > >> > >> Abstract: > >> This document describes a virtual machine mobility protocol commonly > >> used in data centers built with overlay-based network virtualization > >> approach. It is based on using a NVA-NVE protocol to update ARP > >> table or neighbor cache entries at the NVA and the source NVEs > >> tunneling in-flight packets to the destination NVE after the virtual > >> machine moves from source NVE to the destination NVE. > >> > >> > >> > >> > >> Please note that it may take a couple of minutes from the time of > >> submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> The IETF Secretariat > >> > >> > >> > >> _______________________________________________ > >> nvo3 mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/nvo3 > >> > > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
