Geneve: Generic Network Virtualization Encapsulation
Note: This ballot was opened for revision 14 and is now closed.
Alvaro Retana Yes
Martin Vigoureux Yes
Deborah Brungard No Objection
Alissa Cooper (was Discuss) No Objection
The Contact in Section 7 should be email@example.com, not firstname.lastname@example.org. The chair email address is a spam magnet where things will get lost.
Roman Danyliw (was Discuss) No Objection
Comment (2020-03-03 for -15)
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.
Benjamin Kaduk (was Discuss) No Objection
Thank you for addressing my Discuss points!
(Suresh Krishnan) (was Discuss) No Objection
Comment (2020-03-01 for -15)
Thanks for addressing my DISCUSS and COMMENT points.
Warren Kumari No Objection
(Mirja Kühlewind) (was Discuss) No Objection
Comment (2020-03-04 for -15)
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 <email@example.com> and IETF Chair <firstname.lastname@example.org> respectively: Service Name: geneve Transport Protocol(s): UDP Assignee: IESG <email@example.com> Contact: IETF Chair <firstname.lastname@example.org> Description: Generic Network Virtualization Encapsulation (Geneve) Reference: [RFC-to-be] Port Number: 6081
Barry Leiba (was Discuss) No Objection
Comment (2020-03-01 for -15)
Version -15 addresses my DISCUSS and comments; thanks.
(Adam Roach) No Objection
Comment (2019-12-04 for -14)
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 , 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.) ____  I searched mailarchive.ietf.org and found no such discussion, but did not search meeting minutes
Éric Vyncke (was Discuss) No Objection
Comment (2020-02-29 for -15)
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.
Magnus Westerlund (was Discuss) No Objection
Comment (2020-03-02 for -15)
Thanks for addressing my issue.