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

Xuxiaohu <xuxiaohu@huawei.com> Fri, 17 June 2016 03:09 UTC

Return-Path: <xuxiaohu@huawei.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 DBAEE12DABA; Thu, 16 Jun 2016 20:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.647
X-Spam-Level:
X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, 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 Q5FBGvlcUxxQ; Thu, 16 Jun 2016 20:09:17 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1F7212DA71; Thu, 16 Jun 2016 20:09:16 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CQY42272; Fri, 17 Jun 2016 03:09:15 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.235.1; Fri, 17 Jun 2016 04:09:14 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Fri, 17 Jun 2016 11:09:04 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Tom Herbert <tom@herbertland.com>
Thread-Topic: [Int-area] [nvo3] Fwd: New Version Notification for draft-ietf-nvo3-gue-03.txt
Thread-Index: AQHRyEWafHfKWGdujkiT2syduaAyvA==
Date: Fri, 17 Jun 2016 03:09:04 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D564B19@NKGEML515-MBX.china.huawei.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>
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D564ABD@NKGEML515-MBX.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.99.55]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.576369DB.0077, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: d519534f41a74e64bf00e32f2fa3e39e
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/_mZloQpQAooBhABT2LAtJwlC8r4>
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 03:09:20 -0000

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. 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. 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).


+++++++++
	- 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)
++++++++++

Best regards,
Xiaohu

> -----Original Message-----
> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Xuxiaohu
> Sent: Friday, June 17, 2016 9:49 AM
> To: Tom Herbert
> Cc: nvo3@ietf.org; int-area@ietf.org
> Subject: Re: [Int-area] [nvo3] Fwd: New Version Notification for
> draft-ietf-nvo3-gue-03.txt
> 
> 
> 
> > -----Original Message-----
> > From: Tom Herbert [mailto:tom@herbertland.com]
> > Sent: Thursday, June 16, 2016 10:37 PM
> > To: Xuxiaohu
> > Cc: int-area@ietf.org; nvo3@ietf.org
> > Subject: Re: [nvo3] [Int-area] Fwd: New Version Notification for
> > draft-ietf-nvo3-gue-03.txt
> >
> > On Thu, Jun 16, 2016 at 2:12 AM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> > >
> > >
> > >> -----Original Message-----
> > >> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Tom
> > >> Herbert
> > >> Sent: Saturday, June 11, 2016 1:21 AM
> > >> To: int-area@ietf.org; nvo3@ietf.org
> > >> Subject: [Int-area] Fwd: New Version Notification for
> > >> draft-ietf-nvo3-gue-03.txt
> > >>
> > >> Hello,
> > >>
> > >> We've posted a new version of GUE. The primary addition is that we
> > >> added GUE version 1 that allows direct encapsulation of IPv4 and
> > >> IPv6 over UDP (port 6080). This effectively implements
> > >> draft-xu-intarea-ip-in-udp-03 also.
> > > Tom,
> > >
> > > What's the real benefit of such implementation of IP-in-UDP compared
> > > to the
> > approach as described draft-xu-intarea-ip-in-udp-03? Save one UDP port
> > number?
> > >
> > Yes, saves a port number.
> 
> To save a port number, the header format is made ugly. Is it worthwhile? If UDP
> port resource was so sparse as you had imagined, I think the UDP port resource
> keeper would not allocate two different port numbers for VXLAN and
> VXLAN-GPE since the P-bit in VXLAN-GPE header is enough to distinguish
> VXLAN-GPE from VXLAN. For more details, please look at section 3.2 of
> (https://tools.ietf.org/html/draft-ietf-nvo3-vxlan-gpe-02#page-6).
> 
> Xiaohu
> 
> > Tom
> >
> > > Best regards,
> > > Xiaohu
> > >
> > >> Thanks,
> > >> Tom
> > >>
> > >> ---------- Forwarded message ----------
> > >> From:  <internet-drafts@ietf.org>
> > >> Date: Fri, Jun 10, 2016 at 10:14 AM
> > >> Subject: New Version Notification for draft-ietf-nvo3-gue-03.txt
> > >> To: Tom Herbert <tom@herbertland.com>, Lucy Yong
> > >> <lucy.yong@huawei.com>, Osama Zia <osamaz@microsoft.com>
> > >>
> > >>
> > >>
> > >> A new version of I-D, draft-ietf-nvo3-gue-03.txt has been
> > >> successfully submitted by Tom Herbert and posted to the IETF repository.
> > >>
> > >> Name:           draft-ietf-nvo3-gue
> > >> Revision:       03
> > >> Title:          Generic UDP Encapsulation
> > >> Document date:  2016-06-10
> > >> Group:          nvo3
> > >> Pages:          28
> > >> URL:
> > >> https://www.ietf.org/internet-drafts/draft-ietf-nvo3-gue-03.txt
> > >> Status:         https://datatracker.ietf.org/doc/draft-ietf-nvo3-gue/
> > >> Htmlized:       https://tools.ietf.org/html/draft-ietf-nvo3-gue-03
> > >> Diff:           https://www.ietf.org/rfcdiff?url2=draft-ietf-nvo3-gue-03
> > >>
> > >> Abstract:
> > >>    This specification describes Generic UDP Encapsulation (GUE), which
> > >>    is a scheme for using UDP to encapsulate packets of arbitrary IP
> > >>    protocols for transport across layer 3 networks. By encapsulating
> > >>    packets in UDP, specialized capabilities in networking hardware for
> > >>    efficient handling of UDP packets can be leveraged. GUE specifies
> > >>    basic encapsulation methods upon which higher level constructs, such
> > >>    tunnels and overlay networks for network virtualization, can be
> > >>    constructed. GUE is extensible by allowing optional data fields as
> > >>    part of the encapsulation, and is generic in that it can encapsulate
> > >>    packets of various IP protocols.
> > >>
> > >>
> > >>
> > >>
> > >> Please note that it may take a couple of minutes from the time of
> > >> submission until the htmlized version and diff are available at tools.ietf.org.
> > >>
> > >> The IETF Secretariat
> > >>
> > >> _______________________________________________
> > >> Int-area mailing list
> > >> Int-area@ietf.org
> > >> https://www.ietf.org/mailman/listinfo/int-area
> > >
> > > _______________________________________________
> > > nvo3 mailing list
> > > nvo3@ietf.org
> > > https://www.ietf.org/mailman/listinfo/nvo3
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area