[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 03:22 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 F3FCF1243F6; Mon, 22 May 2017 20:22:45 -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 WkExxx5NyXpC; Mon, 22 May 2017 20:22:44 -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 5057B12945F; Mon, 22 May 2017 20:22:43 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DHC92819; Tue, 23 May 2017 03:22:41 +0000 (GMT)
Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 23 May 2017 04:22:40 +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; Tue, 23 May 2017 11:22:34 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: Tom Herbert <tom@herbertland.com>
CC: "int-area@ietf.org" <int-area@ietf.org>, NVO3 <nvo3@ietf.org>
Thread-Topic: =?utf-8?B?562U5aSNOiBbSW50LWFyZWFdIElzIHRoZSBVRFAgZGVzdGluYXRpb24gcG9y?= =?utf-8?B?dCBudW1iZXIgcmVzb3VyY2UgcnVubmluZyBvdXQ/Ly8gcmU6IEktRCBBY3Rp?= =?utf-8?Q?on:_draft-ietf-intarea-gue-04.txt?=
Thread-Index: AQHS0LAkIpK7xvXSTE61Lupl2EaWeKH8YR4AgAB3sYCABGRxEA==
Date: Tue, 23 May 2017 03:22:33 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA9611@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> <CALx6S35Y7VzX7eDSxcMy+swyW9E_3N6b5790Kn6Ni6jvdkY68w@mail.gmail.com>
In-Reply-To: <CALx6S35Y7VzX7eDSxcMy+swyW9E_3N6b5790Kn6Ni6jvdkY68w@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.0A020203.5923AB01.00D8, 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: 219c63f8e912a9e53a52b6c773dbe067
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/ZSvVwqujwY-_UTvLEU-pg3eh9VY>
Subject: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06ICBJcyB0aGUgVURQIGRlc3Rp?= =?utf-8?q?nation_port_number_resource_running_out=3F//_re=3A_I-D_Action?= =?utf-8?q?=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 03:22:46 -0000

Hi Tom, 

> -----邮件原件-----
> 发件人: Tom Herbert [mailto:tom@herbertland.com]
> 发送时间: 2017年5月20日 23:46
> 收件人: Xuxiaohu
> 抄送: 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 6:39 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> > Hi Tom,
> >
> > Thanks for your quick response. Please see my reply inline.
> >
> >> -----邮件原件-----
> >> 发件人: Tom Herbert [mailto:tom@herbertland.com]
> >> 发送时间: 2017年5月19日 22:57
> >> 收件人: Xuxiaohu
> >> 抄送: 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
> >>
> >> Hi Xuxiaohu,
> >>
> >> Thanks for the comments. Some response are inline.
> >>
> >> On Thu, May 18, 2017 at 7:53 PM, Xuxiaohu <xuxiaohu@huawei.com>
> wrote:
> >> > Hi all,
> >> >
> >> > With regard to directly encapsulating IPvx packet in UDP, I think
> >> > the following
> >> argument for using Version 1 of GUE is not valid:
> >> >
> >> > "This technique saves encapsulation overhead on costly links
> >> >    for the common use of IP encapsulation, and also obviates the need to
> >> >    allocate a separate port number for IP-over-UDP encapsulation."
> >> >
> >> > First, I don't think the encapsulation overhead of 4 bytes is a matter.
> >>
> >> I'm not sure everyone would agree with that. The case was made when
> >> we were discussing it that the savings would be beneficial for some
> deployments.
> >
> > 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:))
> 
> Xuxiaohu,
> 
> We have already implemented the facility to directly encapsulate an IP protocol
> directly in UDP. This is FOU-over-UDP (FOU) and in fact GRE-in-UDP is just one
> sub case of the implementation. I know people are using FOU for various
> protocols in their networks, however I doubt we get very far if we requested
> 256 ports to directly encapsulate each IP protocol! It might make sense to
> document FOU as informational.

There had been a Foo-over-UDP draft (see https://tools.ietf.org/html/draft-yong-tsvwg-udp-encap-4-ip-tunneling-01). However, the reality is that different Foo's are specified in dedicated drafts since many foo-specific considerations need to be specified.

> >
> > BTW, what happens if any other GUE payload has the same desire of saving
> the 4 byte GUE header overhead?
> 
> The only other candidate beyond IPv4 and IPv6 that has been suggested is
> Ethernet which would be EtherIP. That is pretty feasible to support if there is
> enough desire.

Could you explain how to support the encapsulation of Ethernet without the 4-octect overhead? By the way, why Ethernet is the only other candidate since GUE is claimed to be generic?

> >
> >> > However, the premise is that it's meaningful for the IETF to
> >> > develop such a GENERIC and COVERALL encapsulation method which is
> >> > still looking for nails:)
> >>
> >> The protocol is called *Generic* UDP Encapsulation for reason.
> >
> > I know that you are trying to specify a generic UDP encapsulation. However,
> there has been a generic UDP encapsulation scheme that is GRE-in-UDP
> [RFC8086]. Furthermore, there is another generic UDP encapsulation scheme
> called GENEVE that the NVO3 group is working on. It's better for the IETF
> community to avoid specifying multiple similar encapsulation schemes and
> therefore the NVo3 WG co-chairs and the corresponding AD try their best to
> reach a consensus of working together on a single encapsulation on the basis of
> GENEVE among the WG members. Do you still believe it's helpful for the
> industry to specify one additional generic encapsulation scheme in another IETF
> WG?
> >
> Yes. The reason we needed to define GUE is that no other encapsulation
> protocol satisfies the requirements. GRE comes close, and in fact GUE is based
> on GRE. We love GRE for the datacenter. It's generic, extensible, simple,
> flag-fields are super efficient, and all hardware we tested works well with it. The
> downside of GRE is that it's extensibility is quite limited; we can only get 12
> bytes for fields.
> That's just not enough. The particular need we had was to add security to
> authenticate the header. We actually we're able to "find" 64 bits of in the fields
> by overloading checksum and sequence number, but that is really not enough
> for security. Besides that, there are other needs for extensibility like
> fragmentation, checksum, payload transform.
> We'll only ever need a handful of such extensions, but it's more than can be fit
> into GRE. So GUE is an answer. It has the same efficiency of GRE but is more
> extensible. Since it is a new protocol we are able to add a few other nice to have
> features like header length, encap by IP protocol, and private data block. Section
> 6 in the draft gives a motivation for GUE.

If GRE-in-UDP is not enough, what about GENEVE? (cced to NVO3)

Best regards,
Xiaohu

> Tom