Linda,
please see in-line.
Le 2020-11-17 à 20:38, Linda Dunbar a écrit :
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 <[email protected]>
Sent: Monday, November 16, 2020 7:22 AM
To: [email protected]; [email protected]; [email protected]
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.
Indeed, but that doesn't explain the silence at WG LC stage, and is in
fact a strong incentive for running a new one, and in fact have a
broader discussion about this draft.
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 moreI'm not a native english speaker/writer, but it is at least easy to
notice the formatting issue your document has. I can go through the
document an pick the nits/typos and hard-to-parse sentences but that is
not the core of the issue.
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.I understood that. My point is that this document should therefore not
be called virtual machine mobility.
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/
That sort of confirms this is not NVO3 specific.
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
possibly, but if those techniques are already in use, what is the
benefit of having an RFC describing them? virtual machine mobility seems
to be fairly well documented already and much more broadly than just
about IP addressing preservation. It is also very challenging for the
reader to determine whether all aspects of IP address preservation have
been covered.
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).
I'm ok with that recommendation, because moving states has little to do
with IP address preservation. The issue I point to is that you refer to
RFC7666 for more information on moving states, but nothing in RFC7666
talks about that.
RFC8014 is not a specification for an NVE-to-NVA protocol.
[Linda] RFC8014 describes the NVE-to-NVA functions.
indeed but your document doesn't say clearly which functions need to be
activated and how is effectively used the protocol to achieve the
desired objective.
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.
hmmm, then we can add this to the things that need to be clarified.
Section 7 mas much less information than 4.2/4.3. In fact it is 42 lines
long while 4.2+4.3 are 142 (and section 4, as a whole, 233). How can the
overview be longer than the details?
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 the intro you say that this document covers planned VM moves.
Section 8 talks about other reasons for a move (failover, load, ...).
This is confusing and in fact doesn't add anything to IP address
preservations. Section 9 itself says that it is outside the scope of the
document.
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.
Not all drafts become RFCs and not all paths to RFC are straight.
I'm not taking a decision here, I'm asking the WG to have a discussion.
-m
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
