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> Sun, 21 May 2017 00:08 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 3FA1D129AB8 for <int-area@ietfa.amsl.com>; Sat, 20 May 2017 17:08:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 rDH7KRdhkPVg for <int-area@ietfa.amsl.com>; Sat, 20 May 2017 17:08:51 -0700 (PDT)
Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 B94A5129AB6 for <int-area@ietf.org>; Sat, 20 May 2017 17:08:51 -0700 (PDT)
Received: by mail-qk0-x22a.google.com with SMTP id k74so84527548qke.1 for <int-area@ietf.org>; Sat, 20 May 2017 17:08:51 -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=aJZk/+bz6Gh0v67SELFmEB1cb7o1GOPMPr8B4aAUNXM=; b=T0VK8UTlBOcuwD57O6QGnUBi9hsxfn5fq0OaTw9Y5+Fza0d+xP6A5Pdp4YKeVQkcKX GV7meFTVZk2yJv/7ejVYjfgyo9H0kPBv4Cv0CeWNs1byU2oRPn74vPRURveoriXIcz8W i6iiSaeSqE3IZ0Y49NN0pSjyCj2TpokHwbR5zQgFSE9Y1Jjt+speDCLKaNYltgRW/4B/ akZXy3d6vd18znCqjf9GQVmJkeX6vBu57dU0en6qZA82SXHXgjn+lUiigydkgu+bxUFP 7PB2yGw8fyOOviUK8tW67O3mKMQIuayyetofZT8mRE0kHD2lybG+1FBB45zkb05AvCj5 0cAg==
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=aJZk/+bz6Gh0v67SELFmEB1cb7o1GOPMPr8B4aAUNXM=; b=oaiSjo84aRtyiZPGevJChf9l71FhAr+EwOFziTgg23o1j2Yc3K2e72CaBuLcWoZYqp 2+dwnQzSnyrHpDk8VDzy3AwZ/BRlrb7UFF2I0xkY8I6gpcD88uN1NTuks/i+FG4bXMpH ir2E6rkIRe3z5uc59a+7mT+nFtYteKACtpRVlV9NYFIkK613WoRQCimZStZ9g/M0OAHE g+osxCGmgf8cmoPgvnzvC1LiBuF14r8z0VyEHE7CkrUpeivbcbM473iynABWUfceHDOM uzwmXt6/9LjEU6DOHg7yrwheTXg/7my7077sS5xj80vCJW5QG0ZH9af1LqmMTmS5UNd3 fXGA==
X-Gm-Message-State: AODbwcDFMxVWwSj2N5PSLABEh2R4bGHp1EjtE7ZTQOHdguTleCV6P4xk pqDhdlvh3OubROVzSjvHcJ5mYpKVffgz
X-Received: by 10.55.92.199 with SMTP id q190mr12373635qkb.286.1495325330785; Sat, 20 May 2017 17:08:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.97.10 with HTTP; Sat, 20 May 2017 17:08:50 -0700 (PDT)
In-Reply-To: <52d4e918-16cb-67fe-f217-e4398b8d3a8b@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> <52d4e918-16cb-67fe-f217-e4398b8d3a8b@isi.edu>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 20 May 2017 17:08:50 -0700
Message-ID: <CALx6S35H7yMSUjtuXbXxuOjzVuYXZKTe6WnRvc=HzddXkR4FbQ@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/86sFp6NyOX_v8RwWT7VZT5EgumQ>
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: Sun, 21 May 2017 00:08:53 -0000

On Sat, May 20, 2017 at 4:16 PM, Joe Touch <touch@isi.edu> wrote:
>
>
> 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, I'm not sure I understand your point about IPv0. GUE v0
encapsulates packets of any IP prolocol number (IP, GRE, MPLS,
EtherIP. ...) and allows for data messages as well as control
messages. GUE v1 directly encapsulates IPv4 and IPv6 in a form of
header compression. Where would we use IPv0?

Tom

> Joe
>