Re: [nvo3] [Int-area] Fwd: New Version Notification for draft-ietf-nvo3-gue-03.txt

Joe Touch <touch@isi.edu> Fri, 17 June 2016 04:28 UTC

Return-Path: <touch@isi.edu>
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 2B9D312DA59; Thu, 16 Jun 2016 21:28:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.326
X-Spam-Level:
X-Spam-Status: No, score=-8.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.426] 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 TfXHBM7BTJ6N; Thu, 16 Jun 2016 21:28:37 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9281812D94C; Thu, 16 Jun 2016 21:28:37 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-251-17.socal.res.rr.com [172.250.251.17]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id u5H4RtvU025089 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Jun 2016 21:27:57 -0700 (PDT)
To: Xuxiaohu <xuxiaohu@huawei.com>, Tom Herbert <tom@herbertland.com>
References: <20160610171451.30437.44413.idtracker@ietfa.amsl.com> <CALx6S34_ba2kBhUY7keEMmPO3fTRAAQsCkyGiy47=NnPm8xgug@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D5647FB@NKGEML515-MBX.china.huawei.com> <CALx6S37K2H+SuEN+5Nmi-GOX0nX-k34YQt0anWJWTUBpBZZGew@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D564ABD@NKGEML515-MBX.china.huawei.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D564B19@NKGEML515-MBX.china.huawei.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <57637C4B.3040603@isi.edu>
Date: Thu, 16 Jun 2016 21:27:55 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D564B19@NKGEML515-MBX.china.huawei.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/Cvr-SHw5OQFQg3WwC55xf9ZWJas>
Cc: "nvo3@ietf.org" <nvo3@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [nvo3] [Int-area] Fwd: New Version Notification for draft-ietf-nvo3-gue-03.txt
X-BeenThere: nvo3@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 17 Jun 2016 04:28:39 -0000

On 6/16/2016 8:09 PM, Xuxiaohu wrote:
> Hi Tom,
>
> By the way, I have just had a look at your draft. It seems that this draft itself has nothing to do with the multi-tenancy capability which is the focus of the NOV3 current charter.

FWIW, I agree it would be useful to add text to discuss the relationship
to NVO3.

>  In addition, according to section 7 (Motivation for GUE) of this draft, it seems that GUE is intended to be a generic UDP-based tunneling technology. Therefore, should this draft be pursued in some WGs other than NVO3, e.g., TSVWG or INTAREA.
It will definitely get review there, but to some extent it already is -
there are TSV and INT area feedback in this thread.

>  In this way, it would be helpful for us to better understand the differences between GUE and GRE-in-UDP, and whether the concerns made by Joe Touch (see below) have been addressed successfully, especially when considering the case where the version is set to 1 (i.e., directly encapsulating IP packet over UDP).

I agree that these issues should be addressed here too, though - to be
fair - some of them already are.

Joe

>
>
> +++++++++
> 	- stronger checksums
>
> 	- fragmentation support
> 	
> 	- signalling support (e.g., to test whether a tunnel is up or
> 	to measure MTUs)
>
> 	- support for robust ID fields (related to fragmentation,
> 	e.g., to overcome the limits of IPv4 ID as per RFC 6864)
> ++++++++++
>