> On Feb 19, 2018, at 10:20 AM, Black, David <David.Black@xxxxxxxx> wrote: > > Scott, > > Thanks for the review ... comments inline. > > Thanks, --David > >> -----Original Message----- >> From: Scott Bradner [mailto:sob@xxxxxxxxx] >> Sent: Saturday, February 17, 2018 8:20 PM >> To: ops-dir@xxxxxxxx >> Cc: nvo3@xxxxxxxx; ietf@xxxxxxxx; draft-ietf-nvo3-hpvr2nve-cp- >> req.all@xxxxxxxx >> 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", >> "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. 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.\ ok > >> ---- >> 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. 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 >> 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. ok >
