Re: [nvo3] Éric Vyncke's Abstain on draft-ietf-nvo3-encap-11: (with COMMENT)

[Donald Eastlake <[e-mail]>]

Hi Éric,

On Wed, Feb 14, 2024 at 10:45 AM Éric Vyncke via Datatracker
<[e-mail]> wrote:
>
> Éric Vyncke has entered the following ballot position for
> draft-ietf-nvo3-encap-11: Abstain
>
> ...
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> # Éric Vyncke, INT AD, comments for draft-ietf-nvo3-encap-11
>
> Thank you for the work put into this document.
>
> I am balloting an ABSTAIN because this document sits between two chairs (French
> saying). It is:
>
> - either the sheer output of the design team, then it has no WG/IETF consensus,
> meaning it must be an independent submission - or the output of the NVO3 WG,
> meaning that it cannot really speak only about the design team (there are 16
> occurrences of "DT" in the draft and I did not count "design team").

Although this document started from DT output, it was processed
through the WG and I will re-word it appropriately to so indicate.

> See also my COMMENT about section 7 about the differences with
> draft-dt-nvo3-encap-01 as recommendations have been added to the DT's ones.

I believe this supports my point that this is not just DT output.

> It would have been more useful to focus only on section 6, which is indeed an
> interesting read. Thank you that section.
>
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
>
> Special thanks to Matthew Bocci for the shepherd's detailed write-up including
> the WG consensus *and* the justification of the intended status even if it
> lacks the justification for the *publication stream*.
>
> Please note that Wassim Haddad is the Internet directorate reviewer (at my
> request) and you may want to consider this int-dir review as well when it will
> be available (no need to wait for it though):
> https://datatracker.ietf.org/doc/draft-ietf-nvo3-encap/reviewrequest/18840/

I have responded to Wassim's review.

> I hope that this review helps to improve the document and/or change its stream,
>
> Regards,
>
> -éric
>
> # COMMENTS (non-blocking)
>
> ## Section 5.2
>
> `similar to those noted for Geneve above` would benefit of further explanation
> as the 'main' issue for Geneve is TLV encoding and this is not the case for
> GUE, or are the GUE extensions also TLV encoded ? Then this may be worth
> explaining.

OK.

> ## Section 6.1
>
> Please explain why the absence of a Length field is important as it can
> (probably) be computed from the header (counting TLV, ...)

The draft does not actually say this is important. A length field
enables a consistency check and provides a way to easily skip the
encapsulation header.

> ## Section 6.2
>
> `Non-vendor specific TLVs` does it apply to all encapsulations or only to
> Geneve ?

All extensible encapsulations. It should perhaps say "non-vendor
specific extensions' '. But the desirability of variable lengths
argues in favor of TLVs/

> ## Section 6.5
>
> Unsure what is meant by `The order of the extension headers should be hardware
> friendly` ? I.e., how can a designer check whether an order is HW friendly?

I believe the text gives the example of certain header extensions
appearing early in the header sequence. Since this might depend on the
specific target NVE or transit devices, I think the point is that the
ordering of extensions should be dynamically determined.

> ## Section 7
>
> There are many additional recommendations that are *not* part of the original
> DT recommendations draft-dt-nvo3-encap-01. I.e., this seems more like a WG
> considerations rather than a design team considerations.

OK. The document will be appropriately re-worded as it is WG output.

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