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

[Donald Eastlake <[e-mail]>]

Hi Anoop,

Thanks for the additional suggestions. I'll update the draft accordingly.

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


On Thu, Jul 29, 2021 at 3:49 AM Anoop Ghanwani <[e-mail]>
wrote:

> Hi Donald,
>
> For an EVPN reference, RFC 8365 which deals with EVPN VXLAN may be better
> than RFC 7432.
>
> The current version of the INT spec is available at p4.org
> https://p4.org/p4-spec/docs/INT_v2_1.pdf
> Section 5.7 talks about how to carry INT headers of VXLAN GPE and Geneve.
>
> The other responses look good to me.
>
> Thanks,
> Anoop
>
> On Wed, Jul 28, 2021 at 9:16 PM Donald Eastlake <[e-mail]> wrote:
>
>> 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
>>
>