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 17:44 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 4FB22129B84 for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 10:44:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 7kCu9e5-aYgr for <int-area@ietfa.amsl.com>; Thu, 25 May 2017 10:44:48 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) (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 1C543127011 for <int-area@ietf.org>; Thu, 25 May 2017 10:44:48 -0700 (PDT)
Received: from [128.9.184.77] ([128.9.184.77]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v4PHiS8j018101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 25 May 2017 10:44:29 -0700 (PDT)
To: Tom Herbert <tom@herbertland.com>, Xuxiaohu <xuxiaohu@huawei.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> <CALx6S350VcJCm4g70jycbXD3FxaGg9eF-dn61_SdVF8xmmkojg@mail.gmail.com> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE2BBA95EA@NKGEML515-MBX.china.huawei.com> <CALx6S34dQX8gGCLvR4OG70FfO7MY8CbOxB_CA-crcTmFE_zX3g@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <d1c22f64-1cab-2946-32a6-4339a197402e@isi.edu>
Date: Thu, 25 May 2017 10:44:28 -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: <CALx6S34dQX8gGCLvR4OG70FfO7MY8CbOxB_CA-crcTmFE_zX3g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-MailScanner-ID: v4PHiS8j018101
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/majClUgvKsnGhehiSEg7122x660>
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 17:44:49 -0000
Hi, Tom, On 5/25/2017 9:00 AM, Tom Herbert wrote: > IPv4 and IPv6 can be directly encapsulated since they have a protocol > number (can be encapsulated by version 0). > > As I mentioned previously, Ethernet could be directly encapsulated via > EtherIP that has a 4 bit version number at the beginning of its > header. The way this would work is to set a version 1 pattern to > indicate EtherIP. For example, we could specify that 0101 would be > EtherIP. When GUE receives such a packet it will notice it's version > one and then see that it is EtherIP (differentiated from IPv4 0100 and > IPv6 0110 values). The first four bits are then overwritten by 0011 to > make it a valid EtherIP header and then the packet is resubmitted to > the stack as EtherIP. If you use the first 4 bits as the type identifier (which I think you should, as noted below), then you could easily support a bunch of encapsulations without needing the 4-byte overhead. E.g.: 0000 = GUE control (your "Version 0") 0100 = IPv4 0101 = IPv6 That leaves 13 other codes you can use for other protocols (including MPLS, Ethernet, etc.), as long as you burn at least those 4 bits. EtherIP effectively burns 2 bytes rather than 4 bits, but has the same net effect. > Transport protocols (TCP, UDP, SCTP) might also be nice to support > with direct encapsulation in version 1, but unfortunately since they > start with a variable port number there's no way to do that. That works the same way as EtherIP - burn at least 4 bits indicating the transport. Joe ------ >From my previous post: 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
- [Int-area] I-D Action: draft-ietf-intarea-gue-04.… internet-drafts
- [Int-area] Is the UDP destination port number res… Xuxiaohu
- Re: [Int-area] Is the UDP destination port number… Tom Herbert
- Re: [Int-area] Is the UDP destination port number… Joe Touch
- Re: [Int-area] I-D Action: draft-ietf-intarea-gue… Joe Touch
- [Int-area] 答复: Is the UDP destination port number… Xuxiaohu
- Re: [Int-area] 答复: Is the UDP destination port nu… Joe Touch
- [Int-area] 答复: 答复: Is the UDP destination port nu… Xuxiaohu
- Re: [Int-area] 答复: 答复: Is the UDP destination por… Joe Touch
- [Int-area] 答复: 答复: 答复: Is the UDP destination por… Xuxiaohu
- Re: [Int-area] 答复: Is the UDP destination port nu… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: Is the UDP destination… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: Is the UDP destination… Joe Touch
- Re: [Int-area] 答复: 答复: 答复: Is the UDP destination… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: Is the UDP destination… Joe Touch
- [Int-area] 答复: 答复: 答复: 答复: Is the UDP destination… Xuxiaohu
- [Int-area] 答复: 答复: Is the UDP destination port nu… Xuxiaohu
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Joe Touch
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Joe Touch
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Joe Touch
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Joe Touch
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Templin, Fred L
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Joe Touch
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Templin, Fred L
- [Int-area] 答复: 答复: 答复: 答复: 答复: Is the UDP destina… Xuxiaohu
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: 答复: 答复: Is the UDP des… Tom Herbert
- Re: [Int-area] 答复: 答复: 答复: 答复: Is the UDP destina… Joe Touch