Subject: [nvo3] Opsdir telechat review of draft-ietf-nvo3-hpvr2nve-cp-req-15

From: Scott Bradner <[email-masked]>
Date: Sat, 17 Feb 2018 17:19:30 -0800

Reviewer: Scott Bradner
Review result: Has Nits

This is an OPD-DIR review of Split Network Virtualization Edge (Split-NVE)
Control Plane Requirements (draft-ietf-nvo3-hpvr2nve-cp-req-15) This ID
describes the requirements that should be met by the technology defined in one
or more technical specifications to implement, in this case, control plane
protocols for use in a split network virtualization system, and thus, by
definition, can not have any direct impacts on the operation of networks. 
Technology specification(s) that meet these requirements might have such
impacts. That said, some notes ---- section 1 .1 says 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] and RFC 8174 [RFC8174].

but RFC 8174 says the text should read as follows if the authors are following
the guidance in RFC 8147

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when,
and only when, they appear in all capitals, as shown here.

if the authors are not following that guidance  I would think that the original
RFC 2119 wording should be used

----
the 3rd pp of section 2.2 says "
The migrating VM should not be in Running state at the same time on the source
hypervisor and destination hypervisor during migration

the pp goes on to say that it could happen

I may be missing something but this puzzles me a bit - I would think that the
state of the results of the operation of the VM (e.g. database updates) would
be indeterminable if both VMs are running at the same time without some sort of
lockout -maybe this should be MUST NOT?

 ----
the 4th pp in section 3.1 states that "the external NVE MUST be notified ...
when it no longer requires connection" - what happens if the software on the
device needing the connection hangs - how is the notification done?

---
section 3 of the ID contains some things that appear to be requirements (i.e.,
include MUST etc) and some things that appear to be descriptive - without
calling out the actual requirements as is done in section 4 it will be hard for
the technology specification developers to know what requirements they need to
meet -if section 4 is a comprehensive list of requirements then it would seem
to be a good idea to avoid 2119 type capitalization in section 3 - if not I
would expect missed requiements

---

From: "Black, David" <[email-masked]>
Date: Mon, 19 Feb 2018 15:20:36 +0000

Scott,

Thanks for the review ... comments inline.

Thanks, --David

> -----Original Message-----
> From: Scott Bradner [mailto:[email-masked]]
> Sent: Saturday, February 17, 2018 8:20 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; draft-ietf-nvo3-hpvr2nve-cp-
> [email-masked]
> Subject: Opsdir telechat review of draft-ietf-nvo3-hpvr2nve-cp-req-15
> 
> Reviewer: Scott Bradner
> Review result: Has Nits
> 
> This is an OPS-DIR review of Split Network Virtualization Edge (Split-NVE)
> the guidance in RFC 8174

The intent is to follow RFC 8174, where only upper case denotes an actual requirement,
in part because this document is providing requirements input to IEEE 802.

> the pp goes on to say that it could happen

Not exactly ... Migration state occurs between the Running and Shutdown states
in both directions as described in the first paragraph of that section:

   The VM state on source hypervisor 1
   transits from Running to Migrating and then to Shutdown [RFC7666].
   The VM state on destination hypervisor 2 transits from Shutdown to
   Migrating and then Running.
 
> lockout -maybe this should be MUST NOT?

In practice, there is a lockout, but it only involves the hypervisors.  Both VMs are
in Migrating state during the transfer of execution from one host to another.
One of the benefits of this is that it reduces the number of entities that have to
participate in the transfer of control, as the states visible through the interface
change before and after transfer of execution, but not during that transfer.

Stating that both states are Migrating during transfer of execution could help
clarify this, and see below on removal of upper case RFC 2119 keywords from
all of section 3.
 
> device needing the connection hangs - how is the notification done?

Something else has to decide that the device is dead and take action - that's
outside the scope of the protocol described here because another entity is
involved.  A sentence to note this need to clean up failed devices would make
sense to add.

> would expect missed requiements

That sounds like the right approach, as the introductory text to Section 3
has this to say:

   The following subsections show illustrative examples of the state
   transitions of an external NVE which are relevant to Hypervisor-to-
   NVE Signaling protocol functionality. It should be noted this is not
   prescriptive text for the full state machine.

---

From: Scott Bradner <[email-masked]>
Date: Mon, 19 Feb 2018 13:28:28 -0500

