Hi Ilango, Your proposed text changes work for me. I will clear as soon as the new version hits.
Regards Suresh On Jan 15, 2020, at 6:19 PM, Ganga, Ilango S <[email protected]<mailto:[email protected]>> wrote: Hi Suresh, Thanks for your review of the document. Please see below for our responses inline, enclosed within <Response> </Response>. Let us know if you are satisfied with the resolution. Regards, Ilango Ganga Geneve Editor -----Original Message----- From: Suresh Krishnan via Datatracker <[email protected]<mailto:[email protected]>> Sent: Thursday, December 5, 2019 5:38 AM To: The IESG <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]>; Matthew Bocci <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]>; [email protected]<mailto:[email protected]> Subject: Suresh Krishnan's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT) Suresh Krishnan has entered the following ballot position for draft-ietf-nvo3-geneve-14: Discuss ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- * Section 3.3. This might be an easy DISCUSS to resolve. Since the specification requires the Destination port to be configurable, it is not clear to me how the "transit" devices will identify Geneve packets being sent to a non-default port (i.e. not 6081). Can you please clarify? IG>> <Response> This is the responsibility of the control plane. We will add the following sentence to section 3.3 (at the end of this paragraph) to provide better clarity: “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. It is the responsibility of the control plane for any reconfiguration of the assigned port and its interpretation by respective devices. The definition of the control plane is beyond the scope of this document.” </Response> ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I support Ben's DISCUSS position and I would like to ensure that the concerns brought up regarding transit devices and UDP zero checksums are resolved. I would also like to ensure that RFC8200 is used as the reference for the IPv6 protocol as stated in Eric's DISCUSS. IG>> <Response> Please see our response to Benjamin’s DISCUSS/comments (link below) https://mailarchive.ietf.org/arch/msg/nvo3/G37hH5brjYzYPQLHAfUr54_-Fwg We will replace RFC2460 to RFC8200 as noted in response to Eric’s DISCUSS. </Response> * Section 3.3 Have you considered the use of the flow label instead of source port for in the IPv6 tunnel case? I highly recommend looking at [RFC6438] for further details as it is specifically addresses ECMP for IP-in-IPv6 tunneled traffic. IG>> <Response> As we have seen, not all underlay networks support the use of flow label for ECMP purposes. However if an underlay IP network supports flow label for entropy, then this could be an additional method to provide entropy for networks that supports the mechanism outlined in RFC 6438. We can add an informative reference to RFC 6438 to section 3.3 as follows: “Since the port represents a flow identifier rather than a true UDP connection, the entire 16-bit range MAY be used to maximize entropy. In addition to setting the source port, for IPv6, flow label MAY also be used for providing entropy. For an example of using IPv6 flow label for tunnel use cases, see RFC6438.” </Response> <End of Responses>
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
