Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip

Joe Touch <touch@isi.edu> Tue, 05 May 2015 19:34 UTC

Return-Path: <touch@isi.edu>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EE01ACDD3; Tue, 5 May 2015 12:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 fCTDgU9x3jYU; Tue, 5 May 2015 12:34:00 -0700 (PDT)
Received: from mail-b.isi.edu (boreas.isi.edu [128.9.160.161]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DFA1A87BD; Tue, 5 May 2015 12:34:00 -0700 (PDT)
Received: from [169.228.177.133] ([169.228.177.133]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id t45JXHkJ005267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 5 May 2015 12:33:26 -0700 (PDT)
Message-ID: <55491AFD.8000306@isi.edu>
Date: Tue, 05 May 2015 12:33:17 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Xuxiaohu <xuxiaohu@huawei.com>, Donald Eastlake <d3e3e3@gmail.com>, "trill@ietf.org" <trill@ietf.org>
References: <4552F0907735844E9204A62BBDD325E76ABADC85@nkgeml512-mbx.china.huawei.com> <CAF4+nEHSGYa+1DHzwee+RNgkXfZra_Pa9706vqpTGJV71SmDaw@mail.gmail.com> <CAF4+nEFcUL2ieQKCm98_0XxfrrAR0M11irVFfOfqa=92OM1V=A@mail.gmail.com> <5543D870.6080108@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A468@NKGEML512-MBS.china.huawei.com> <55479A6D.2040403@isi.edu> <1FEE3F8F5CCDE64C9A8E8F4AD27C19EE0832A7B7@NKGEML512-MBS.china.huawei.com> <2134F8430051B64F815C691A62D9831832E5A834@XCH-BLV-504.nw.nos.boeing.com> <5548F132.7050704@isi.edu> <2134F8430051B64F815C691A62D9831832E5A90F@XCH-BLV-504.nw.nos.boeing.com> <5549039C.2020709@isi.edu> <2134F8430051B64F815C691A62D9831832E5ABBE@XCH-BLV-504.nw.nos.boeing.com> <55490B41.2000207@isi.edu> <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com>
In-Reply-To: <2134F8430051B64F815C691A62D9831832E5AC5F@XCH-BLV-504.nw.nos.boeing.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/3t1XeA_gLwRb1c3d8qp3FtwAmBA>
Cc: "nvo3@ietf.org" <nvo3@ietf.org>, "int-area@ietf.org" <int-area@ietf.org>, "sfc@ietf.org" <sfc@ietf.org>
Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 May 2015 19:34:03 -0000


On 5/5/2015 11:47 AM, Templin, Fred L wrote:
> Hi Joe,
> 
>> -----Original Message-----
>> From: Joe Touch [mailto:touch@isi.edu]
>> Sent: Tuesday, May 05, 2015 11:26 AM
>> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org
>> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org
>> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip
>>
>>
>>
>> On 5/5/2015 11:04 AM, Templin, Fred L wrote:
>>> Hi Joe,
>>>
>>>> -----Original Message-----
>>>> From: Joe Touch [mailto:touch@isi.edu]
>>>> Sent: Tuesday, May 05, 2015 10:54 AM
>>>> To: Templin, Fred L; Xuxiaohu; Donald Eastlake; trill@ietf.org
>>>> Cc: nvo3@ietf.org; int-area@ietf.org; sfc@ietf.org
>>>> Subject: Re: [trill] Fwd: Mail regarding draft-ietf-trill-over-ip
>>>>
>>>>
>>>>
>>>> On 5/5/2015 9:39 AM, Templin, Fred L wrote:
>>>>> Hi Joe,
>>>> ..
>>>>>> IP in UDP adds only port numbers and an Internet checksum.
>>>>>>
>>>>>> That doesn't address fragmentation; if outer fragmentation is assumed,
>>>>>> IPv4 needs to be rate-limited to avoid ID collisions and the Internet
>>>>>> checksum is insufficient to correct those collisions.
>>>>>
>>>>> Right - that is why we have GUE. But, when these functions are not
>>>>> needed GUE can perform header compression and the result looks
>>>>> exactly like IP in UDP.
>>>>
>>>> That seems impossible.
>>>
>>> Not impossible - Tom Herbert provided the solution:
>>>
>>> http://www.ietf.org/mail-archive/web/int-area/current/msg04593.html
>>
>> That is allocating bits (or bit patterns) from the IP header.
>>
>> The solution provided - to check for 0x01 - is incorrect. IP can have
>> versions that include 0x10 and 0x11.
> 
> The version field in both IPv4 and IPv6 have that bit set to 1. If GUE
> then deems that bit to indicate "direct IP encapsulation, then there
> is no need for a GUE header of length greater than 0.
> 
> You may say that future IP protocol versions might not have that bit
> set in the version field. But, the version bits for IPv4 and IPv6 will
> never change (by definition) and we do not see a new IP protocol
> version replacing IPv4 or IPv6 on the near-term horizon.

0x01 is valid for four version numbers:
	4
	5
	6
	7

You cannot assume either that 0x01 always means IPv4 and IPv6 only OR
that any other pattern is NOT an IP packet UNLESS GUE is assigned the
values you are assuming (e.g., 0x00, 0x10, 0x11), and that's not going
to happen.

As I said on the other post:

	Codepoints you aren't assigned aren't yours to assume.

> Even if a new IP protocol version emerged with the "direct IP
> encapsulation" bit set to 0, that version can still be accommodated
> by GUE. It's just that direct encapsulation cannot be used and a
> non-zero-length GUE header is needed.

It's more than that - you need to ensure that all other IP values are
NOT interpreted as uncompressed.

Joe