Re: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)

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 <nvo3-bounces@ietf.org> On Behalf Of Éric Vyncke via Datatracker
Sent: Wednesday, December 4, 2019 10:04 AM
To: The IESG <iesg@ietf.org>
Cc: matthew.bocci@nokia.com; draft-ietf-nvo3-geneve@ietf.org; nvo3@ietf.org; nvo3-chairs@ietf.org
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

nvo3@ietf.org<mailto:nvo3@ietf.org>

https://www.ietf.org/mailman/listinfo/nvo3