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) <[email protected]>
Sent: Tuesday, February 11, 2020 2:51 PM
To: Ganga, Ilango S <[email protected]>; The IESG <[email protected]>
Cc: [email protected]; [email protected]; [email protected];
[email protected]
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"
<[email protected]<mailto:[email protected]>>
Date: Thursday, 5 December 2019 at 04:25
To: Eric Vyncke <[email protected]<mailto:[email protected]>>, The IESG
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
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 <[email protected]<mailto:[email protected]>> On Behalf Of
Éric Vyncke via Datatracker
Sent: Wednesday, December 4, 2019 10:04 AM
To: The IESG <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[email protected]>;
[email protected]<mailto:[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
