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

"Ganga, Ilango S" <ilango.s.ganga@intel.com> Wed, 15 January 2020 05:16 UTC

Return-Path: <ilango.s.ganga@intel.com>
X-Original-To: nvo3@ietfa.amsl.com
Delivered-To: nvo3@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43C54120048; Tue, 14 Jan 2020 21:16:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikyGoRM-pTaM; Tue, 14 Jan 2020 21:16:38 -0800 (PST)
Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E567120024; Tue, 14 Jan 2020 21:16:38 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jan 2020 21:16:37 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.70,321,1574150400"; d="scan'208,217";a="256614769"
Received: from orsmsx105.amr.corp.intel.com ([10.22.225.132]) by fmsmga002.fm.intel.com with ESMTP; 14 Jan 2020 21:16:36 -0800
Received: from orsmsx155.amr.corp.intel.com (10.22.240.21) by ORSMSX105.amr.corp.intel.com (10.22.225.132) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 14 Jan 2020 21:16:36 -0800
Received: from orsmsx116.amr.corp.intel.com ([169.254.7.30]) by ORSMSX155.amr.corp.intel.com ([169.254.7.66]) with mapi id 14.03.0439.000; Tue, 14 Jan 2020 21:16:36 -0800
From: "Ganga, Ilango S" <ilango.s.ganga@intel.com>
To: Barry Leiba <barryleiba@computer.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-nvo3-geneve@ietf.org" <draft-ietf-nvo3-geneve@ietf.org>, Matthew Bocci <matthew.bocci@nokia.com>, "nvo3-chairs@ietf.org" <nvo3-chairs@ietf.org>, "nvo3@ietf.org" <nvo3@ietf.org>, Martin Vigoureux <martin.vigoureux@nokia.com>, "T. Sridhar" <tsridhar@vmware.com>, Jesse Gross <jesse@kernel.org>
Thread-Topic: Barry Leiba's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)
Thread-Index: AQHVqxuAZQ6cv+ndJk68pQVlvYmdH6fra51A
Date: Wed, 15 Jan 2020 05:16:36 +0000
Message-ID: <C5A274B25007804B800CB5B289727E35906A3F15@ORSMSX116.amr.corp.intel.com>
References: <157551626672.11187.18427078634450263590.idtracker@ietfa.amsl.com>
In-Reply-To: <157551626672.11187.18427078634450263590.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiYjNhYTAzNGUtNjMyOC00NWQ5LWI4NDUtMGY3MDM0YTU0NjM4IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoia0VjRVRSRUFtQzVRODhaUHVKWkpOTVpxSVNEbGE4cjZFVFJPM2ZySlZsTE8wY09JbEVTeDFzekxXTVNRQzFDQiJ9
x-ctpclassification: CTP_NT
dlp-product: dlpe-windows
dlp-version: 11.2.0.6
dlp-reaction: no-action
x-originating-ip: [10.22.254.140]
Content-Type: multipart/alternative; boundary="_000_C5A274B25007804B800CB5B289727E35906A3F15ORSMSX116amrcor_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/C61ain76bjUtSXA0dAWeGXEzvCA>
Subject: Re: [nvo3] Barry Leiba's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Network Virtualization Overlays \(NVO3\) Working Group" <nvo3.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/nvo3>, <mailto:nvo3-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/nvo3/>
List-Post: <mailto:nvo3@ietf.org>
List-Help: <mailto:nvo3-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/nvo3>, <mailto:nvo3-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jan 2020 05:16:40 -0000

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 <noreply@ietf.org>
Sent: Wednesday, December 4, 2019 7:24 PM
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-nvo3-geneve@ietf.org; Matthew Bocci <matthew.bocci@nokia.com>; nvo3-chairs@ietf.org; matthew.bocci@nokia.com; nvo3@ietf.org
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>