Geneve: Generic Network Virtualization Encapsulation
draft-ietf-nvo3-geneve-16

Thank you for addressing my DISCUSS point.

I support Ben Kaduk’s DISCUSS position.  To reiterate part of his write-up, the role of the transit device which is only permitted to inspect the geneve traffic isn’t clear, especially if end-to-end security is applied.  RFC7365 didn’t provide insight into this architectural element.

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.

Thanks for the work that went into consolidating network tunneling protocols
into a single, unified design. I have one comment that I think is rather
important to Geneve's success.

In fact, I'm on the wall about whether this comment should be a DISCUSS, since
I think the current design will render Geneve broadly unusable in a number of
important use-cases.

>  Dest port:  IANA has assigned port 6081 as the fixed well-known
>     destination port for Geneve.  Although the well-known value should
>     be used by default, it is RECOMMENDED that implementations make
>     this configurable.  The chosen port is used for identification of
>     Geneve packets and MUST NOT be reversed for different ends of a
>     connection as is done with TCP.

This behavior -- using 6081 as the destination in both directions -- has the
unfortunate property of violating NAT and Firewall assumptions about the
nature of UDP traffic (see RFC 4748 for a discussion of UDP behavior in NATs).
For example, while RTP was originally specified to typically work in the way
described here (using two unrelated unidirectional flows when a bidirectional
flow was desired), all (or nearly all) modern implementations use a technique
known as "symmetric RTP" (see RFC 4961), which uses port numbers in the same
way as TCP does.

I can't find any discussion of NAT traversal in this document. One might
assume that such responsibility is delegated to the control plane, but it
should be noted that this specific requirement is going to frustrate every NAT
traversal technique that I'm aware of (save for the mostly undeployed NAT-PMP
and similar approaches), regardless of how well-designed the control plane is.

If the working group has already considered NAT/Firewall traversal and decided
to use the specified design anyway [1], please add text laying out the
rationale in this document. If this point has not yet been discussed, I urge
the working group to withdraw its request for publication and to carefully
reconsider the implications of this specific normative requirement.

(I take the point about the design being applicable to "controlled networks,"
but that doesn't necessarily imply the absence of a NAT or a non-NAT Firewall;
and, as Roman notes in his DISCUSS, the applicability statement appears to be
overstated anyway: if crossing public networks -- as this document clearly
anticipates -- using IPv4, the presence of a CG-NAT device will become
increasingly likely as time goes on.)

____
[1] I searched mailarchive.ietf.org and found no such discussion, but did
    not search meeting minutes

The Contact in Section 7 should be iesg@ietf.org, not chair@ietf.org. The chair email address is a spam magnet where things will get lost.

Version -15 addresses my DISCUSS and comments; thanks.

Thank you for addressing my Discuss points!

Thanks for addressing my issue.

Thanks for addressing my process discuss and also my comments!

One more comment on the port assignment though: I think it would be better to only list the new assignment information (and not have the old data written in stone in this RFC), e.g. like this:

   IANA has allocated UDP port 6081 in the Service Name and Transport Protocol 
   Port Number Registry [IANA-SN] as the well-known destination port
   for Geneve based on early registration.

   Upon publication of this document, this registration will have its
   reference changed to cite this document [RFC-to-be] and inline with
   [RFC6335] the Assignee and Contact of the port entry should be
   changed to IESG <iesg@ietf.org> and IETF Chair <chair@ietf.org>
   respectively:

   Service Name: geneve
   Transport Protocol(s): UDP
   Assignee: IESG <iesg@ietf.org> 
   Contact: IETF Chair <chair@ietf.org>
   Description: Generic Network Virtualization Encapsulation (Geneve)
   Reference: [RFC-to-be]
   Port Number: 6081

Thanks for addressing my DISCUSS and COMMENT points.