Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destination port number resource running out?// re: I-D Action: draft-ietf-intarea-gue-04.txt

"Templin, Fred L" <Fred.L.Templin@boeing.com> Thu, 25 May 2017 19:44 UTC

Return-Path: <Fred.L.Templin@boeing.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 AA432127ABE for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 12:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
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 7me_2F3zyTKj for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 12:44:22 -0700 (PDT)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B83BE12700F for <int-area@ietf.org>; Thu, 25 May 2017 12:44:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v4PJiLVu021473; Thu, 25 May 2017 12:44:22 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (xch15-06-11.nw.nos.boeing.com [137.136.239.220]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v4PJiIVJ021425 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Thu, 25 May 2017 12:44:18 -0700
Received: from XCH15-06-08.nw.nos.boeing.com (2002:8988:eede::8988:eede) by XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 25 May 2017 12:44:17 -0700
Received: from XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) by XCH15-06-08.nw.nos.boeing.com ([137.136.238.222]) with mapi id 15.00.1263.000; Thu, 25 May 2017 12:44:17 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Joe Touch <touch@isi.edu>, Tom Herbert <tom@herbertland.com>
CC: "int-area@ietf.org" <int-area@ietf.org>
Thread-Topic: =?utf-8?B?W0ludC1hcmVhXSDnrZTlpI06IOetlOWkjTog562U5aSNOiAg562U5aSNOiBJ?= =?utf-8?B?cyB0aGUgVURQIGRlc3RpbmF0aW9uIHBvcnQgbnVtYmVyIHJlc291cmNlIHJ1?= =?utf-8?B?bm5pbmcgb3V0Py8vIHJlOiBJLUQgQWN0aW9uOiBkcmFmdC1pZXRmLWludGFy?= =?utf-8?Q?ea-gue-04.txt?=
Thread-Index: AQHS1YpZcMPCykwF7kes5feA57QyOqIFcv6w
Date: Thu, 25 May 2017 19:44:17 +0000
Message-ID: <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>
In-Reply-To: <85610864-3b00-67b3-6d3a-db1c4ef3870b@isi.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: multipart/alternative; boundary="_000_b1d251aff62c45d392c2ee8c1b3828b2XCH150608nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/3Ls6GED58SsnPXjF8vv90rA8hCQ>
Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06IOetlOWkjTogIOetlA==?= =?utf-8?q?=E5=A4=8D=3A_Is_the_UDP_destination_port_number_resource_runnin?= =?utf-8?q?g_out=3F//_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 19:44:25 -0000

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.

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