Subject: [nvo3] Éric Vyncke's No Objection on draft-ietf-nvo3-geneve-15: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Sat, 29 Feb 2020 23:27:09 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-nvo3-geneve-15: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for version -15 that addresses my DISCUSS and most of my COMMENTs.
They are kept below for history

---- Original DISCUSS and COMMENTs ---
Thank you for the work put into this document. It solves an interesting problem
and the document is easy to read.

I have one DISCUSS that is **trivial to fix** and some COMMENTs, feel free to
ignore my COMMENTs even if  I would appreciate your answers to those COMMENTs.

Regards,

-éric

== DISCUSS ==

-- Section 3.3 --
Please use RFC 8200 the 'new' IPv6 standard rather than RFC 2460 ;-)

== COMMENTS ==

-- Generic --
Is it worth mentioning that when transporting an Ethernet frame neither the
preamble nor the inter-frame gap are included? (AFAIR, IEEE considers those
parts as integral part of the IEEE 802.3 frame)

Is a length of 24 bits for the VNI be enough?

-- Section 1 --
In the list of protocols, rather than presenting the current list as
comprehensive, I would suggest to clearly present this list as non-exhaustive.

Is it worth to mention the reasoning behind "one additional defining
requirement is the need to carry system state along with the packet data"
(beside common sense)

-- Section 4.4.1 --
It is unclear to me whether Geneve endpoints can fragment the Geneve
UDP-encapsulated packet itself as the transit routers see only unfragmentable
packets.