Subject: [nvo3] WG Last Call for draft-ietf-nvo3-hpvr2nve-cp-req-10

From: "Bocci, Matthew (Nokia - GB)" <[email-masked]>
Date: Wed, 6 Dec 2017 14:32:41 +0000

This email begins a two-week working group last call for draft-ietf-nvo3-hpvr2nve-cp-req-10draft-ietf-nvo3-hpvr2nve-cp-req-10.txt.

Please review the draft and post any comments to the NVO3 working group list.

If you have read the latest version of the draft but have no comments and believe it is ready for publication as an Informational RFC, please also indicate so to the WG email list.

This working group last call will close on Wednesday 20th December 2017.

Best regards

Matthew and Sam

---

From: Liyizhou <[email-masked]>
Date: Mon, 11 Dec 2017 01:58:56 +0000

As a co-author, I believe it is ready for publication as an Informational RFC.

Thanks,
Yizhou

From: nvo3 [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Wednesday, December 06, 2017 10:33 PM
To: NVO3 <[email-masked]>
Subject: [nvo3] WG Last Call for draft-ietf-nvo3-hpvr2nve-cp-req-10

Best regards

Matthew and Sam

---

From: Linda Dunbar <[email-masked]>
Date: Mon, 11 Dec 2017 15:59:58 +0000

I support moving this draft to IESG.

Linda Dunbar

From: nvo3 [mailto:[email-masked]] On Behalf Of Bocci, Matthew (Nokia - GB)
Sent: Wednesday, December 06, 2017 10:33 PM
To: NVO3 <[email-masked]<mailto:[email-masked]>>
Subject: [nvo3] WG Last Call for draft-ietf-nvo3-hpvr2nve-cp-req-10

Best regards

Matthew and Sam

---

From: <[email-masked]>
Date: Tue, 12 Dec 2017 14:28:12 +0800 (CST)

Yes， I support this draft.

BR.

Ting Ao

原始邮件

发件人： <[email-masked]>;
收件人： <[email-masked]>;
日 期 ：2017年12月06日 22:33
主 题 ：[nvo3] WG Last Call for draft-ietf-nvo3-hpvr2nve-cp-req-10

_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

 

 

 

 

Best regards

Matthew and Sam

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 12 Dec 2017 05:34:40 -0500

The draft looks good to me.

A few nits:

   1.  Introduction

   Then the high level requirements to be fulfilled are satisfied.

I think s/satisfied/stated/ is intended here.

   1.1  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

RFC 2119 has been updated by RFC 8174 and the newer version should be
used.

   Hypervisor/Container: the logical collection of software, firmware
   and/or hardware that allows the creation and running of server or
   service appliance virtualization. tNVE is located on
   Hypervisor/Container. It is loosely used in this document to refer to
   the end device supporting the virtualization. For simplicity, we also
   use Hypervisor in this document to represent both hypervisor and
   container.

I think this would be clearer if the term you intend to use (hypervisor)
was indexed and described as such.  You could also index "container" or
"hypervisor/container" and point it to "hypervisor".  (Better would be
to use a generic word throughout and not overload a term which also has
a use of much narrower scope, but it's late to make that change.  The
use of "tenant system" is a good example of this style, as it doesn't
carry much baggage about what *type* of tenant it is.  OTOH, "tenant
system" isn't used consistently in the document.)

   1.2  Target Scenarios

   This implies that if a
   given TSI disassociates from one VN, all the MAC and/or IP addresses
   are also disassociated.  There is no need to signal the deletion of
   every MAC or IP when the TSI is brought down or deleted.

This sentence is very detailed for the context in which it appears.  To
me, it reads more as a requirement (about the dissociation action) than
part of the introduction.  And I don't see (on one reading) a clear
statement of this property among the listed requirements.  Then again,
is this intended as a firm requirement?

   2.2 VM Live Migration Event

If we've intiated a migration from hypervisor 1 to hypervisor 2, before
it is finished, can we initiate a migration from hypervisor 2 to
hypervisor 3?  That is, does the CP have to support chained
migrations-in-progress?

   2.4 VM Pause, Suspension and Resumption Events

   The VM pause event leads to the VM transiting from Running state to
   Paused state. The Paused state indicates that the VM is resident in
   memory but no longer scheduled to execute by the hypervisor [I-
   D.ietf-opsawg-vmm-mib]. The VM can be easily re-activated from Paused
   state to Running state. 

   The VM suspension event leads to the VM transiting from Running state
   to Suspended state. The VM resumption event leads to the VM
   transiting state from Suspended state to Running state. Suspended
   state means the memory and CPU execution state of the virtual machine
   are saved to persistent store.  During this state, the virtual
   machine is not scheduled to execute by the hypervisor [I-D.ietf-
   opsawg-vmm-mib]. 

>From the split-NVe point of view, is there any difference between Paused
and Suspended?

   5. VDP Applicability and Enhancement Needs

   +------+-----------+-----------------------------------------------+
   | Req  | VDP       |   remarks                                     |
   |      | supported?|                                               |
   +------+-----------+-----------------------------------------------+

I think "VDP supported?" would be clearer as "Supported by VDP?".  As
written now, it means "Does this requirement support VDP?".  But my
suggested wording won't fit well into this format.  Perhaps "VDP
supports?" would work.

Dale

---

From: Liyizhou <[email-masked]>
Date: Tue, 12 Dec 2017 12:05:06 +0000

Hi Dale,

Thank you so much for your review and comments. Please see inlines with [yz].

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: Tuesday, December 12, 2017 6:35 PM
To: [email-masked]
Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-hpvr2nve-cp-req-10

A few nits:

   1.  Introduction

[yz] Yes. Will update as suggested.

   1.1  Terminology

RFC 2119 has been updated by RFC 8174 and the newer version should be used.

[yz] Yes. Will update as suggested.

I think this would be clearer if the term you intend to use (hypervisor) was indexed and described as such.  You could also index "container" or "hypervisor/container" and point it to "hypervisor".  (Better would be to use a generic word throughout and not overload a term which also has a use of much narrower scope, but it's late to make that change.  The use of "tenant system" is a good example of this style, as it doesn't carry much baggage about what *type* of tenant it is.  OTOH, "tenant system" isn't used consistently in the document.)

[yz] That makes sense to me. I will change the text to 
Hypervisor: the logical collection of software, firmware  and/or hardware that allows the creation and running of server or  service appliance virtualization. tNVE is located on Hypervisor. It is loosely used in this document to refer to the end device supporting the virtualization. For simplicity, we also use Hypervisor in this document to represent both hypervisor and container.

Container: Please refer to Hypervisor. This document use hypervisors to represent both hypervisor and container for simplicity. 
[/yz]

   1.2  Target Scenarios

   This implies that if a

This sentence is very detailed for the context in which it appears.  To me, it reads more as a requirement (about the dissociation action) than part of the introduction.  And I don't see (on one reading) a clear statement of this property among the listed requirements.  Then again, is this intended as a firm requirement?

[yz] It tries to explain the implication of the potential complex address hierarchy used by a Tenant System. The requirement-8 tries to cover it. To make it clearer, I propose to change "address(es)" to "some or all address(es)" as follows.

Req-8: The protocol MUST allow an End Device initiating a request to associate/disassociate and/or activate/deactive address(es) of a TSI instance to a VN on an NVE port.
=>
Req-8: The protocol MUST allow an End Device initiating a request to associate/disassociate and/or activate/deactive some or all address(es) of a TSI instance to a VN on an NVE port.
                                                                                                                                                                                                                                             ^^^^^^^^^^^^^^^^^^
Req-9 should be modified in the same way as it talks about the message triggered from the other direction. 

 [/yz]

If we've intiated a migration from hypervisor 1 to hypervisor 2, before it is finished, can we initiate a migration from hypervisor 2 to hypervisor 3?  That is, does the CP have to support chained migrations-in-progress?
[yz] I guess the tricky point is how the VM migration is supposed to react in this case. Will it be something like "abort and revert 1st migration and jump to the migration to hypervisor 3" or "finish the first migration gracefully and perform the second one immediately"?
I do not think split-NVE control plane is necessarily to tell the difference or provide different functionalities for them. VM migration mechanism should take care of it.
[/yz]

and Suspended?

[yz] No difference. Sub-section 2.4 just tries to explain VM keeps in association state in case of VM Pause or Suspension.
It seems the information provided was a little bit overwhelming. I would like propose to change section 2.4 to:

The VM can be easily resumed and brought back to Running state after it is paused and suspended [I-D.ietf-opsawg-vmm-mib]. Therefore in the Split-NVE architecture, the external NVE keeps any paused or suspended VM in association as the VM can return to Running state at any time.
[/yz]

I think "VDP supported?" would be clearer as "Supported by VDP?".  As written now, it means "Does this requirement support VDP?".  But my suggested wording won't fit well into this format.  Perhaps "VDP supports?" would work.
[yz]  "Supported by VDP?" looks good to me :) I will use it unless someone figure out a better term.
Thanks,
Yizhou
[yz-end]

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 13 Dec 2017 21:58:53 -0500

Liyizhou <[email-masked]> writes:
>  I think this would be clearer if the term you intend to use
>  (hypervisor) was indexed and described as such.  You could also index
>  "container" or "hypervisor/container" and point it to "hypervisor".
>  (Better would be to use a generic word throughout and not overload a
>  term which also has a use of much narrower scope, but it's late to
>  make that change.  The use of "tenant system" is a good example of
>  this style, as it doesn't carry much baggage about what *type* of
>  tenant it is.  OTOH, "tenant system" isn't used consistently in the
>  document.)
>
> Hypervisor: the logical collection of software, firmware  and/or
> hardware that allows the creation and running of server or  service
> appliance virtualization. tNVE is located on Hypervisor. It is loosely
> used in this document to refer to the end device supporting the
> virtualization. For simplicity, we also use Hypervisor in this
> document to represent both hypervisor and container.

I would favor "supervisor" over "hypervisor".  "Hypervisor" has come to
have a specific meaning -- the control program of a virtual machine
system -- whereas "supervisor", which used to be equivalent to
"operating system", has more or less gone out of fashion.  So you can
use "supervisor" with fewer implications for the relationship between
the "supervisor" and the "tenant system".

Dale

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 18 Dec 2017 17:57:45 -0500

Hi Dale,

> the "supervisor" and the "tenant system".

I think we would like to stick with hypervisor. We do define it more
generally for this document. I think supervisor will confuse people as
so many tenant systems have a supervisor.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]