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> Thu, 25 May 2017 16:00 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 9D5E5129B2E for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 09:00:25 -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 hpgbBX1_Wpoj for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 09:00:23 -0700 (PDT)
Received: from mail-wm0-x22e.google.com (mail-wm0-x22e.google.com [IPv6:2a00:1450:400c:c09::22e]) (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 9DBB0129B25 for <int-area@ietf.org>; Thu, 25 May 2017 09:00:20 -0700 (PDT)
Received: by mail-wm0-x22e.google.com with SMTP id b84so98057171wmh.0 for <int-area@ietf.org>; Thu, 25 May 2017 09:00:20 -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=t+fgrja2tIc1qJyKmlwDrOaJstu3JRf36EkOVx9ZniY=; b=GUDPCCV62FHmHS/CVpblprXi1tvijDV36wO/Ohq8l22CoiDug1GvIj4Y/JOdQ/Oyk3 u4SiIqQ9QVdaQ69Np1+piEDGCYccSf5nUdeFq4giJTAIFzngCJTVVWgy06dnDfOJKURw TyHFfKGzg/Z7iiulUC/1kO9IUcoGMRvhOmWuOGDXtFG9sfkLxm1jU4yJgvP6ZkQf0NRp 4UkK7BFjeHF3xa1ylpDKlGyRSSFfhOGdRvvmCL0F7++cLu+GCaVA4UjHzI/x58OPAd6G Gevo/B0yz+RF7Ij4U25dIeQqVbcGfmxb2A4L4LaCszn/287/xLEAsn0ti7/zaA11pFbN d/jg==
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=t+fgrja2tIc1qJyKmlwDrOaJstu3JRf36EkOVx9ZniY=; b=S/y+NRH3M4ABlGXbshRXo5IlQdJhSaohct4lpIEx2LC0ahmm+PP6qB6/m6tG0tyUtX jgrBOuFZmnL+BiDjwMDrkKvirSjGrTK+qdPMS+ANGr38m//q352JfPkWanb79x3qFUCg k3NHeIYDXimkBL9vjO1Yk5pLUiw5lH7xa07VCrfR5Siq3IV5xRGapYLgP6vIbuF8eVCY gGXm/c+OnYQrSVgkTNYmFAOiLamPJB0Fia5Dha8qcEzUjnfmVk6tlMelq47deFSEsXcO dzg4JljGBWq/ZgRwq8z0q29Y4miL44BjUcTR2kZNxUHLdZYPAf9ADU6d11WhHIdRF708 nOOg==
X-Gm-Message-State: AODbwcDiE5qPJ9ddpF+BWnl+R2bKER7BdS8ZJ2Kc4QaBcbmlzkcT4hG0 X6LdQpjxaGhnVs5QLp3CM9ZLVHwB7usd
X-Received: by 10.223.183.31 with SMTP id l31mr509460wre.115.1495728018233; Thu, 25 May 2017 09:00:18 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.132.195 with HTTP; Thu, 25 May 2017 09:00:17 -0700 (PDT)
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@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>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 25 May 2017 09:00:17 -0700
Message-ID: <CALx6S34dQX8gGCLvR4OG70FfO7MY8CbOxB_CA-crcTmFE_zX3g@mail.gmail.com>
To: Xuxiaohu <xuxiaohu@huawei.com>
Cc: Joe Touch <touch@isi.edu>, "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/RRElSfvoLH5JU9judxMOoJM_4uY>
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: Thu, 25 May 2017 16:00:26 -0000

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.

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

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.

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