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

Hi Éric,

Thanks for your response. We have addressed your other comments to provide better clarity as suggested. Please see our responses with proposed text below. We will publish the revised document as soon as we close with the reviewers.

Thanks,
Ilango

== 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>  We will revise the note in the illustrations in Sections 3.1 and 3.2 that preamble and SFD are not included as follows.

        “(Note that the original Ethernet frame's preamble, start frame delimiter (SFD) and frame check sequence (FCS)are not included)”

          </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 will revise the following text in Section 1 as suggested to present this list as non-exhaustive.

        “The large number of protocols in this space, for example, ranging all the way from

   VLANs [IEEE.802.1Q_2014<https://tools.ietf.org/html/draft-ietf-nvo3-geneve-14#ref-IEEE.802.1Q_2014>] and MPLS [RFC3031<https://tools.ietf.org/html/rfc3031>] through the more recent

   VXLAN [RFC7348<https://tools.ietf.org/html/rfc7348>] (Virtual eXtensible Local Area Network) and NVGRE

   [RFC7637<https://tools.ietf.org/html/rfc7637>] (Network Virtualization Using Generic Routing

   Encapsulation), often leads to questions about the need for new

   encapsulation formats and what it is about network virtualization in

   particular that leads to their proliferation. Note that the list of protocols presented above 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> We will revise the following text in Section 1 as suggested.

        “However, one additional defining requirement is the

        need to carry metadata (e.g. system state) along with the packet data; example use cases of metadata are noted below.

        The use of some metadata is certainly …”

</Response>

From: Eric Vyncke (evyncke) <evyncke@cisco.com>
Sent: Tuesday, February 11, 2020 2:51 PM
To: Ganga, Ilango S <ilango.s.ganga@intel.com>; The IESG <iesg@ietf.org>
Cc: matthew.bocci@nokia.com; draft-ietf-nvo3-geneve@ietf.org; nvo3@ietf.org; nvo3-chairs@ietf.org
Subject: Re: [nvo3] Éric Vyncke's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)

Ilango

Sorry for belated reply, it seems that your email was lost somewhere in my mailbox.

I will clear my DISCUSS about RFC 8200 as soon as the revised ID is published and incorporate the RFC 8200. BTW, two months later, I would have expected to have the revised I-D published.

It seems by your reply that you prefer to ignore my non-blocking COMMENTs whose only goals were to improve the text. Up to the authors of course.

Regards and thank you again for the work done in this document.

-éric

From: "Ganga, Ilango S" <ilango.s.ganga@intel.com<mailto:ilango.s.ganga@intel.com>>
Date: Thursday, 5 December 2019 at 04:25
To: Eric Vyncke <evyncke@cisco.com<mailto:evyncke@cisco.com>>, The IESG <iesg@ietf.org<mailto:iesg@ietf.org>>
Cc: "matthew.bocci@nokia.com<mailto:matthew.bocci@nokia.com>" <matthew.bocci@nokia.com<mailto:matthew.bocci@nokia.com>>, "draft-ietf-nvo3-geneve@ietf.org<mailto:draft-ietf-nvo3-geneve@ietf.org>" <draft-ietf-nvo3-geneve@ietf.org<mailto:draft-ietf-nvo3-geneve@ietf.org>>, "nvo3@ietf.org<mailto:nvo3@ietf.org>" <nvo3@ietf.org<mailto:nvo3@ietf.org>>, "nvo3-chairs@ietf.org<mailto:nvo3-chairs@ietf.org>" <nvo3-chairs@ietf.org<mailto:nvo3-chairs@ietf.org>>
Subject: 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<mailto: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<mailto:iesg@ietf.org>>
Cc: matthew.bocci@nokia.com<mailto:matthew.bocci@nokia.com>; draft-ietf-nvo3-geneve@ietf.org<mailto:draft-ietf-nvo3-geneve@ietf.org>; nvo3@ietf.org<mailto:nvo3@ietf.org>; nvo3-chairs@ietf.org<mailto: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