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> Fri, 19 May 2017 14:56 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 CA16B1292C5 for <int-area@ietfa.amsl.com>; Fri, 19 May 2017 07:56:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] 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 33Naeps6ncHY for <int-area@ietfa.amsl.com>; Fri, 19 May 2017 07:56:38 -0700 (PDT)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 D8062128C81 for <int-area@ietf.org>; Fri, 19 May 2017 07:56:37 -0700 (PDT)
Received: by mail-qk0-x230.google.com with SMTP id k74so63152871qke.1 for <int-area@ietf.org>; Fri, 19 May 2017 07:56:37 -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=Vi23l9W8nMXhFA4XRBIAMtqgDjKIzK1wCj8JuLUeOcQ=; b=NZIEqfP9YqmADdARPhy0LIc2VVxj9kICRSUQSodr033zyFOze/cfw14yELmfSEwbuc d40V0IHiAziai8zlOax8wIpY5qSW7zJYfYWThu1n13e6xEQsoSHXRo8ztbod2CxFltja R+yRydQvUeIGqtp31zSgAvDO+2vvz0SLxN2JUZWTd0Tsp2vPXTmDrmYlSDsAG/5deGDD H48MKa3I81CCIOJYxITcvIiHc0Wpu5lBW40NgqcbR70dQQW5aHFQ2BWaxobqvAG+xuFG W6EzWGR74snH/rrOsi+pVICVnRyTf7ATch718bAKoPrXaiBdFxTvry+hgWN0Q1VAm7Yh 2LoA==
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=Vi23l9W8nMXhFA4XRBIAMtqgDjKIzK1wCj8JuLUeOcQ=; b=uboLxbyZwQXZtgrEUbOyB7w0aCoyVd1/V9F7q0PMa7QoU0Fej6A1dcICycqKkeodmF ERrtBZYN/5MWTlAtabE1LYjvcSlMuwCf48ohAGoV0e0eipqdCr2jRELLmWzpgdDdMQIr LacfhhaJ4shoqXoM9OB73957JnwMomOP619qKMe2ezNIy3wpl0w7byQ4A/m8CVD660Y7 z7g3fEfzMoXJbc5pRmy5PVmb8QN2hXoaLcLDU9y7zXP/itcgPGM42UdHmKS0RflKHjUg 5QKop5nfBeSDmGCF3gjyuHzQwpqUv0Hc0Z5Xahs1+xCRSXWg0RouIFphpmuhWtFjP6g0 pUZg==
X-Gm-Message-State: AODbwcDtY0JW6bhVwIz5jAig9NN3U5SIfmz3lImQg1ZS4xkiVwo6PQQG ZWFnZJljqm7wuvy1psmT14XsgTi8oUu6ljU=
X-Received: by 10.55.146.68 with SMTP id u65mr9295170qkd.77.1495205796844; Fri, 19 May 2017 07:56:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Fri, 19 May 2017 07:56:36 -0700 (PDT)
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com>
References: <149514799195.6631.3231700013200014494@ietfa.amsl.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 19 May 2017 07:56:36 -0700
Message-ID: <CALx6S37nrJNGLdRHWx9DYNQyS54YdwLCXcG9Mp3zi4L_wrr6=g@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/U0RMFXifj0Ep6BP-lGxVSoNw7t0>
Subject: Re: [Int-area] Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
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, 19 May 2017 14:56:40 -0000

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.

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

> If I remembered correctly, this draft was originally adopted by the NVO3 WG which is focused on multi-tenancy, although this draft has nothing to do with multi-tenancy:) Latter it becomes a INTAREA WG draft. by the way, did I miss the WG adoption call for this draft in the INTAREA WG or the WG adoption call isn't occurred at all?
>
It was adopted after Seoul IETF.

> Second, UDP itself has been widely used as a tunnel technology due to its load-balancing capability. See LISP [RFC6830], VXLAN [RFC7346], MPLS-in-UDP [RFC7510], GRE-in-UDP [RFC8086], ESP-in-UDP [RFC3948], TRILL-in-UDP, NSH-in-UDP, VXLAN-GPE, GENEVE, GUE, ... The destination port is used to distinguish these different UDP tunnel payload types. For IP-in-UDP, there has been a draft (https://tools.ietf.org/html/draft-xu-intarea-ip-in-udp) which was originally discussed in Softwire WG (https://tools.ietf.org/html/draft-xu-softwire-ip-in-udp) . IMHO, it seems ugly to use a version field within the GUE header to distinguish IPvx header from the GUE header itself. Is the UDP destination port number resource running out?

>From RFC7605, section 6 "Conservation":

"Assigned port numbers are a limited resource that is globally shared
by the entire Internet community.  As of 2014, approximately 5850 TCP
and 5570 UDP port numbers had been assigned out of a total range of
49151.  As a result of past conservation, current assigned port use is
small and the current rate of assignment avoids the need for
transition to larger number spaces.  This conservation also helps
avoid the need for IANA to rely on assigned port number reclamation,
which is practically impossible even though procedurally permitted
[RFC6335].

Also, it's not just the assignment that is a pain, port numbers to
need to be managed in networks. If we introduce a new port number in
the datacenter management tools, firewalls, packet capture need to be
updated.

A feature of GUE is that the payload transform option allows DTLS to
be done on the payload. This obviates needing to ask for two port
numbers (a DTLS variant and non-DTLS variant) as several of the
encapsulation methods you listed above have done.

> If so, why not use GRE-in-UDP to carry GUE so as to save one more UDP destination port number?
>
Then we'd be talking about having to reserve an Ethertype for GUE.

> Third, if the GUE devotes itself to save the UDP destination port number for the interest of the internet community, the 2-bit version field abused as a payload type indicator is obviously not enough:)
>
I'm not sure how it's "obviously not enough". Version 1 handles the
currently deployed two IP protocol versions. The technique allows for
supporting two more IP protocol versions to be supported without
burning another version number.

Tom

> Best regards,
> Xiaohu
>
>> -----邮件原件-----
>> 发件人: Int-area [mailto:int-area-bounces@ietf.org] 代表
>> internet-drafts@ietf.org
>> 发送时间: 2017年5月19日 6:53
>> 收件人: i-d-announce@ietf.org
>> 抄送: int-area@ietf.org
>> 主题: [Int-area] I-D Action: draft-ietf-intarea-gue-04.txt
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Internet Area Working Group of the IETF.
>>
>>         Title           : Generic UDP Encapsulation
>>         Authors         : Tom Herbert
>>                           Lucy Yong
>>                           Osama Zia
>>       Filename        : draft-ietf-intarea-gue-04.txt
>>       Pages           : 37
>>       Date            : 2017-05-18
>>
>> Abstract:
>>    This specification describes Generic UDP Encapsulation (GUE), which
>>    is a scheme for using UDP to encapsulate packets of different 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
>>    as 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.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-intarea-gue/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-intarea-gue-04
>> https://datatracker.ietf.org/doc/html/draft-ietf-intarea-gue-04
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-gue-04
>>
>>
>> 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.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> Int-area mailing list
>> Int-area@ietf.org
>> https://www.ietf.org/mailman/listinfo/int-area
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area