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.