Re: [trill] I-D Action: draft-ietf-trill-over-ip-10.txt

Joe Touch <touch@isi.edu> Fri, 02 June 2017 18:43 UTC

Return-Path: <touch@isi.edu>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1173C129A92 for <trill@ietfa.amsl.com>; Fri, 2 Jun 2017 11:43:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ujiBjoLzO59a for <trill@ietfa.amsl.com>; Fri, 2 Jun 2017 11:43:11 -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 1C823129544 for <trill@ietf.org>; Fri, 2 Jun 2017 11:43:11 -0700 (PDT)
Received: from [128.9.160.211] (mul.isi.edu [128.9.160.211]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id v52IgsfF027412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 2 Jun 2017 11:42:55 -0700 (PDT)
To: Donald Eastlake <d3e3e3@gmail.com>
Cc: "trill@ietf.org" <trill@ietf.org>
References: <149626897714.19836.7466806270075160460@ietfa.amsl.com> <CAF4+nEEcYOk7kw3PDHMwhqYqgXvQ2G_19-=XTs_AvpAs93my5A@mail.gmail.com> <dd4d81d0-6e58-5780-c57b-dd987f15d809@isi.edu> <CAF4+nEFyfJhA2W=iHzyQquCRBqcbKt1uY1jkQjO_tq+fyGHoUQ@mail.gmail.com>
From: Joe Touch <touch@isi.edu>
Message-ID: <40ac03d6-9ad5-5e4a-a4ad-fbcb2003398f@isi.edu>
Date: Fri, 02 Jun 2017 11:42:54 -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: <CAF4+nEFyfJhA2W=iHzyQquCRBqcbKt1uY1jkQjO_tq+fyGHoUQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-MailScanner-ID: v52IgsfF027412
X-ISI-4-69-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/x-GyMoH5M_0ZvF9EEPJpalhN8Ak>
Subject: Re: [trill] I-D Action: draft-ietf-trill-over-ip-10.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 02 Jun 2017 18:43:12 -0000

Hi, Donald,


On 6/2/2017 9:47 AM, Donald Eastlake wrote:
> Hi Joe,
>
> On Wed, May 31, 2017 at 6:37 PM, Joe Touch <touch@isi.edu> wrote:
>> Hi, all,
>>
>> I'm confused by the TCP encapsulation shown.
>>
>> If you place TRILL in TCP, you cannot ensure that the TRILL packets are aligned with the TCP headers. TCP is a bytestream, not message-oriented.
>>
>> I.e., you need to assume that TRILL packets could be split across TCP segments or multiple TRILL packets (or portions thereof) could be contained within a TCP segment. That means you will need a framing protocol that identifies the start of TRILL packets, and you should never assume that TRILL packets align with TCP segments.
>>
>> If you want to try to assume alignment of some sort, you need to discuss using RDMA, but that's a much bigger can of worms.
> Well, although I'm not sure it is all that difficult to do framing
> through TCP, for example BGP does it, I tend to agree with you.

BGP messages are framed (they include a marker, length, and type), so
they can be parsed out of a TCP bytestream. There is no expectation that
BGP messages align to segments.

> ...
>> Finally, regarding the IANA considerations, IMO the distinction between TRILL data and TRILL control needs to be indicated in-band, not via different port numbers. Ports should be requested only for services that are useful independently (RFC7605).
> That's not the TRILL architecture. 
Perhaps, but that represents a flaw in the architecture, not something
to be propagated IMO.

> On Ethernet, TRILL uses two
> Ethertypes. On PPP, TRILL uses two PPP code points. CAPWAP is another
> example of this. TRILL control is a use of IS-IS and could be used for
> other things than TRILL as long as they can be tunneled to the same
> extent as TRILL.
Using different port numbers complicates configuration and encourages
the potential for separate failures (e.g., one port is blocked but not
the other).

Whether TRILL control *could* be used in the future independently is
less an issue as whether it is specified as such right now.

Since you're creating a new shim for IP, you could easily clean this up,
and I would encourage considering that, FWIW.

>
>> (frankly, IMO, this system has gone off the rails out of control; you really ought to treat everything as running over Ethernet using the TRILL shim and call it a day; the rest should already be sufficiently handled by Ethernet-in-X encapsulation).
> Doing that wastes 12 or 16 bytes for every TRILL packet and these
> wasted bytes provide a covert channel which is not good from a
> security point of view. 
IMO, this perverts the concept of a TRILL campus. If that campus runs
over Ethernet (real or virtual, local or extended), then the messages
already ought to have those bytes (or need them reconstituted) anyway.

If you're really interested in saving bytes, then you should be
considering some sort of header compression, which could involve
soft-state with header reconstitution at the tunnel egress.

The specific encapsulations you're considering already exist for
Ethernet. IMO, you're adding only complexity and fragility.

Joe