Re: [RTG-DIR] Rtgdir early review of draft-ietf-nvo3-encap-07

[Donald Eastlake <[e-mail]>]

Hi Michael,

On Wed, Aug 25, 2021 at 2:55 PM Michael Richardson via Datatracker
<[e-mail]> wrote:
> Reviewer: Michael Richardson
> Review result: Not Ready
>
> To: [e-mail]
> Cc: [e-mail], [e-mail]
> Subject: RtgDir review: draft-ietf-nvo3-encap-07
>
> Hello,
>
> I have been selected as the Routing Directorate reviewer for this draft. The
> Routing Directorate seeks to review all routing or routing-related drafts as
> they pass through IETF last call and IESG review, and sometimes on special
> request. The purpose of the review is to provide assistance to the Routing
> ADs. For more information about the Routing Directorate, please see
> http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>
> Although these comments are primarily for the use of the Routing ADs, it
> would be helpful if you could consider them along with any other IETF Last
> Call comments that you receive, and strive to resolve them through discussion
> or by updating the draft.
>
> Document: draft-ietf-nvo3-encap-07
> Reviewer: Michael Richardson
> Review Date: 2020-08-25
> IETF LC End Date: unknown
> Intended Status: Informational
>
> Summary:
>
> This document is NOT ready for publication.
> It is unclear that this document should ever be published as-is.
> I'm not sure why a review of it was asked for.

I was not involved in the decision, but I would imagine that a review
was asked for with a view to improving the draft.

> This document is the result of a chair-mandate design team to look at
> converging [RFC8926] Geneve, [I-D.ietf-intarea-gue] Generic UDP
> Encapsulation, and [I-D.ietf-nvo3-vxlan-gpe].
>
> This document might be appropriate an informative appendix to some protocol
> document that explained what encapsulation was to be used.  Or perhaps just
> as a record for future reference.  I don't see a reason to publish it as an RFC.

If it is reasonable for something to be retained as "a record for
future reference" then, in my opinion, it follows that it is a
plausible candidate for publication as an RFC, likely an Informational
RFC, which is the category shown on the title page of this draft.
Generally speaking, I think the IETF does a bad job of preserving the
basis for many of its decisions when it would be useful to do so. Not
only do I think the material in this draft, which could be improved,
should be published as an RFC, I think it would be reasonable for
there to be additional RFCs of this type.

> Comments:
>
> Please supply an overview of the draft quality and readability.
> Include anything else that you think will be helpful toward understanding your review.
>
> Major Issues:
>
> The document jumps right into comparing the three protocols.

Given that the purpose of the draft is to cover the comparison of the
protocols and selection of one, what sort of material do you think
should appear before the comparisons?

> The deficiencies of each protocol are very briefly noted.
> No diagrams or extracts of the relevant protocols are included to help a
> reader understand the deficiencies.
>
> Few readers are likely to have a deep understanding of all three, so some
> contrasting pictures would be helpful.

Some such diagrams could be added.

> The two major issues with GENEVE (can be longer than 256 bytes, has a hard to
> parse in hardware TLV structure) are identified.  But the document seems to
> conclude on GENEVE, without explaining why those major issues are not issues,
> or how they would be mitigated.

Jon Hudson responded to this point and something along the lines of
his answer could be incorporated into the draft.

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

> Minor Issues:
>
> No minor issues found.
>
> Nits:
>
> I did not review for nits.