Linda,
Le 2020-11-19 à 18:39, Linda Dunbar a écrit :
[Linda] Is it better to call the draft "Solutions to preserve IP Addresses during VM
mobility in Layer 2 and Layer 3 Networks"?
that would work
That sort of confirms this is not NVO3 specific.
[Linda] Do you suggest to go through independent RFC stream?
IMO, if the WG thinks that the content is worth publishing as an RFC and
considers that this is not specific to NVO3 then the WG should consider
that option.
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.
[Linda] We have aimed to cover all aspects of IP address preservation. If we
miss some aspects, can you elaborate?
I didn't say you were missing some.
In any case consistently with my previous point, I think the WG needs to
discuss the added value this brings. It would be great to have feedback
from DC operators as they are the targetted community of this document.
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.
[Linda] Thank you for the specific action. we can add.
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?
[Linda]Interesting point. Will ask the WG if more needs to be added or removed.
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.
[Linda] "failover, planned VM moves" are some of the reasons triggering the "VM
Moving".
indeed but again, Section 8 is not clear. It is called "Other options".
But it is not clear other options to what. Section 8 starts by talking
about "unexpected events" so that leads me to thinking this is not in
scope of the document because of the intro which says "planed moves".
But then Section 8 goes on talking about Hot Failover. Do you mean to
cover in section 8 the "Hot" mobility and in Section 7 the Warm and Cold
mobility? But Section 7 does have some text on "Hot".
All in all, at the very least, some clarifications are needed.
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.
[Linda] sure.
-m
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
