Re: [nvo3] Second Working Group Last call for draft-ietf-nvo3-encap

[Donald Eastlake <[e-mail]>]

Hi Anoop,

Thank you for your very detailed review. :-\

See my responses below where I didn't exactly agree with your
suggestion. If I don't respond to a point it means I think your
comment is a reasonable change.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]


On Tue, Jul 27, 2021 at 8:07 PM Anoop Ghanwani <[e-mail]>
wrote:
>
> I support publication of the document.  I have the following
> comments -- mostly editorial and around use of consistent
> terminology.
>
> ==
>
> Section 2
> - Expand first use of DT.

Instead replace "design team", which occurs earlier in Section 2, with
"design team (DT)".


> Section 6.2.1
>
> - "IP-address, or MAC-address" ->
>   IP addresses, and MAC addresses.
>
> - It would be good to include a reference to INT and/or IOAM, so
>   it's clear what is being discussed.
>
>
> Section 6.2.2
>
> - "in some NVO3 extension" ->
>    in an NVO3 extension
>
> - "This is nice" ->
>   This is desirable.
>
> - "we don't need a separate UDP" ->
>   we don't need a separate UDP port
>
>
> Section 6.2.3
>
> - (section header)
>   Group Base Policy ->
>   Group Based Policy
>
>
> Section 6.3
>
> - "NICs doing TCP offload" ->
>   NICs implementing various TCP offload mechanisms
>
>
> Section 6.4
>
> - "unnecessarily constrained" ->
>   unnecessarily constrain
>
> - design team -> DT
>
> - "total extension header length selected" ->
>   total extension header length specified
>
> - "Single Extension size" ->
>   The size of an extension header"
>
> - "The maximum length of a single option" ->
>   The maximum length of a single extension header
>
>
> Section 6.5
>
> (Several of the subsections use extension, extension header,
> option, and TLV interchangeably.  I have tried to use extension
> header in this section, but other sections also have similar
> issues.  Would recommend editor search doc for "extension" and
> "option" and "TLV" and make sure usage is correct/consistent.
> In some cases it makes sense to use TLV, but there is almost no
> case where "option" or "extension" makes sense over "extension
> header".)

I did some searching and replacing in the document but I probably
didn't change as many instances as you would have.

> - (section header)
>   Extension Ordering ->
>   Ordering of Extension Headers
>
> - "one or a few extensions TLVs"
>   a subset of the extension headers
>
> - "specific TLV" ->
>   specific extension header
>
> - "order of TLVs" ->
>   order of extension headers
>
> - "Transit devices doesn't" ->
>   Transit devices don't
>
> - "process the options" ->
>   process the extension headers
>
> - "they need to process only a small subset of options" ->
>   they may need to process only subset of extension headers
>
>
> Section 6.6
>
> - "bit-field approach" ->
>   bit fields approach
>
> - "and support in the control plane such that" ->
>   and support via the control plane a method such that
>
> - "they need more effort" ->
>   some other method must be used.
>
> - "In a Bit fields" ->
>   In a bit fields
>
> - "does a firewall" ->
>   implements a firewall
>
> - "that allows different software" ->
>   that allow different software modules
>
> - "to handle different options" ->
>   to process different options
>
>
> Section 6.7
>
> (Same issue with extension v extension headers.
> Also look for receiver v target v target NVE.
> Should we be using "egress NVE" per the framework?)

I changed occurrences of "target" to "target NVE".

> - "EVPN and others"
>   provide reference.

Added reference to RFC 7432.

> - "they only care" ->
>   it only cares
>
> - "only care about particular extensions"
>   only support certain extensions

The above two changes overlap resulting in
"it only supports certain extensions"

> - "requested extensions" ->
>   supported extensions
>
> - "cares about a few extensions" ->
>   "supports only certain extensions"
>
> - "with minimal hardware requirements" ->
>   with simplified hardware requirements
>   for the target NVE.
>
> - "Note that in this approach" ->
>   Note that with this approach
>
> - "enumerate the supported NVO3 extensions and their order" ->
>   indicated the supported NVO3 extensions and their order, for
>   each of encapsulations supported.
>
>
> Section 6.8
>
> - Add reference to RFC 8394.
>
> - "Ether type" -> EtherType
>
>
> Section 7
>
> - Add references to VXLAN and NVGRE docs.
>
> (Also doc uses VxLAN and VXLAN and VxLAN-GPE and VXLAN-GPE.
> Would recommend stick to VXLAN and VXLAN-GPE.  Check throughout.)
>
> - "lack of header length" ->
>   lack of a header length field
>
> - Another full doc check should be done for
>   bit-fields vs bit fields vs Bit-field vs Bit field vs Bit Field.
>   Recommend using "bit fields" everywhere.
>
> - "By using Geneve option" ->
>   By using Geneve options
>
> - Security extension TLVs ->
>   security extension TLVs
>
> - "There are implemented Geneve options today in production" ->
>   There are already implementations of Geneve options deployed in
>   production networks as of this writing.
>
> - Bullet 8 -- add reference to INT spec.

I'm not sure how to find such a reference.

> - "We recommend the following enhancements to Geneve to make it more
>    suitable to hardware and yet provide the flexibility for software:"
>   Indent and add quotations around following paragraph(s).

Indenting OK but I think quotes are overkill for a relatively large
amount of text like this.

> - "The Geneve draft could specify" ->
>   The Geneve draft should specify
>
>
> Appendix
>
> - Check terminology usage "tunnel endpoint" vs NVE/egress NVE.
>
>
> On Thu, Jul 1, 2021 at 8:09 AM Bocci, Matthew (Nokia - GB) <[e-mail]> wrote:
>>
>> This email begins a two-week working group last call for draft-ietf-nvo3-encap-06.
>>
>>
>>
>> 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.
>>
>>
>>
>> We are also polling for knowledge of any undisclosed IPR that applies to this document, to ensure that IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).
>>
>> If you are listed as an Author or a Contributor of this document, please respond to this email and indicate whether or not you are aware of any relevant undisclosed IPR. The Document won't progress without answers from all the Authors and Contributors.
>>
>>
>>
>> Currently there are no IPR disclosures against this document.
>>
>>
>>
>> If you are not listed as an Author or a Contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.
>>
>>
>>
>> As a reminder, we are pursuing publication of this document in order to permanently document the experience of one working group in choosing between multiple proposed standards track encapsulation drafts. The idea was that this would provide helpful guidance to others in the community going forward.
>>
>>
>>
>> This poll will run until Thursday 15th July 2021.
>>
>>
>>
>> Regards
>>
>>
>>
>> Matthew and Sam
>>
>>
>>
>> _______________________________________________
>> nvo3 mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/nvo3