> On Feb 19, 2018, at 10:20 AM, Black, David <david.bl...@dell.com> wrote:
> Scott,
> Thanks for the review ... comments inline.
> Thanks, --David
>> -----Original Message-----
>> From: Scott Bradner [mailto:s...@sobco.com]
>> Sent: Saturday, February 17, 2018 8:20 PM
>> To: ops-...@ietf.org
>> Cc: nvo3@ietf.org; i...@ietf.org; draft-ietf-nvo3-hpvr2nve-cp-
>> req....@ietf.org
>> 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)
>> 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",
>> "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",
>> 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.

OK - in that case the ID should use the 8147 wording
>> ----
>> 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
> 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.
>> 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.\


>> ----
>> 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?
> 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.

>> ---
>> 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
> 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.


nvo3 mailing list

Reply via email to