Hello Éric,
Thanks for your review and comments. Please see below for our responses in-line, enclosed within <Response> </Response>. Let us know if you are satisfied with this resolution. Regards, Ilango Ganga Geneve Editor -----Original Message----- From: nvo3 <[email protected]> On Behalf Of Éric Vyncke via Datatracker Sent: Wednesday, December 4, 2019 10:04 AM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected] Subject: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-nvo3-geneve-14: Discuss ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- 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 ;-) IG> <Response> Yes, this is identified as a nit in Sheperd’s writeup to be fixed during the publication process. We will update the reference to RFC 8200. </Response> ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- == 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) IG> <Response> Illustrations in sections 3.1 and 3.2 show that the Ethernet payload does not include the preamble/start frame delimiter. We don’t believe there is any ambiguity so we don’t need to have explicit text to mention this information. </Response> Is a length of 24 bits for the VNI be enough? IG> <Response> This was discussed in the WG. The NVO3 design team constituted by the WG Chairs/AD discussed this item and considered whether a 24-bit vs larger VNI and finally made a recommendation to keep the VNI to 24-bit. This is documented in sections 6.9 and 7 of draft-dt-nvo3-encap-01 </Response> -- 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. IG> <Response> We believe you are referring to the following text: "The large number of protocols in this space, ranging all the way from VLANs [IEEE.802.1Q_2014] and MPLS [RFC3031] through the more recent VXLAN [RFC7348] (Virtual eXtensible Local Area Network) and NVGRE [RFC7637] (Network Virtualization Using Generic Routing Encapsulation)..." The above text does not imply an exhaustive list of protocols, but examples to illustrate a range of protocols. We don’t believe additional clarification is needed to say it is non-exhaustive. </Response> 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) IG> <Response> Example uses of metadata is described in the last sentence of this paragraph. </Response> -- 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. IG> <Response> The tunnel end point function does not fragment the packet, the tenant system does the fragmentation or limit the MTU size to avoid fragmentation. </Response> _______________________________________________ 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
