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

[Anoop Ghanwani <[e-mail]>]

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
>