Re: [nvo3] AD review of draft-ietf-nvo3-vmm-16

[Linda Dunbar <[e-mail]>]

Martin,

Thank you very much for finally squeezing time to review the draft, after 2 years of WGLC and long journey of revisions to address Areas Directorates comments.  Being an AD is not easy, so many drafts to review..

Replies to your comments are inserted below:

-----Original Message-----
From: Martin Vigoureux <[e-mail]>
Sent: Monday, November 16, 2020 7:22 AM
To: [e-mail]; [e-mail]; [e-mail]
Subject: AD review of draft-ietf-nvo3-vmm-16

Hi,

I have several concerns with this document.

There hasn't been a single response to the WG LC, which by the way happened more than two years ago and the draft has undergone 13 revisions since then.
[Linda] There have been a lot of comments during the Area Directorate reviews, and private comments from NVO3 Chairs.

This document has an evident formatting issue (text width, section titles, Status of This Memo, references, ...), as well as a reasonable number of typos / unclear sentences making it quite hard to understand.
[Linda] Can you elaborate more on those issues? With English as a second language, I am hoping to learn from the mistakes. NVO3 Chair Matthews had a private session with us pointing English language issues, we had revised draft to correct those issues.   We would like to learn more.

It apparently aims at addressing Virtual Machine Mobility, but in fact seems to only cover IP address preservation during such type of event.
This must be clarified.
[Linda] one of the big issues of VM Mobility in Layer 3 is when the VMs need to maintain their original IP addresses after their move. If VMs addresses can be re-assigned after their move, network becomes very simple but applications running on the VMs  can’t be moved freely.
Layer 2 addresses don’t have hierarchical structure as Layer 3 IP addresses. All switches learn the host Layer 2 addresses on the fly and time out the learned addresses in the Forwarding table when there is no packets has the addresses in the SA/DST fields for certain period of time.
That is why the draft is focusing on practices and actions when VMs need to maintain their addresses after the move.

It is not clear to me what is specific to NVO3 networks in this document.
[Linda] The draft is to address the NVO3 Charter:
      The NVO3 WG will develop solutions for network virtualization based on
      the following architectural tenets:
      - Support for an IP-based underlay data plane

This document is said to describe solutions *commonly* used in data centers. Also, it primarily only describes what needs to be done but not how.
This makes me wonder what benefit does it bring to the community and to operators of data centers.
[Linda] This document provides guidelines to DC operators if they want to maintain VMs IP addresses during VM migration. Being able to move VMs dynamically, from one server to another, makes it possible for dynamic load balancing or work distribution. Therefore, dynamic VM Mobility is highly desirable for large scale multi-tenant DCs

This document refers to other specifications which themselves do not provide the missing pieces e.g., RFC7666 does not describe how to transfer VM states;
[Linda] That is why we wrote this draft to indicate that VMs states transferred are needed. But during the numerous reviews, we had been advised to remote the actual protocols of moving states and change the document to be “Informational” (from Standard Track).

RFC8014 is not a specification for an NVE-to-NVA protocol.
[Linda] RFC8014 describes the NVE-to-NVA functions.

How section 7 relates to the rest of the document is unclear. It seems to restate some elements described in 4.2 and 4.3 but not all.
[Linda] Section 4 is the Overview.  Section 7 describes the details of the Overview of Section 4.

Section 8 and 9 seem to be out of the scope of this document.
[Linda] Section 8 and 9 describes what triggers the VMs move. It was suggested from Aera Directorates review comments.

In its current state the document is not ready for review by the IESG and I'm returning it to the WG. I encourage the WG to evaluate the benefit of publishing this as an RFC, to discuss whether this should be the product of NVO3 and would an alternate publication stream be more appropriate. In any case this document needs more work.
[Linda]   We are going around in circles.


-m