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

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Wed, 04 Dec 2019 10:04:01 -0800

Éric Vyncke has entered the following ballot position for
draft-ietf-nvo3-geneve-14: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nvo3-geneve/

----------------------------------------------------------------------
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 ;-)

----------------------------------------------------------------------
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)

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.

---

From: "Ganga, Ilango S" <[email-masked]>
Date: Thu, 5 Dec 2019 08:25:28 +0000

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-masked]> On Behalf Of Éric Vyncke via Datatracker
Sent: Wednesday, December 4, 2019 10:04 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)

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 --

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>

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-masked]<mailto:[email-masked]>

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