Re: [nvo3] Opsdir last call review of draft-ietf-nvo3-vmm-03

[Behcet Sarikaya <[e-mail]>]

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 <
[e-mail]> 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.
>
>