[Int-area] 答复: 答复: 答复: 答复: Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt

Xuxiaohu <xuxiaohu@huawei.com> Tue, 23 May 2017 02:50 UTC

Return-Path: <xuxiaohu@huawei.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82C9E1294A1 for <int-area@ietfa.amsl.com>; Mon, 22 May 2017 19:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
X-Spam-Level:
X-Spam-Status: No, score=-4.222 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=-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 faTFjkvsV2WK for <int-area@ietfa.amsl.com>; Mon, 22 May 2017 19:50:13 -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 A4BC3129469 for <int-area@ietf.org>; Mon, 22 May 2017 19:50:12 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHC89065; Tue, 23 May 2017 02:50:10 +0000 (GMT)
Received: from NKGEML412-HUB.china.huawei.com (10.98.56.73) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 23 May 2017 03:50:09 +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; Tue, 23 May 2017 10:49:48 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Tom Herbert <tom@herbertland.com>
CC: Joe Touch <touch@isi.edu>, "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: =?utf-8?B?562U5aSNOiDnrZTlpI06IFtJbnQtYXJlYV0g562U5aSNOiBJcyB0aGUgVURQ?= =?utf-8?B?IGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyIHJlc291cmNlIHJ1bm5pbmcgb3V0?= =?utf-8?B?Py8vIHJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFyZWEtZ3VlLTA0?= =?utf-8?Q?.txt?=
Thread-Index: AQHS0RsMnyvO0qVuZEOz5xejzfeIJKH8l23w//9/jYCAAKQ8oIAAIOaAgARdqYA=
Date: Tue, 23 May 2017 02:49:47 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com>
References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com> <CALx6S37nrJNGLdRHWx9DYNQyS54YdwLCXcG9Mp3zi4L_wrr6=g@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@NKGEML515-MBX.china.huawei.com> <a3915b87-f104-51d8-11e3-d9f8196462b5@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8903@NKGEML515-MBX.china.huawei.com> <54980b3a-2dc9-2ab1-f150-45b3f500f7ac@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com> <CALx6S350VcJCm4g70jycbXD3FxaGg9eF-dn61_SdVF8xmmkojg@mail.gmail.com>
In-Reply-To: <CALx6S350VcJCm4g70jycbXD3FxaGg9eF-dn61_SdVF8xmmkojg@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.184.181]
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.0A090202.5923A363.0029, 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: 84c208743e9e7b5acb6473db37136984
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/doEsxSmvF0N-I7nB2mF0KBNvWCo>
Subject: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIOetlOWkjTog?= =?utf-8?q?Is_the_UDP_destination_port_number_resource_running_out=3F//_re?= =?utf-8?q?=3A_I-D_Action=3A_draft-ietf-intarea-gue-04=2Etxt?=
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 May 2017 02:50:15 -0000


> -----邮件原件-----
> 发件人: Tom Herbert [mailto:tom@herbertland.com]
> 发送时间: 2017年5月21日 0:01
> 收件人: Xuxiaohu
> 抄送: Joe Touch; int-area@ietf.org
> 主题: Re: 答复: 答复: [Int-area] 答复: Is the UDP destination port number
> resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
> 
> On Fri, May 19, 2017 at 11:09 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> >
> >
> >> -----邮件原件-----
> >> 发件人: Joe Touch [mailto:touch@isi.edu]
> >> 发送时间: 2017年5月20日 12:15
> >> 收件人: Xuxiaohu; Tom Herbert
> >> 抄送: int-area@ietf.org
> >> 主题: Re: 答复: [Int-area] 答复: Is the UDP destination port number
> >> resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
> >>
> >>
> >>
> >> On 5/19/2017 8:57 PM, Xuxiaohu wrote:
> >> > Hi Joe,
> >> >
> >> >> -----邮件原件-----
> >> >> 发件人: Joe Touch [mailto:touch@isi.edu]
> >> >> 发送时间: 2017年5月20日 11:41
> >> >> 收件人: Xuxiaohu; Tom Herbert
> >> >> 抄送: int-area@ietf.org
> >> >> 主题: Re: [Int-area] 答复: Is the UDP destination port number resource
> >> >> running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
> >> >>
> >> >>
> >> >>
> >> >> On 5/19/2017 6:39 PM, Xuxiaohu wrote:
> >> >>> If the saving is beneficial, it'd better to assign a dedicated
> >> >>> port number for each UDP payload type( e.g., IP packet), rather
> >> >>> than combining the UDP port number dedicated for GUE and the
> >> >>> version field within the GUE header together to indicate whether
> >> >>> the UDP payload is GUE or IP (or even other payload type if the
> >> >>> GUE is devoted to help save the UDP port number resource for the
> >> >>> IETF
> >> >>> community:))
> >> >> FWIW, IANA strives to assign one port for a service.
> >> > Great. Hence IPvx should be taken as a service rather than taking
> >> > IPvx and
> >> GUE as a service, IMO.
> >> GUE is supposed to be both signalling and content (data), where the
> >> data are IP packets.
> >
> > Since IANA strives to assign one port for a service, IP packet within the UDP
> tunnel should be assigned a dedicated port. In other words, GUE and IP-in-UDP
> are distinguished by the different port numbers.
> >
> >> Take away the IP part and GUE isn't an E anymore.
> >> >> Services are expected to have version fields and subtype
> >> >> demultiplexing indicators, to so that all message variants of
> >> >> current and future versions can use a single port number.
> >> > Sure, the version field within the IPvx packet could be used for
> >> > demultiplexing
> >> purpose.
> >>
> >> That demultiplexes within IPvx. There still needs to be a way to
> >> demultiplex non-IPvx packets (control) from IPvx.
> >
> > Since GUE and IP-in-UDP have different UDP port numbers, I don't know why
> there is still a need to demultiplex GUE and IP-in-UDP.
> >
> It's header compression. Consider a scenario that GUE is tunneling
> IPv6 and IPv4 and will do GUE fragmentation if necessary on tunnel ingress.
> So some packets will have a fragmentation option and some won't. For
> unfragmented packets with no GUE options, they can be sent in direct
> encapsulation of IP. This could be done as version 1 of GUE or in IP-in-UDP as
> you're suggesting. The problem with the latter is that it doubles the number of
> flows in the network. So instead of punching one hole for a tunnel in a firewall
> we need two (the fragment tunnel and non-fragment UDP ports). Packets in
> individual flows now can take different paths depending on whether they're
> fragmented so this introduces OOO.

Since GUE is intended to be a generic UDP encapsulation, now let's assume GUE is tunneling MPLS, NSH or BIER. Please continue your rationale once those encapsulations have the same requirement of saving the 4-byte GUE base header overhead as the encapsulation of IP in UDP.

Best regards,
Xiaohu

> Tom
> 
> > Xiaohu
> >
> >> Joe