[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, 19 May 2017 02:58 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 []) by ietfa.amsl.com (Postfix) with ESMTP id 7DB3C127241 for <int-area@ietfa.amsl.com>; Thu, 18 May 2017 19:58:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.222
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mXS_Apbkrcsv for <int-area@ietfa.amsl.com>; Thu, 18 May 2017 19:58:49 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E3D6129C0C for <int-area@ietf.org>; Thu, 18 May 2017 19:54:01 -0700 (PDT)
Received: from (EHLO LHREML711-CAH.china.huawei.com) ([]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DGX04998; Fri, 19 May 2017 02:53:59 +0000 (GMT)
Received: from NKGEML414-HUB.china.huawei.com ( by LHREML711-CAH.china.huawei.com ( with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 19 May 2017 03:53:58 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([]) with mapi id 14.03.0235.001; Fri, 19 May 2017 10:53:45 +0800
From: Xuxiaohu <xuxiaohu@huawei.com>
To: "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: Is the UDP destination port number resource running out?// re: [Int-area] I-D Action: draft-ietf-intarea-gue-04.txt
Thread-Index: AQHS0CmnQ/zIrELPwk+iaB2D2b/nV6H63uUg
Date: Fri, 19 May 2017 02:53:45 +0000
Message-ID: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA82B7@NKGEML515-MBX.china.huawei.com>
References: <149514799195.6631.3231700013200014494@ietfa.amsl.com>
In-Reply-To: <149514799195.6631.3231700013200014494@ietfa.amsl.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.591E5E48.0005, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: 2d055b51bf1eb07c76d8f48d76950b50
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/8UMvsEeXeiY7TJc5rYoIVXdEfFo>
Subject: [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 02:58:51 -0000

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. 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:)  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?

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? If so, why not use GRE-in-UDP to carry GUE so as to save one more UDP destination port number? 

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:)

Best regards,

> -----邮件原件-----
> 发件人: 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