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 18:47 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 8D50312AF84 for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 11:47:58 -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 wayaFmg-RxVL for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 11:47:56 -0700 (PDT)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (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 6F3F112AF6E for <int-area@ietf.org>; Thu, 25 May 2017 11:47:56 -0700 (PDT)
Received: by mail-wm0-x233.google.com with SMTP id d127so109102608wmf.0 for <int-area@ietf.org>; Thu, 25 May 2017 11:47:56 -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; bh=e3n1No5zDeUlbGdIs1guDf1Yu3P3mVl15qjdTukgl5w=; b=nBNXIG8vYM7kx4wY5ssCKiIBf5DPRF/W3k84G/vda8bCPYI0069C2I0LJ+E3z/GD79 bPSAB+sSmbpE7Wpcg4nsXfEu2vE0I+Ub9JU29oqLKcvPuryvXaBLf37t9LvvZ5TzWqOu 3V2eV7Zibf17DMz9BGPnQQEnoCAb9Q5OWX7K6oPMWFhcfXejKTSLnQWnjaeKcBbBg+By moarMK+XdAOObNvhzE6z0sqV2Rp6IRJ7hn13h2smgxVK3teH2KvKgMVeipMjZDWuK47w oLRqfRwpIGItFt6AfmOAgKQYvt3h3Nb7TDHWktHoWEvNrJ/A4wXfl5C+37RP9AVCjtGr 7qEg==
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; bh=e3n1No5zDeUlbGdIs1guDf1Yu3P3mVl15qjdTukgl5w=; b=jChIYN/ku6bxc3VSLaZSHz7SUsjlj+fmicHnCedyj0bPSrjpy3P4oTykwNQ6Br1u5r 8cN4kAlkjQgTNqi6e5RyVe1WQFL4hVa4nuczh0dlgc92nRwq9+CPAfd3nGkUs2l6TwVG M7h57H49SjsVnC+1i0fDS1sE7rZFs1L4Vh3x4lPpZ4hmL9aWtheL3jEVzQaLybWDVWxF j/xjYYsb5hT7E2x/S77NQQO54ueWjjzdzEaJeuF8sQaw/9Sts2CaiAI5i4VwyL98f/63 Nt0M/Q5A/m3dJnm2wGIevPu9y6UDSSxTxtPkIqN0beVlkorS24O+HQ8iUc54p4LOG5D2 2LSw==
X-Gm-Message-State: AODbwcAWk0BUfS3CU8uhjzc25xJAb6zF41qFryjvMeoM4M5qGCyfyC+o DDM85ZGaTjbhA0bOxwpA0rie+yFDeuSl
X-Received: by 10.223.160.68 with SMTP id l4mr22733342wrl.52.1495738074765; Thu, 25 May 2017 11:47:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.132.195 with HTTP; Thu, 25 May 2017 11:47:54 -0700 (PDT)
In-Reply-To: <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu>
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> <d1c22f64-1cab-2946-32a6-4339a197402e@isi.edu> <CALx6S365N44zV=-N3BgA9ATibfqW5G78_4cDD4EnL1muDoA04Q@mail.gmail.com> <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 25 May 2017 11:47:54 -0700
Message-ID: <CALx6S37SQivoYNsPnQOCvG2UpNk=_7rThD5rQP3gPmwqx+1siA@mail.gmail.com>
To: Joe Touch <touch@isi.edu>
Cc: Xuxiaohu <xuxiaohu@huawei.com>, "int-area@ietf.org" <int-area@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/TA3-jQR6OXTO9ACBb7nXg9vvxck>
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 18:47:59 -0000

On Thu, May 25, 2017 at 11:33 AM, Joe Touch <touch@isi.edu> wrote:
>
>
> On 5/25/2017 11:27 AM, Tom Herbert wrote:
>> On Thu, May 25, 2017 at 10:44 AM, Joe Touch <touch@isi.edu> wrote:
>>> Hi, Tom,
>>>
>>> On 5/25/2017 9:00 AM, Tom Herbert wrote:
>>>> 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.
>>> If you use the first 4 bits as the type identifier (which I think you
>>> should, as noted below), then you could easily support a bunch of
>>> encapsulations without needing the 4-byte overhead.
>>>
>>> E.g.:
>>>     0000 = GUE control (your "Version 0")
>>>     0100 = IPv4
>>>     0101 = IPv6
>>>
>>> That leaves 13 other codes you can use for other protocols (including
>>> MPLS, Ethernet, etc.), as long as you burn at least those 4 bits.
>>>
>> Right, although even with 00 for version zero there's still enough for
>> ten other codes which is a lot.
>
> Yes, but there's very little benefit in looking at 2 bits vs 4. That
> would matter only for serial processing and saves far too little to be
> worthwhile IMO. It also complicates the way the protocol is described (I
> personally find it confusing; it's a lot more obvious to just say that
> you use IPv0 for control, IPv1 for encapsulation, and other IP versions
> are included without overriding headers).
>
>>
>>> EtherIP effectively burns 2 bytes rather than 4 bits, but has the same
>>> net effect.
>>>
>>>> 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.
>>> That works the same way as EtherIP - burn at least 4 bits indicating the
>>> transport.
>> EtherIP begins with a fixed version number, for the transport
>> protocols we would be overwriting the source port with no way to
>> recover the bits.
> You can't put bare Ethernet inside GUE. You need to use EtherIP -
> exactly because it has a 16-bit field, of which only the first 4 bits
> are (already) defined.
>
> My point is that EtherIP burns 16 bits vs bare Ethernet, but those 16
> bits allow it to be mapped to one of the IP versions (you picked IPv5).
> The same trick works for UDP and TCP - just pick a different 16 bit
> pattern for each one.
>
Inserting two bytes before the TCP header breaks four byte alignment
of the header which is a bigger hit than the benefit of saving two
bytes. A nice side effect of the two byte header in EtherIP is that it
aligns the Ethernet payload (e.g. an IP header) to four bytes.
Maintaining this four byte alignment is still important to some CPU
architectures most notably Sparc, but can even be problematic to x86
under certain circumstances.

Tom

> The catch is that EtherIP and these corresponding tricks for UDP and TCP
> end up burning 16 bits more than the bare packet would, but that's still
> less than the GUE encapsulation header burns.
>
> Joe
>>
>>> Joe
>>>
>>> ------
>>> From my previous post:
>>>
>>> When we look at the first 2 bits of a GUE packet, we see:
>>>     00 = GUE version 0
>>>     01 = IPv4 or IPv6
>>>     10 = undefined
>>>     11 = undefined
>>>
>>> That's nearly the same as looking at the first 4 bits as simply the IP
>>> version number, and defining some of the unused IP versions as control:
>>>     0000 (IPv0) = GUE control
>>>     0001 (IPv1) = GUE control
>>>     0010 (IPv2) = GUE encapsulation using the GUE header
>>>     0011 (IPv3) = GUE encapsulation using the GUE header
>>>     0100 (IPv4) = direct encapsulation of IPv4, with no intervening GUE
>>> header
>>>     0101 (IPv5) = direct encapsulation of IPv5 (ST), with no interveni
>>> GUE header
>>>     0110 (IPv6) = direct encapsulation of IPv6, with no intervening GUE
>>> header
>>>     0111 (IPv7) = direct encapsulation of IPv7 (TP/IX), with no
>>> intervening GUE header
>>>     1000 (IPv8) = direct encapsulation of IPv8 (PIP), with no
>>> intervening GUE header
>>>     1001 (IPv9) = direct encapsulation of IPv9 (TUBA), with no
>>> intervening GUE header
>>>     1010 (IPv10) = direct encapsulation of IPv10, when assigned
>>>     1010 (IPv11) = direct encapsulation of IPv11, when assigned
>>>     1010 (IPv12) = direct encapsulation of IPv12, when assigned
>>>     1010 (IPv13) = direct encapsulation of IPv13, when assigned
>>>     1010 (IPv14) = direct encapsulation of IPv14, when assigned
>>>     1010 (IPv15) = direct encapsulation of IPv15, when assigned
>>>
>>> I.e., all you're basically doing is defining the first four version
>>> numbers of IP as your control plane. Unless we come back and assign them
>>> in the future, any mechanism that encapsulates IP packets (which should,
>>> IMO, be able to handle ALL IP versions, by definition) should be able to
>>> include GUE-style signaling.
>>>
>> Right, this scheme could work to generally encapsulate different IP
>> versions. There is a caveat though: AFAIK there is no IP protocol
>> number to encapsulate any IP protocols other then IPv4 (IPIP 94) and
>> IPv6 (IPv6 encapsulates 41). GUE encapsulates IP protocols which means
>> they need a protocol number. Version 1 is header compression for
>> version 0 so the there must be a way to encapsulate the protocol using
>> version 0. What would resolve that is a new IP protocol number for
>> encapsulating a packet of any IP version and use the IP version itself
>> to differentiate.
>>
>> Tom
>>
>>> IMO, it's simpler to explain this all using this fixed-field
>>> demultiplexer - in which case, you could even use just the IPv0 pattern
>>> for control and the IPv1 pattern for encapsulation using the GUE header,
>>> leaving the IPv2 and IPv3 equivalent patterns for future expansion.
>>>
>>> Joe
>>>
>>>
>