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 < [email protected]> 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. > >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
