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

[Linda Dunbar <[e-mail]>]

Matthew,

Thank you very much for the detailed comments. They are very helpful.
Inserted below are the detailed changes per your comments.

Can you let us know if they are acceptable?

Thank you.

Linda

From: Bocci, Matthew (Nokia - GB) <[e-mail]>
Sent: Wednesday, February 19, 2020 12:01 PM
To: [e-mail]
Cc: NVO3 <[e-mail]>
Subject: Shepherd's review of draft-ietf-nvo3-vmm-06

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.
[Linda] thank you. We are going through to add them.

Please expand the term ‘DC’ on first use.
[Linda] added.

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’ ?
[Linda]. Yes. Changed the sentence to “Virtual machine (VM) mobility should not require changing VMs’ IP addresses after the move.”

   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?

[Linda] Add the following sentences to the paragraph:
“Not all DCs support “Hot Migration. DCs that only support Cold Migration should make their customers aware of the potential service interruption during the Cold migration.”

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.
[Linda] Yes. Revised the sentence to the following:
“Therefore, dynamic VM Mobility is highly desirable for large scale multi-tenant DCs.”

[...]

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?
[Linda] the procedure is explained in the paragraph right following this sentence:
“In IPv4, the VM immediately after the move should send a gratuitous ARP request message containing its IPv4 and Layer 2 MAC address in its new NVE.  This message's destination address is the broadcast address.  Upon receiving this message, both Old and New NVEs should update the VM's ARP entry in the central directory at the NVA, to update its mappings to record the IPv4 address & MAC address of the moving VM along with the new NVE IPv4 address.  An NVE-to-NVA protocol is used for this purpose [RFC8014].”

[...]

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.
[Linda] Changed the sentence to the following:
“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 if the VM already knows its IPv4 address (most common scenario). Next, we describe a case where RARP is used.

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?
[Linda] That is correct. Changed to your suggested wording.

[...]

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.
[Linda] removed. Thanks.

[...]

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.
[Linda] “Old NVE gets New NVE address from NVA in the request to move the VM”. Not clear?


[...]

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.
[Linda] How about we remove the description for the detailed State Transferring. And states that it is out of the scope of this document?
6. Moving Local State of VM
In addition to the VM mobility related signaling (VM Mobility Registration Request/Reply), the VM state needs to be transferred to the New NVE.  The state includes its memory and file system if the VM cannot access the memory and the file system after moving to the New NVE.
The mechanism of transferring VM States and file system is out of the scope of this document.



[...]
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.
[Linda] Added a new subtitle “Other VM Mobility Options”

     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?
[Linda] moved the description of the behaviour on Hot VM Mobility to be under the Section 7 (Handling Hot, Warm and Cold VM Mobility). Changed the section title to “VM Lifecycle Management” (which is out of the scope of the document).