Hello Adam,
Thanks for your review and comments. Please see below for our responses inline, enclosed within <Response> </Response>. Let us know if you are fine with this resolution. Regards, Ilango Ganga Geneve Editor -----Original Message----- From: nvo3 <[email protected]> On Behalf Of Adam Roach via Datatracker Sent: Wednesday, December 4, 2019 9:45 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [nvo3] Adam Roach's No Objection on draft-ietf-nvo3-geneve-14: (with COMMENT) Adam Roach has entered the following ballot position for draft-ietf-nvo3-geneve-14: No Objection ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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 IG>> <Response> Geneve is designed to provide Network virtualization overlays for use in data center environments. This is documented in Section 4.1 that Geneve is intended for use in controlled data center environments. This aligns with NVO3 charter that states, "The purpose of the NVO3 WG is to develop a set of protocols and/or protocol extensions that enable network virtualization within a data center (DC) environment that assumes an IP-based underlay." Also, usages like geographically separated data centers does not mean Geneve directly goes over the general internet, whereas Geneve traffic needs to be carried over other VPN technologies to bridge Geneve traffic across geographically separated data centers. Moreover, we have seen that network virtualization deployments within controlled data center environments do not use NAT on the underlay traffic. Also, other UDP tunneling protocols like GRE in UDP (RFC 8086), MPLS over UDP (RFC7510) use single UDP destination port to identify the protocol irrespective of the direction. If there is any ambiguity, we could even bring the message upfront on the use in data center environments, by updating the text at the beginning of Section 2 as noted below: "Geneve is designed to support network virtualization use cases for data center environments, where tunnels are typically established to act as a backplane between the virtual switches residing in hypervisors, physical switches, or middleboxes or other appliances." </Response> <End of Responses> _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
