Subject: [nvo3] Re. WG adoption consideratios for draft-sarikaya-nvo3-vmm-dmm-pmip-05.txt

From: "[email-masked]" <[email-masked]>
Date: Mon, 9 Feb 2015 10:02:57 -0500

Dear All,

Requesting for WG adotoption of this draft
(https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-vmm-dmm-pmip/).

As you know, managing virtual machine mobility is one of the major
requirements for overlay networks, especially in data centers, and this
draft addresses this.

If we are missing any crucial considerations, KINDLY bring those to our
attention ASAP.

Many Thanks in advance.

Best.
Bhumip
                   __o
             _ `\ <, _
.......... ( • ) / ( • ) ......................

---------- Forwarded message ----------
From: Behcet Sarikaya <[email-masked]>
Date: Mon, Feb 2, 2015 at 6:35 PM
Subject: [nvo3] New Version Notification for
draft-sarikaya-nvo3-vmm-dmm-pmip-05.txt
To: "[email-masked]" <
​​
[email-masked]>
Hi all,

We revised VM Mobility solution draft as follows. This revision is
based on the comments received during the interim meeting last year
and the solution satisfies all requirements in RFC 7364, etc.

Regards,

Behcet

A new version of I-D, draft-sarikaya-nvo3-vmm-dmm-pmip-05.txt
has been successfully submitted by Behcet Sarikaya and posted to the
IETF repository.

Name:           draft-sarikaya-nvo3-vmm-dmm-pmip
Revision:       05
Title:          Virtual Machine Mobility Protocol for Overlay Networks
Document date:  2015-01-30
Group:          Individual Submission
Pages:          12
URL:
http://www.ietf.org/internet-drafts/draft-sarikaya-nvo3-vmm-dmm-pmip-05.txt
Status:
https://datatracker.ietf.org/doc/draft-sarikaya-nvo3-vmm-dmm-pmip/
Htmlized:
http://tools.ietf.org/html/draft-sarikaya-nvo3-vmm-dmm-pmip-05
Diff:
http://www.ietf.org/rfcdiff?url2=draft-sarikaya-nvo3-vmm-dmm-pmip-05

Abstract:
   This document specifies a virtual machine mobility protocol in data
   centers built with overlay-based network virtualization approach.
   The protocol is based on the virtual machine sending a gratuitous
   Address Resolution Protocol request in IPv4 and unsolicited neighbor
   advertisement message in IPv6 which are broadcast or sent to all
   nodes after moving to the new Network Virtualization Edge.  These
   messages enable the Network Virtualization Edges update their virtual
   machine MAC address to the tunnel endpoint tables.

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: Zu Qiang <[email-masked]>
Date: Mon, 9 Feb 2015 18:22:53 +0000

Hello, Bhumip
                Reading the section 4, the described ARP/ND updating procedures, both IPv4and IPv6, are not aligned with the procedure described in the architecture draft. In the architecture draft, the TS traffic is always forwarded by the NVE based on the inner-outer address mapping table which is always configured by the NVA. According to your draft, the VM sends ARP / ND after the VM mobility. Then the remote NVEs updates the inner-outer address mapping table based on the data plane learning, i.e. snooping on the APR / ND messages without any NVA-NVE control protocol. The problem is that the NVE and the NVA may be out of sync. Are you going to define any NVA updating  procedure later?

Have a nice day
Zu Qiang

From: nvo3 [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, February 09, 2015 10:03 AM
To: [email-masked]
Subject: [nvo3] Re. WG adoption consideratios for draft-sarikaya-nvo3-vmm-dmm-pmip-05.txt

Dear All,

As you know, managing virtual machine mobility is one of the major requirements for overlay networks, especially in data centers, and this draft addresses this.

If we are missing any crucial considerations, KINDLY bring those to our attention ASAP.

Many Thanks in advance.

Best.
Bhumip
                   __o
             _ `\ <, _

---------- Forwarded message ----------
From: Behcet Sarikaya <[email-masked]<mailto:[email-masked]>>
Date: Mon, Feb 2, 2015 at 6:35 PM
Subject: [nvo3] New Version Notification for draft-sarikaya-nvo3-vmm-dmm-pmip-05.txt
To: "[email-masked]<mailto:[email-masked]>" <
​​
[email-masked]<mailto:[email-masked]>>
Hi all,

Regards,

Behcet

Htmlized:       http://tools.ietf.org/html/draft-sarikaya-nvo3-vmm-dmm-pmip-05

Abstract:

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<http://tools.ietf.org>.

The IETF Secretariat

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 9 Feb 2015 16:31:56 -0600

Hello Qiang,

On Mon, Feb 9, 2015 at 12:22 PM, Zu Qiang <[email-masked]> wrote:
> Hello, Bhumip
>
>                 Reading the section 4, the described ARP/ND updating
> procedures, both IPv4and IPv6, are not aligned with the procedure described
> in the architecture draft. In the architecture draft, the TS traffic is
> always forwarded by the NVE based on the inner-outer address mapping table
> which is always configured by the NVA. According to your draft, the VM sends
> ARP / ND after the VM mobility. Then the remote NVEs updates the inner-outer
> address mapping table based on the data plane learning, i.e. snooping on the
> APR / ND messages without any NVA-NVE control protocol. The problem is that
> the NVE and the NVA may be out of sync. Are you going to define any NVA
> updating  procedure later?

If needed yes.
I think you are talking about additional functionality in NVA-NVE
protocol for VM mobility. Currently
https://tools.ietf.org/html/draft-ietf-nvo3-nve-nva-cp-req-03 does not
have any specific text on this.

Regards,

Behcet