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> Sun, 21 May 2017 00:41 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 3ADAD129ADD for <int-area@ietfa.amsl.com>; Sat, 20 May 2017 17:41:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.501
X-Spam-Level:
X-Spam-Status: No, score=-5.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 LF7ncXO2JV9i for <int-area@ietfa.amsl.com>; Sat, 20 May 2017 17:41:01 -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 1EEBA126B6E for <int-area@ietf.org>; Sat, 20 May 2017 17:41:01 -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 v4L0eUCI011269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sat, 20 May 2017 17:40:40 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>
Cc: Xuxiaohu <xuxiaohu@huawei.com>, "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> <52d4e918-16cb-67fe-f217-e4398b8d3a8b@isi.edu> <CALx6S35H7yMSUjtuXbXxuOjzVuYXZKTe6WnRvc=HzddXkR4FbQ@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <8ac04a6b-75a9-e39a-0a94-c345182f99cd@isi.edu>
Date: Sat, 20 May 2017 17:40:29 -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: <CALx6S35H7yMSUjtuXbXxuOjzVuYXZKTe6WnRvc=HzddXkR4FbQ@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/XX3Ea3ioaeQdvPhTTzUneePM_EY>
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:41:02 -0000


On 5/20/2017 5:08 PM, Tom Herbert wrote:
> 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
When we look at the first 2 bits of a GUE packet, we see:
    00 = GUE version 0
    01 = IPv4 or IPv6
    10 = undefined
    11 = undefined

That's nearly the same as looking at the first 4 bits as simply the IP
version number, and defining some of the unused IP versions as control:
    0000 (IPv0) = GUE control
    0001 (IPv1) = GUE control
    0010 (IPv2) = GUE encapsulation using the GUE header
    0011 (IPv3) = GUE encapsulation using the GUE header
    0100 (IPv4) = direct encapsulation of IPv4, with no intervening GUE
header
    0101 (IPv5) = direct encapsulation of IPv5 (ST), with no intervening
GUE header
    0110 (IPv6) = direct encapsulation of IPv6, with no intervening GUE
header
    0111 (IPv7) = direct encapsulation of IPv7 (TP/IX), with no
intervening GUE header
    1000 (IPv8) = direct encapsulation of IPv8 (PIP), with no
intervening GUE header
    1001 (IPv9) = direct encapsulation of IPv9 (TUBA), with no
intervening GUE header
    1010 (IPv10) = direct encapsulation of IPv10, when assigned
    1010 (IPv11) = direct encapsulation of IPv11, when assigned
    1010 (IPv12) = direct encapsulation of IPv12, when assigned
    1010 (IPv13) = direct encapsulation of IPv13, when assigned
    1010 (IPv14) = direct encapsulation of IPv14, when assigned
    1010 (IPv15) = direct encapsulation of IPv15, when assigned

I.e., all you're basically doing is defining the first four version
numbers of IP as your control plane. Unless we come back and assign them
in the future, any mechanism that encapsulates IP packets (which should,
IMO, be able to handle ALL IP versions, by definition) should be able to
include GUE-style signaling.

IMO, it's simpler to explain this all using this fixed-field
demultiplexer - in which case, you could even use just the IPv0 pattern
for control and the IPv1 pattern for encapsulation using the GUE header,
leaving the IPv2 and IPv3 equivalent patterns for future expansion.

Joe