> On Feb 19, 2018, at 10:20 AM, Black, David <[email-masked]> wrote:
> 
> Scott,
> 

OK - in that case the ID should use the 8147 wording
> all of section 3.\

ok

> involved.  A sentence to note this need to clean up failed devices would make

ok
>   prescriptive text for the full state machine.

ok

---

From: Liyizhou <[email-masked]>
Date: Thu, 22 Feb 2018 02:47:53 +0000

Scott and David,

Thanks for reviews and feedback. Sorry about the delayed response. I agree with your discussions and will update ID as follows.

1. Incorporate phrase from RFC8174 to section 1.1.
"The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here."

2. Remove upper case keywords from section 2 & 3 (occurrence: MUST*2, SHOULD NOT *1, SHOULD *1)

3. Add the following to the beginning of pp3 section 2.2.
 "The states of VM on the source and destination hypervisors both are Migrating during transfer of migration execution."  

4. Add the following as the 2nd sentence to pp4 section 3.1.
" Connection clean up for the failed devices should be employed which is out of the scope of the protocol specified in this document.

Rgds,
Yizhou

-----Original Message-----
From: Scott Bradner [mailto:[email-masked]] 
Sent: Tuesday, February 20, 2018 2:28 AM
To: Black, David <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Opsdir telechat review of draft-ietf-nvo3-hpvr2nve-cp-req-15

>> This is an OPS-DIR review of Split Network Virtualization Edge 
>> (Split-NVE) Control Plane Requirements 
>> (draft-ietf-nvo3-hpvr2nve-cp-req-15) This ID describes the 
>> requirements that should be met by the technology defined in one or 
>> more technical specifications to implement, in this case, control 
>> plane protocols for use in a split network virtualization system, and 
>> thus, by definition, can not have any direct impacts on the operation of networks.
>> Technology specification(s) that meet these requirements might have 
>> such impacts. That said, some notes ---- section 1 .1 says 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] and RFC 8174 [RFC8174].
>> 
>> but RFC 8174 says the text should read as follows if the authors are 
>> following the guidance in RFC 8174
>> 
>> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
>> "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
>> "OPTIONAL" in this document are to be interpreted as described in BCP 
>> 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
>> 
>> if the authors are not following that guidance  I would think that 
>> the original RFC 2119 wording should be used
> 
> The intent is to follow RFC 8174, where only upper case denotes an 
> actual requirement, in part because this document is providing requirements input to IEEE 802.

>> The migrating VM should not be in Running state at the same time on 
>> the source hypervisor and destination hypervisor during migration
>> 
> Not exactly ... Migration state occurs between the Running and 
> Shutdown states in both directions as described in the first paragraph of that section:
> 
>> I may be missing something but this puzzles me a bit - I would think 
>> that the state of the results of the operation of the VM (e.g. 
>> database updates) would be indeterminable if both VMs are running at 
>> the same time without some sort of lockout -maybe this should be MUST NOT?
> 
> In practice, there is a lockout, but it only involves the hypervisors.  
> Both VMs are in Migrating state during the transfer of execution from one host to another.
> One of the benefits of this is that it reduces the number of entities 
> that have to participate in the transfer of control, as the states 
> visible through the interface change before and after transfer of execution, but not during that transfer.
> 
> Stating that both states are Migrating during transfer of execution 
> could help clarify this, and see below on removal of upper case RFC 
> 2119 keywords from all of section 3.\

ok

>> when it no longer requires connection" - what happens if the software 
>> on the device needing the connection hangs - how is the notification done?
> 
> Something else has to decide that the device is dead and take action - 
> that's outside the scope of the protocol described here because 
> another entity is involved.  A sentence to note this need to clean up 
> failed devices would make sense to add.

ok
> 
>> ---
>> section 3 of the ID contains some things that appear to be 
>> requirements (i.e., include MUST etc) and some things that appear to 
>> be descriptive - without calling out the actual requirements as is 
>> done in section 4 it will be hard for the technology specification 
>> developers to know what requirements they need to meet -if section 4 
>> is a comprehensive list of requirements then it would seem to be a 
>> good idea to avoid 2119 type capitalization in section 3 - if not I 
> That sounds like the right approach, as the introductory text to 
> Section 3 has this to say:
> 

ok