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 20:40 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 26B39127871 for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 13:40:32 -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 On6qtp7YAsrl for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 13:40:30 -0700 (PDT)
Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (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 7580F126C23 for <int-area@ietf.org>; Thu, 25 May 2017 13:40:30 -0700 (PDT)
Received: by mail-wm0-x236.google.com with SMTP id 7so105629880wmo.1 for <int-area@ietf.org>; Thu, 25 May 2017 13:40:30 -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=oWFvxu4ltNfehFRPlYD+dHytH2sv0bzrJ7ARzp3LuqQ=; b=KOVpKtuAtdM3z3451EQRd8XW/2viXF1NXVITDy2U2G8Kb1vw4G2DaBHjfAq+opQ89U LPDNt0yHez/dL+/odx+R8eNu4LTdPoGlz8xshqz0ONr2SNegjRah9pOb/m+C/TE+TQe7 eotdK3cBA8vrW/qJTv2zR79yVvOSQ5lBT6FVRWPbzsADoG/dWrfZtHK6MP3gBV9b6srW JhP1k/1FnF2vs7qV2L2MuV13s65RMM7I+Is5POilXWF1V9AlnfJoesyKUvKiOOHiJh4s 5fLyffyxjaWUvFOSvlnuiVaKqZ0kIKKAxMywBnAgZXFCvUxVWJaCXZWR7PpnrCP2ub5M LyBA==
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=oWFvxu4ltNfehFRPlYD+dHytH2sv0bzrJ7ARzp3LuqQ=; b=dOQFEUZg4B0IbUWd8fZMklAuuk5Vrbory1GuTO1WhKp+x0dIhnQd40I7V4KEluztA2 QPQ9duMCaSZddvOWyvsTJpZKibCYcM/eWVL3vz3rxpCDnubD6djCHZ02P+4N1Nq0YCgu WsyWrRXWXtRt7iQIdKU8hVp8RzQdom1yGmnhlOPMdZ6US9DJJ41FEfDxKwNMiWj/NTmQ +FASI7sfZMGU0R8sSAMm98Vd52VH75YB80bAVKq7Cmun2ve+Dr4rZf/1zZNoqYfhzg60 M7S4wWdYhsIuSdbMTm0TE5xgsey6TS1CdPgyR23DuJezofssWziQVuew6r6M2/4EYwpB 8otA==
X-Gm-Message-State: AODbwcB56XPkEZ+Ww83VzrMmUlG3kd7hFvXeb5aoIVkwHeSAKrjv6iyG kVNT74Bfus45wo8BBuZTFwf28ARY+lTO
X-Received: by 10.223.183.31 with SMTP id l31mr1224376wre.115.1495744828936; Thu, 25 May 2017 13:40:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.223.132.195 with HTTP; Thu, 25 May 2017 13:40:28 -0700 (PDT)
In-Reply-To: <b1d251aff62c45d392c2ee8c1b3828b2@XCH15-06-08.nw.nos.boeing.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> <d1c22f64-1cab-2946-32a6-4339a197402e@isi.edu> <CALx6S365N44zV=-N3BgA9ATibfqW5G78_4cDD4EnL1muDoA04Q@mail.gmail.com> <7b56cfb4-87a9-a3c0-98ab-19acfed01da5@isi.edu> <CALx6S37SQivoYNsPnQOCvG2UpNk=_7rThD5rQP3gPmwqx+1siA@mail.gmail.com> <85610864-3b00-67b3-6d3a-db1c4ef3870b@isi.edu> <b1d251aff62c45d392c2ee8c1b3828b2@XCH15-06-08.nw.nos.boeing.com>
From: Tom Herbert <tom@herbertland.com>
Date: Thu, 25 May 2017 13:40:28 -0700
Message-ID: <CALx6S34TqFoZHwiDJPeNhChLm5ceM6_dbkko4Uhy6MsT+snAKA@mail.gmail.com>
To: "Templin, Fred L" <Fred.L.Templin@boeing.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/yyKl-ikhholwnG1rh_Mym1Gu0Vk>
Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTog562U5aSN?= =?utf-8?q?=3A_Is_the_UDP_destination_port_number_resource_running_out=3F/?= =?utf-8?q?/_re=3A_I-D_Action=3A_draft-ietf-intarea-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: Thu, 25 May 2017 20:40:32 -0000

On Thu, May 25, 2017 at 12:44 PM, Templin, Fred L
<Fred.L.Templin@boeing.com> wrote:
> If you are talking about the GUE direct encapsulation of IPv4 and IPv6, I
> agree
>
> with the current spec and that direct encapsulation (i.e., with no
> additional
>
> encapsulations between the IP/UDP and inner IP headers) is desirable and
>
> should remain as part of the spec. I think we may be over-thinking this.
>
+1. I think a little too much has been inferred beyond the what is
actually in draft. Versions are straightforward:

- There is a two bit version number field that begins GUE header. The
format of the rest of the header depends on the version.
- Version 0 defines an encapsulation header that encapsulates by IP
protocol number.
- Version 1 defined a means for direct encapsulation of select
protocols as an optimization. Formats for IPv4 and IPv6 are defined.
- Version 2 and 3 are reserved

Rather Version 1 constitutes a new version or a different format seems
to be a matter of terminology, however semantically and implementation
wise the intent is clear. If it's necessary the field could be renamed
"version/format"

Tom

>
>
> Fred
>
>
>
> From: Int-area [mailto:int-area-bounces@ietf.org] On Behalf Of Joe Touch
> Sent: Thursday, May 25, 2017 12:08 PM
> To: Tom Herbert <tom@herbertland.com>
> Cc: int-area@ietf.org
> Subject: Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destination port number
> resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt
>
>
>
>
>
>
>
> On 5/25/2017 11:47 AM, Tom Herbert wrote:
>
> 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
>
> Sure - I'm not sure the 4-byte penalty is worth avoiding any nearly any
> case, frankly -- even for IP.
>
> Joe