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

"Ganga, Ilango S" <ilango.s.ganga@intel.com> Tue, 04 February 2020 22:27 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 4922E120131; Tue, 4 Feb 2020 14:27:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 7do9pV8PuOgb; Tue, 4 Feb 2020 14:27:33 -0800 (PST)
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) (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 D795212003F; Tue, 4 Feb 2020 14:27:32 -0800 (PST)
X-Amp-Result: SKIPPED(no attachment in message)
X-Amp-File-Uploaded: False
Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2020 14:27:31 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.70,403,1574150400"; d="scan'208";a="431668527"
Received: from orsmsx102.amr.corp.intel.com ([10.22.225.129]) by fmsmga006.fm.intel.com with ESMTP; 04 Feb 2020 14:27:31 -0800
Received: from orsmsx116.amr.corp.intel.com ([169.254.7.209]) by ORSMSX102.amr.corp.intel.com ([169.254.3.100]) with mapi id 14.03.0439.000; Tue, 4 Feb 2020 14:27:30 -0800
From: "Ganga, Ilango S" <ilango.s.ganga@intel.com>
To: Barry Leiba <barryleiba@computer.org>
CC: The IESG <iesg@ietf.org>, "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+ndJk68pQVlvYmdH6fra51AgAEu14CAH2KqkA==
Date: Tue, 04 Feb 2020 22:27:30 +0000
Message-ID: <C5A274B25007804B800CB5B289727E35906BC956@ORSMSX116.amr.corp.intel.com>
References: <157551626672.11187.18427078634450263590.idtracker@ietfa.amsl.com> <C5A274B25007804B800CB5B289727E35906A3F15@ORSMSX116.amr.corp.intel.com> <CALaySJKy0kO8mT=rhfEnRZ9Ct+oj7kZZ3Rwf-17AVem3+-NnBA@mail.gmail.com>
In-Reply-To: <CALaySJKy0kO8mT=rhfEnRZ9Ct+oj7kZZ3Rwf-17AVem3+-NnBA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzg0ZjY2NjUtZmRiYS00YjQ2LWI2NzYtYTMyMjU2ZDE5NzE0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiWU5QNlo5WE5OVXdrazBGRWZaKzcwbENrQVJBK2FGd1NrTDZuVzNpRFwvRWd4NXR3M2JTalFySGttZ1YxYjE2MU8ifQ==
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/FZDt_v2NZxk2-MS07zv3_eM0-v0>
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: Tue, 04 Feb 2020 22:27:35 -0000

Hi Barry,

Thanks for your response.  We will refresh the draft as soon as we hear back from few other reviewers.

Regards,
Ilango

-----Original Message-----
From: Barry Leiba <barryleiba@computer.org> 
Sent: Wednesday, January 15, 2020 7:06 AM
To: Ganga, Ilango S <ilango.s.ganga@intel.com>
Cc: The IESG <iesg@ietf.org>; draft-ietf-nvo3-geneve@ietf.org; Matthew Bocci <matthew.bocci@nokia.com>; nvo3-chairs@ietf.org; nvo3@ietf.org; Martin Vigoureux <martin.vigoureux@nokia.com>; T. Sridhar <tsridhar@vmware.com>; Jesse Gross <jesse@kernel.org>
Subject: Re: Barry Leiba's Discuss on draft-ietf-nvo3-geneve-14: (with DISCUSS and COMMENT)

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 <ilango.s.ganga@intel.com> 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 <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>
>
>
>
>
>
>