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

[Barry Leiba <[e-mail]>]

Hi, Ilango , and thanks for your response.  We're all good here, and
I'll clear the DISCUSS when I see the updated reference.

Barry

On Wed, Jan 15, 2020 at 12:16 AM Ganga, Ilango S
<[e-mail]> wrote:
>
> Hello Barry,
>
>
>
> Thanks for your review of the document. Please see our responses to your comments, inline below enclosed within <Response> </Response>.  Let us know if you are satisfied with the resolution.
>
>
>
> Regards,
>
> Ilango Ganga
>
> Geneve Editor
>
>
>
> -----Original Message-----
> From: Barry Leiba via Datatracker <[e-mail]>
> Sent: Wednesday, December 4, 2019 7:24 PM
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Matthew Bocci <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
> Subject: Barry Leiba's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)
>
>
>
> Barry Leiba has entered the following ballot position for
>
> draft-ietf-nvo3-geneve-14: Discuss
>
> ----------------------------------------------------------------------
>
> DISCUSS:
>
> ----------------------------------------------------------------------
>
>
>
> This will be trivial to address:
>
>
>
> — Section 1.2 —
>
>
>
>    The NVO3 framework [RFC7365] defines many of the concepts commonly
>
>    used in network virtualization.
>
>
>
> Indeed, and it seems a critical normative reference here.  So why is it in the informative section?
>
>
>
> IG>> <Response>. Agreed, we will move [RFC7365] to normative references section.
>
> </Response>
>
>
>
> ----------------------------------------------------------------------
>
> COMMENT:
>
> ----------------------------------------------------------------------
>
>
>
> I support Ben’s DISCUSS and comments.  In addition:
>
>
>
> IG>> <Response>
>
> Please see our Response to Benjamin’s DISCUSS/comments (links below):
>
> https://mailarchive.ietf.org/arch/msg/nvo3/G37hH5brjYzYPQLHAfUr54_-Fwg
>
> https://mailarchive.ietf.org/arch/msg/nvo3/Pt3TAucyhmeD9DGUvgcURme4zGs
>
> </Response>
>
>
>
>
>
> — Section 3.3 —
>
> In the description of the UDP Checksum, the first paragraph says the checksum MUST be set for v6, then the second paragraph contradicts that.  You really should note when the MUST is specified that there are exceptions.
>
>
>
> IG>> <Response> For IPv6, Section 3.3 says, UDP checksum MUST be generated by “default”, which implies that there are exceptions. We will add the following sentence to refer to the exception mentioned in the second paragraph for better clarity:
>
>
>
> “To protect the IP header, Geneve header,
>
>       options and payload from potential data corruption, the UDP
>
>       checksum MUST be generated by default as specified in [RFC0768]
>
>       and [RFC2460] when Geneve is encapsulated in IPv6, except for certain conditions outlined in the next paragraph.”
>
> </Response>
>
>
>
>
>
> — Section 3.5 —
>
> In the description of the Type field, I believe it confuses things to say that it’s 8 bits, and then to say that the first bit is not really part of the type, but has a special meaning.  Why do you not show the C bit and Type field in the main diagram as it is shown in the mini-figure, describe the C bit separately, and define the Type field as 7 bits?
>
>
>
> IG>> <Response> The high order bit indicating critical options is an integral part of the type field. Basically, indicates certain option types are critical options.  Hence we feel that it is best to leave it the way it is defined.
>
> </Response>
>
>
>
> <End of Responses>
>
>
>
>
>
>