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> Sat, 20 May 2017 23:18 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 B7DC9129601 for <int-area@ietfa.amsl.com>; Sat, 20 May 2017 16:18:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 eV67FHvG9O9H for <int-area@ietfa.amsl.com>; Sat, 20 May 2017 16:18:02 -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 60DC5128656 for <int-area@ietf.org>; Sat, 20 May 2017 16:18:02 -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 v4KNGorC013485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 20 May 2017 16:17:13 -0700 (PDT)
To: Xuxiaohu <xuxiaohu@huawei.com>, Tom Herbert <tom@herbertland.com>
Cc: "int-area@ietf.org" <int-area@ietf.org>
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>
From: Joe Touch <touch@isi.edu>
Message-ID: <52d4e918-16cb-67fe-f217-e4398b8d3a8b@isi.edu>
Date: Sat, 20 May 2017 16:16:45 -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: <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA892E@NKGEML515-MBX.china.huawei.com>
Content-Type: multipart/alternative; boundary="------------3957FB09AE2DB674DF555076"
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/2utELyyRKh1eJ9JN6iYgCdLTZyc>
Subject: Re: [Int-area] =?utf-8?b?562U5aSNOiDnrZTlpI06ICDnrZTlpI06IElzIHRo?= =?utf-8?q?e_UDP_destination_port_number_resource_running_out=3F//_re=3A_I?= =?utf-8?q?-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: Sat, 20 May 2017 23:18:04 -0000


On 5/19/2017 11:09 PM, Xuxiaohu wrote:
>> 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. 
GUE is one service that includes both encapsulation of IP packets and
signaling.
Frankly, it seems like it would work anywhere IP works - where IPv0 is
defined as the signalling channel (which is sufficient because IPv0
isn't defined).

In that case, the first field after v0 needs to be a signal channel
version number, to allow for future updates.

>
>> 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, 
They don't and they shouldn't. That would complicate forwarding - a
single service needs to use a single port. Using separate ports
complicates configurations - this is a case where you want "fate
sharing" (either both IP encapsulation and the signal channel work or
neither do).

> I don't know why there is still a need to demultiplex GUE and IP-in-UDP.
The point of GUE is an IP encapsulation channel with in-band signalling.
That is a single service, IMO.

Note - AFAICT, GUE could work anywhere an IP packet works. IP packets
always start with a version number, and v0 isn't really defined.
Defining v0 as the signal channel is the same thing as how GUE is
currently specified.

Joe