[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> Fri, 26 May 2017 01:36 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 5AC01129BDD for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 18:36:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 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, 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 Cy3fUvhf9nBG for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 18:36:42 -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 77B86129B41 for <int-area@ietf.org>; Thu, 25 May 2017 18:36:41 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHI00940; Fri, 26 May 2017 01:36:39 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 26 May 2017 02:36:38 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Fri, 26 May 2017 09:36:34 +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?562U5aSNOiDnrZTlpI06IOetlOWkjTogW0ludC1hcmVhXSDnrZTlpI06IElz?= =?utf-8?B?IHRoZSBVRFAgZGVzdGluYXRpb24gcG9ydCBudW1iZXIgcmVzb3VyY2UgcnVu?= =?utf-8?B?bmluZyBvdXQ/Ly8gcmU6IEktRCBBY3Rpb246IGRyYWZ0LWlldGYtaW50YXJl?= =?utf-8?Q?a-gue-04.txt?=
Thread-Index: AQHS0RsMnyvO0qVuZEOz5xejzfeIJKH8l23w//9/jYCAAKQ8oIAAIOaAgARdqYCAA33pgIABITGQ
Date: Fri, 26 May 2017 01:36:33 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBAB24C@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> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <CALx6S34dQX8gGCLvR4OG70FfO7MY8CbOxB_CA-crcTmFE_zX3g@mail.gmail.com>
In-Reply-To: <CALx6S34dQX8gGCLvR4OG70FfO7MY8CbOxB_CA-crcTmFE_zX3g@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.0A090206.592786A7.0037, 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: 16e7f54091501823f02e5f41a77eb5a0
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/iKwzUGtlSiVOHkJUmvZlUcL8KW4>
Subject: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSNOiAg?= =?utf-8?q?=E7=AD=94=E5=A4=8D=3A_Is_the_UDP_destination_port_number_resour?= =?utf-8?q?ce_running_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea-gue-?= =?utf-8?q?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: Fri, 26 May 2017 01:36:44 -0000

Tom,

> -----邮件原件-----
> 发件人: Tom Herbert [mailto:tom@herbertland.com]
> 发送时间: 2017年5月26日 0:00
> 收件人: 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 Mon, May 22, 2017 at 7:49 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> >
> >
> >> -----邮件原件-----
> >> 发件人: 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.
> >
> Xiaohu,
> 
> GUE encapsulates by IP protocol, I don't believe there is a protocol number for
> NSH or BIER so they should not be encapsulated in version 1. There is a protocol
> number for MPLS-IP, however there is no fixed field in the MPLS header (like the
> IP version) so the overlay technique can't work. Furthermore, these three
> protocols are already encapsulations, the optimization makes the most sense for
> simple network protocols that are not encapsulations.

If so, it seems a little bit confused to claim it as a generic udp encapsulation.

> IPv4 and IPv6 can be directly encapsulated since they have a protocol number
> (can be encapsulated by version 0).

If the possible payload types of GUE are limited to IPv4, IPv6 and MPLS, and these payloads need to be directly transported over UDP, the most simple way is to allocate a dedicated port number for IP since MPLS has already be assigned one (RFC7510), IMHO.

> As I mentioned previously, Ethernet could be directly encapsulated via EtherIP
> that has a 4 bit version number at the beginning of its header. The way this
> would work is to set a version 1 pattern to indicate EtherIP. For example, we
> could specify that 0101  would be EtherIP. When GUE receives such a packet it
> will notice it's version one and then see that it is EtherIP (differentiated from
> IPv4 0100 and
> IPv6 0110 values). The first four bits are then overwritten by 0011 to make it a
> valid EtherIP header and then the packet is resubmitted to the stack as EtherIP.

To save the 4-byte GUE base header overhead when encapsulating Ethernet over UDP, you propose to insert the additional 16-bit EtherIP header between the UDP header and MAC frame?

Xiaohu

> Transport protocols (TCP, UDP, SCTP) might also be nice to support with direct
> encapsulation in version 1, but unfortunately since they start with a variable
> port number there's no way to do that.
> 
> Tom
> 
> > Best regards,
> > Xiaohu
> >
> >> Tom
> >>
> >> > Xiaohu
> >> >
> >> >> Joe