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

Joe Touch <touch@isi.edu> Thu, 25 May 2017 22:14 UTC

Return-Path: <touch@isi.edu>
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 D7CC1129AF1 for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 15:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] 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 Z2ifZ80hYuYb for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 15:14:45 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (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 D233C127B5A for <int-area@ietf.org>; Thu, 25 May 2017 15:14:45 -0700 (PDT)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id v4PMEPVR014753 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 15:14:36 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>, "Templin, Fred L" <Fred.L.Templin@boeing.com>
Cc: "int-area@ietf.org" <int-area@ietf.org>
References: <149514799195.6631.3231700013200014494@ietfa.amsl.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> <CALx6S34TqFoZHwiDJPeNhChLm5ceM6_dbkko4Uhy6MsT+snAKA@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <9657c82a-7314-878e-1559-cc81ed3c2241@isi.edu>
Date: Thu, 25 May 2017 15:14:25 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CALx6S34TqFoZHwiDJPeNhChLm5ceM6_dbkko4Uhy6MsT+snAKA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/E_t9K5kbgtKkR6ChxC8--GKmodM>
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 22:14:47 -0000


On 5/25/2017 1:40 PM, Tom Herbert wrote:
> 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
I continue to be confused as to why it is more useful to try to make
decisions based on the first two bits rather than the first four.
There's near zero benefit, and the harm is that you end up with only two
reserved versions.

>
> 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"
It is not a version; I think that's at least part of the problem. It's a
type or kind, but version implies that V0 is superceded by V1, which may
or may not be backward compatible with V0.

Joe