[nvo3] Shepherd's review of draft-ietf-nvo3-vmm-06

["Bocci, Matthew (Nokia - GB)" <[e-mail]>]

Authors

Here is my document shepherd’s review. Please treat these comments as you would any other last call comment.

Thanks

Matthew

The document is missing the definite article (‘the’, ‘a’ etc) in numerous places. Please go through the document carefully and correct these.

Please expand the term ‘DC’ on first use.

Section 3, Requirements
VM mobility should not require changing their IP addresses after the
   move.

MB> Who is ‘their’? Do you mean ‘a VM’s’ ?


   There exist "Hot Migration" where transport service continuity is
   maintained, and "Cold Migration" where the transport service needs
   to be restarted, i.e., execution of the tasks   is stopped on the
   "Old" NVE, moved to the "New" NVE and the task is restarted.

MB> What is the requirement here? Can you rephrase this paragraph?


4.1. VM Migration in Layer-2 Network
[...]
Therefore, this scheme is highly desirable for utilization in
     large scale multi-tenant DCs.

MB> Which scheme? Do you mean dynamic VM mobility? Please can you clarify this sentence.

[...]

Such a change enables all NVEs
     to encapsulate the outgoing MAC frames with the current target NVE
     IP address. It may take some time to refresh the ARP/ND cache when
     a VM has moved to a New NVE.  During this period, a tunnel is
     needed for that Old NVE to forward packets destined to the VM
     under the New NVE.

MB> How does the old VM know which tunnel to use?

[...]

Reverse ARP (RARP) which enables the host to discover its IPv4
     address when it boots from a local server [RFC0903], is not used
     by VMs because the VM already knows its IPv4 address. Next, we
     describe a case where RARP is used.

MB> Please clarify. First you say RARP is not used, but then you say it is. Perhaps it is just the was this paragraph is phrased.

4.2. Task Migration in Layer-3 Network

     Layer-2 based DC networks become quickly prohibitive because
     ARP/neighbor caches don't scale.

MB> That is a very strong statement for a BCP. Perhaps you mean to say that ARP/neighbour cache scalability considerations can limit the size of Layer-2 based DC networks?

[...]

Cold task migration, which is a common practice in many data
     centers, involves the following steps:

     - Stop running the task.
     - Package the runtime state of the job.
     - Send the runtime state of the task to the new NVE where the
        task is to run.
     - Instantiate the task's state on the new machine.
     - Start the tasks   continuing it from the point at which it was
        stopped.


     Address migration and connection migration in moving tasks or VMs
     are addressed next.

MB> This last sentence seems redundant. I suggest removing it.

[...]

5. Handling Packets in Flight

     The Old NVE may receive packets from the VM's ongoing
     communications. These packets should not be lost; they should be
     sent to the New NVE to be delivered to the VM.  The steps involved
     in handling packets in flight are as follows:

     Preparation Step:  It takes some time, possibly a few seconds for
     a VM to move from its Old NVE to a New NVE. During this period, a
     tunnel needs to be established so that the Old NVE can forward
     packets to the New NVE. Old NVE gets New NVE address from NVA in
     the request to move the VM. The Old NVE can store the New NVE
     address for the VM with a timer. When the timer expired, the entry
     for the New NVE for the VM can be deleted.

MB> How does the old NVE know this? I assume the NVA pushes this to the old NVE, but it is not at all clear from the text. Please clarify.

[...]

6. Moving Local State of VM

MB> This whole section seems to be out of scope of the DC VPN network. Therefore, I would think it is out of scope of this draft and should be removed.

[...]
There is also a Hot Standby option in addition to the Hot
     Mobility, where there are VMs in both primary and secondary NVEs.

MB> This section title says Hot Mobility, but only talks about Hot Standby.

     They have identical information and can provide services
     simultaneously as in load-share mode of operation.  If the VM in
     the primary NVE fails, there is no need to actively move the VM to
     the secondary NVE because the VM in the secondary NVE already
     contains identical information.  The Hot Standby option is the
     costliest mechanism, and hence this option is utilized only for
     mission-critical applications and services.  In Hot Standby
     option, regarding TCP connections, one option is to start with and
     maintain TCP connections to two different VMs at the same time.
     The least loaded VM responds first and starts providing service
     while the sender (origin) still continues to receive Ack from the
     heavily loaded (secondary) VM and chooses not to use the service
     of the secondary responding VM.  If the situation (loading
     condition of the primary responding VM) changes the secondary VM
     may start providing service to the sender (origin).

[...]

8. VM Operation
     Once a VM moves to a new NVE, the VM's IP address does not change
     and the VM should be able to continue to receive packets to its
     address(es).

MB> How does that work for the hot standby case? Do you swap the old/new VM IP addresses?