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, 26 May 2017 01:52 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 69A3612EB05 for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 18:52:28 -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 O5t85WW3GUlP for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 18:52:26 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c: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 2E5B112EB04 for <int-area@ietf.org>; Thu, 25 May 2017 18:52:26 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id 7so111687936wmo.1 for <int-area@ietf.org>; Thu, 25 May 2017 18:52:26 -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=HDAbjTY3m+8YX1otPeF89SDJUOZWFLmS46m4b4D3IR8=; b=oTJ+YxC29rjF7545fnzCyobPwQXLePbhrVVtbkr3gkhsrTRV1h43xaY/YFcezIo5Sl PuQt3nuBdog85lBFhmVoCwXtVjNhm9lDPQPFCFzBar2RFwqFSgUOvNnBAf/wfo3FVggu CyxVZZ+jAmXQLUw9wWtDsMLETT8J5MNCu33/gvZNhpFcXnTPMUZzzRXQIZURE514SXQE yBpivHwnWcO7LnjEhzNMRaos1lSCsnTj+oylOugdpkPYU6rOPQSiaOKZPmXFAJtskiTR dzvThdfFVVke0yqE8bzm4Y9wcGWIGqO+JJQ2kfwQ1EvH2+E++aDjf4JtG3ZbK0bSfVXS lYrw==
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=HDAbjTY3m+8YX1otPeF89SDJUOZWFLmS46m4b4D3IR8=; b=ABnf7fkAXmcZzjJd7TSnCbwOUEiqzZeaX4Z/LRdc25qgrWnnpA5/OzKxyD4rmjvVIF JsO1IcuGJa6vIV9oFRmYYXCxV17IZzDywtN2/OhwyRSRsS5chUYl3f4jhX56BL9KyAqw eNK65cI8LWOYgQqe+VNEiM78BHBu0eTdlsP+muP9YYVBLcHIFXWxHC3abP02VQGAIu15 33tjnuo519iy9QT/MSI+ZZvqBPyU0b9HOx2VBo84Rl2VOVcynnUY+zsXKYXwCHd1e85l 0ssaJly4O//AvI3WChuUIR04M0uh6WzYnwIwNebx6dPdc5t9zYykcVQrvtV7gAoBoqfg llsw==
X-Gm-Message-State: AODbwcD1ATW/c3ZRzXKAWJmThzuYWRhl+uBOBInDWMhScPX+uCHz0epr fNgz7Odi0bUKi06eRn+lNO6nHj0Ig4aV
X-Received: by 10.28.139.69 with SMTP id n66mr265292wmd.60.1495763544625; Thu, 25 May 2017 18:52:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.132.195 with HTTP; Thu, 25 May 2017 18:52:23 -0700 (PDT)
In-Reply-To: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBAB24C@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> <CALx6S34dQX8gGCLvR4OG70FfO7MY8CbOxB_CA-crcTmFE_zX3g@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBAB24C@NKGEML515-MBX.china.huawei.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 25 May 2017 18:52:23 -0700
Message-ID: <CALx6S370pYa5WAEG0xFhsZO8ekW+GRurxROLkp7GBGzk8OFtkA@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/PZ1-ryjyrHrRodhbqZVoIgM2sxg>
Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSN?= =?utf-8?q?=3A__=E7=AD=94=E5=A4=8D=3A_Is_the_UDP_destination_port_number_r?= =?utf-8?q?esource_running_out=3F//_re=3A_I-D_Action=3A_draft-ietf-intarea?= =?utf-8?q?-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: Fri, 26 May 2017 01:52:28 -0000

On Thu, May 25, 2017 at 6:36 PM, Xuxiaohu <xuxiaohu@huawei.com> wrote:
> Tom,
>
>> -----邮件原件-----
>> 发件人: Tom Herbert [mailto:tom@herbertland.com]
>> 发送时间: 2017年5月26日 0:00
>> 收件人: 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 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.
>
> If so, it seems a little bit confused to claim it as a generic udp encapsulation.
>
>> IPv4 and IPv6 can be directly encapsulated since they have a protocol number
>> (can be encapsulated by version 0).
>
> If the possible payload types of GUE are limited to IPv4, IPv6 and MPLS, and these payloads need to be directly transported over UDP, the most simple way is to allocate a dedicated port number for IP since MPLS has already be assigned one (RFC7510), IMHO.
>
>> 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.
>
> To save the 4-byte GUE base header overhead when encapsulating Ethernet over UDP, you propose to insert the additional 16-bit EtherIP header between the UDP header and MAC frame?
>

That is already part of EtherIP (RFC3378).

Tom

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