Last Call Review of draft-ietf-nvo3-vmm-03
|Requested rev.||03 (document currently at 05)|
|Type||Last Call Review|
|Team||Ops Directorate (opsdir)|
|Requested by||Matthew Bocci|
|Draft last updated||2018-07-02|
Opsdir Last Call review of -03 by Mahesh Jethanandani
Rtgdir Last Call review of -03 by IJsbrand Wijnands (diff)
Tsvart Last Call review of -04 by Bob Briscoe (diff)
This document has just entered working group last call in the NVO3 working group. I am asking for broader review for two reasons: Most of the content was developed some time ago and could do with a fresh and detailed review. Secondly, it deals with some of the networking considerations that result from the way virtual machines are managed in a data center. I want to make sure that any potential issues for the overlay network that result from VM mobility and the management thereof are addressed, hence the request for review from the Ops area. The working group last call finishes on 29th June, but it is fine for any further reviews to take longer as I am aware of the short timeframe of the request. I will wait for all reviews t be addressed before progressing the document.
|Reviewed rev.||03 (document currently at 05)|
|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.