Subject: Re: [nvo3] Fwd: New Version Notification for draft-sarikaya-nvo3-vmm-dmm-pmip-08.txt

From: Nicolas Bouliane <[email-masked]>
Date: Mon, 4 Apr 2016 15:28:08 -0400

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 ?

Thank you,
Nicolas

On Sun, Mar 6, 2016 at 8:43 PM, B. Khasnabish <[email-masked]> 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-masked]>
> 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-masked]>, Linda Dunbar <
> [email-masked]>, Behcet Sarikaya <[email-masked]>, Frank Xia <
> [email-masked]>, Linda Dunbar <[email-masked]>
>
>
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
>

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 4 Apr 2016 16:13:22 -0500

> 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?

Regards,

Behcet
>> (VMM, https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-vmm-dmm-pmip/)
>> To: Bhumip Khasnabish <[email-masked]>, Linda Dunbar
>> <[email-masked]>, Behcet Sarikaya <[email-masked]>, Frank Xia
>> <[email-masked]>, Linda Dunbar <[email-masked]>
>>
>>
>>

---

From: Nicolas Bouliane <[email-masked]>
Date: Mon, 4 Apr 2016 19:46:16 -0400

> After that time the source NVE stops tunneling.

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 ?

> >> (VMM,
> https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-vmm-dmm-pmip/)