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

> 
> On Aug 25, 2021, at 11:55 AM, Michael Richardson via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Michael Richardson
> Review result: Not Ready
> 
> To: rtg-ads@ietf.org
> Cc: rtg-dir@ietf.org, draft-ietf-nvo3-encap.all@datatracker.ietf.org
> 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.
> 
> This document is the result of a chair-mandate design team to look at
> converging [RFC8926] Genevek, [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.
> 
> 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.
> 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 have a deep understanding of all three, so some
> constrasting pictures would be helpful.
> 
> The two major issues with GENEVE (can be longer than 256 bytes, has a hard to
> parse in hardware TLV structure) are identified.

That was somewhat intentional.

My understanding as a co-author of previous versions of GENEVE (prior to WG adoption) was that we didn’t need or even want to make this easier on HW. 

The idea was this would terminate at the server in SW. Not to a shared upstream HW device. 

So the difficulty of parsing in HW wasn’t seen as an issue. If anything it was seen as a feature.

>  But the document seems to
> conclude on GENEVE, without explaining why those major issues are not issues,
> or how they would be mitigated.
> 
> Minor Issues:
> 
> No minor issues found.
> 
> Nits:
> 
> I did not review for nits.
> 
> 
> 
> _______________________________________________
> nvo3 mailing list
> nvo3@ietf.org
> https://www.ietf.org/mailman/listinfo/nvo3