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

Tom Herbert <tom@herbertland.com> Sat, 20 May 2017 15:45 UTC

Return-Path: <tom@herbertland.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 23A91128B8F for <int-area@ietfa.amsl.com>; Sat, 20 May 2017 08:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com
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 paWKJgiOWpmW for <int-area@ietfa.amsl.com>; Sat, 20 May 2017 08:45:49 -0700 (PDT)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDA4F128B51 for <int-area@ietf.org>; Sat, 20 May 2017 08:45:48 -0700 (PDT)
Received: by mail-qk0-x22f.google.com with SMTP id y201so80707015qka.0 for <int-area@ietf.org>; Sat, 20 May 2017 08:45:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=994D1fAO1I67zLfj8wu7LsF4IynV0tifRXV8EkFzxzo=; b=o94mfm3ZH6+Xcw9g6wYekWZUHxTVyfPQ0VedZBBPpkb/vNt+Co8sPVuXv8FDUHL6VF tz3mpS7obu5GODyhMRWE8vr+ysGLbLM2mjxuouZ7aGaEB3lhkKFXxF2kxt9qBIDRxZL7 dYCBMgNUMbx07zJ+nfizYoWP0a8WJRGGsGW0I22u7ShdH02Id8VgnsyNTP9i2NlADsAJ +nQFbSLF5FqXnILWuiZjAmXWkDIdNafqwkObKdUsU0LdaE7GS7L9kX/8aeDQg3Rw2kGK lMQ9CXcP1MV70MeCQNTM6BPk+DylqEBqb8BrU7ZGyKkPfLy1jBqsjmrI0l352SJ1L8AO vOmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=994D1fAO1I67zLfj8wu7LsF4IynV0tifRXV8EkFzxzo=; b=XIodm0eU8kdBlerMwYvyoIL2fSgexOEajPt6m7O7QOq9CEQparMk1uqPUVL/Z2nAtd BF+T6DMRVqbYXPBid63jTfLJtglrngRQ7f8aP9NMMcmewrkcCzicPNFa3CK3zgFqiC97 oxZ2prMIQxD2u3ElYLAj1oHFbJ+SDt7HGYnSZaYh7rmZVBdl3OcL1ceF9ufzfoWkuuKE QSaXODk+JOqrxFuCaxg5M0iz781SO9MF6i7sbCZxXzR9kcqTb8qO1gT14G2VDuTnbPMq rgdNV7sWJGwnRAOwhuQCbMccrSvKNefipUdG2s1kLjgUeoLg8j3yh2ZxIlwTzMQU5GFM AXXg==
X-Gm-Message-State: AODbwcCu/YQTiRfEsR4etRvRv1Yvu3qPVJ1byvReXjZqk6EvoZcoqccy MLB/9sMMi9j5RP4cD9QKGii5TQiLgoqt
X-Received: by 10.55.197.92 with SMTP id p89mr12928478qki.34.1495295147947; Sat, 20 May 2017 08:45:47 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Sat, 20 May 2017 08:45:47 -0700 (PDT)
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA8877@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>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 20 May 2017 08:45:47 -0700
Message-ID: <CALx6S35Y7VzX7eDSxcMy+swyW9E_3N6b5790Kn6Ni6jvdkY68w@mail.gmail.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
Cc: "int-area@ietf.org" <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/QbcYkPXzuZbM2PEVe3c7tXtLJdU>
Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiAgSXMgdGhlIFVEUCBkZXN0aW5hdGlv?= =?utf-8?q?n_port_number_resource_running_out=3F//_re=3A_I-D_Action=3A_dra?= =?utf-8?q?ft-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: Sat, 20 May 2017 15:45:50 -0000

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.

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

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

Tom