Hi Mahesh,
Thanks for your comments.
We will revise the draft accordingly and post a revision after IETF 102.
Regards,
Behcet
On Mon, Jul 2, 2018 at 11:41 PM, Mahesh Jethanandani <mjethanandani@xxxxxxxxx> wrote:
Reviewer: Mahesh Jethanandani
Review result: Has Issues
I have reviewed this document as part of the Operational directorate’s ongoing
effort to review all IETF documents being processed by the IESG.
These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not addressed in last
call may be included in AD reviews during the IESG review. Document editors
and WG chairs should treat these comments just like any other last
call comments.
Document reviewed: draft-ietf-nvo3-vmm-03
Summary:
This document describes a virtual machine mobility protocol commonly used in
data centers built with overlay-based network virtualization approach. For
layer 2, it is based on using a Network Virtualization Authority (NVA)-Network
Virtualization Edge (NVE) protocol to update Address Resolution Protocol (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. For Layer 3, it is based on address and
connection migration after the move.
Document Status:
Has Issues.
Comments:
General Considerations:
The document could do with some much needed rewrite, as it is very hard to
understand its content. There is extensive use of terms like “this virtual
machine”, “those VMs”, and “those NVEs”, without being specific of which
virtual machine or NVE one is referring to.
By the end of the fourth paragraph of Section 4.1, it is very difficult to
understand which VM one is talking about, the source or the destination. The
same is true about the NVE. Is it the old or the new NVE?
The next paragraph starts by saying that RARP is not used by VMs because VM
already knows about its IP address. It then goes on to describe how a end-user
client (a new term, not defined before) goes about getting the same IP address
using RARP. It concludes by saying that that is how IP address assignment is
completed for a migrating VM.
s/central directory at the NVA/central directory of the NVA/
s/recorded to the entry/recorded in the entry/
Also who is “we” in Section 4.2, first paragraph? Also what is “guests”?
Would strongly suggest that the authors discuss the Connection migration
strategy with TCPM WG to understand if their proposal makes sense, as I do not
understand the term “reopen dropped connections”, nor how a connection can be
“paused”.
Finally, in Section 7, the document claims that in a hot standby option, the
VMs in both primary and secondary domains have identical information and can
provide services simultaneously. Does it mean that a TCP connection can talk to
two different VMs at the same time? If so, who is replicating the information
to the two VMs and how is the duplicate information coming from either of the
sources quashed?
The following comments look at the document both from an operational
perspective as well as a management perspective.
Operational Considerations:
Operational considerations include installation and initial setup, migration
path, requirements on other protocols, impact on network operations and
verification of correct operation.
The document is a BCP, so it is not expected to provide any operational
considerations.
Management Considerations:
Management considerations include interoperability, fault management,
configuration management, accounting, performance and security.
The document is a BCP, so it is not expected to provide any management
considerations.
