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

Xuxiaohu <xuxiaohu@huawei.com> Mon, 20 June 2016 02:25 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 DD91D12D8BA; Sun, 19 Jun 2016 19:25:41 -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 kLscA06z5FYA; Sun, 19 Jun 2016 19:25:39 -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 6B80412D60E; Sun, 19 Jun 2016 19:25:38 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CRD05877; Mon, 20 Jun 2016 02:25:35 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.235.1; Mon, 20 Jun 2016 03:25:34 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml412-hub.china.huawei.com ([10.98.56.73]) with mapi id 14.03.0235.001; Mon, 20 Jun 2016 10:25:29 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Tom Herbert <tom@herbertland.com>
Thread-Topic: [nvo3] [Int-area] Fwd: New Version Notification for draft-ietf-nvo3-gue-03.txt
Thread-Index: AQHRx9yFbJRXFm15w0+03CGCJqjQoZ/s3uCQgABnFgCABF1eMA==
Date: Mon, 20 Jun 2016 02:25:28 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0D565143@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> <CALx6S35k2y_emb757PaGQR0=xQHEENZ1BYHE1F2wBN+nDJL5UQ@mail.gmail.com>
In-Reply-To: <CALx6S35k2y_emb757PaGQR0=xQHEENZ1BYHE1F2wBN+nDJL5UQ@mail.gmail.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.57675420.0026, 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: 738edd86f1cc59daf0dfa3ff8c2bcb52
Archived-At: <https://mailarchive.ietf.org/arch/msg/nvo3/1B73epglMGRjCw-t1ABvesDdINs>
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: Mon, 20 Jun 2016 02:25:42 -0000


> -----Original Message-----
> From: Tom Herbert [mailto:tom@herbertland.com]
> Sent: Friday, June 17, 2016 11:36 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 6:48 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> >
> >
> >> -----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,
> 
> Ugliness is in the eye of the beholder. Personally, I think this solution is clever and
> elegant. Also, this was a trivial code change to make work in GUE.
> 
> As for the UDP port number space, I suggest you review RFC6335. From that:
> 
> "Conservation of the port number space is required because this space is a
> limited resource, so applications are expected to participate in the traffic
> demultiplexing process where feasible.  The port numbers are expected to
> encode as little information as possible that will still enable an application to
> perform further demultiplexing by itself."
> 
> To flip the question around, what would be the value be for allocating new port
> numbers to do IP-over-UDP if this can already be done with an existing port

Clear and simple, especially in the case where other versions of GUE than 1 (i.e., IP-in-UDP) would never be deployed, as you had mentioned below. 

Xiaohu

> number? The fact that this same port number can be also used for GUE isn't
> particularly relevant (i.e. the Swiss Army Knife point), an implementation is
> perfectly free to only send IP-in-UDP on the port and never has to send a single
> GUE packet (vers. 0).
> Semantically and operationally there is no difference between port
> 6080 or using a new port for IP-in-UDP.
> 
> Tom
> 
> >> >
> >> >> 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