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

From: Donald Eastlake <[email-masked]>
Date: Fri, 2 Jun 2017 12:47:24 -0400

Hi Joe,

On Wed, May 31, 2017 at 6:37 PM, Joe Touch <[email-masked]> 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. Unless
there are comments to the contrary, we can remove this TCP
encapsulation. It was an interesting exercise adding it because it
revealed several places where the document was unnecessarily
restrictive concerning transport.

> 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. 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.

> (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. Designing an encapsulation for a particular
transport is generally more efficient and provides better service but
the question is whether it is worth the effort or complexity. The
existing TRILL RFCs and Charter contemplate designing exactly 4
encapsulations: Ethernet, PPP, pseudowires, and IP. Only IP remains to
have be completed. In retrospect, I'm not sure it was worth doing PPP
but, in my opinion, Ethernet, pseudowires, and IP are worth it.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> Joe
>
>
>
> On 5/31/2017 3:24 PM, Donald Eastlake wrote:
>
> Hi,
>
> This revision has relatively minor changes to add an optional TCP based encapsulation.
>
> Thanks,
> Donald
> ===============================
>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>  155 Beaver Street, Milford, MA 01757 USA
>  [email-masked]
>
> On Wed, May 31, 2017 at 6:16 PM, <[email-masked]> wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transparent Interconnection of Lots of Links of the IETF.
>>
>>         Title           : TRILL (Transparent Interconnection of Lots of Links) over IP
>>         Authors         : Margaret Cullen
>>                           Donald Eastlake
>>                           Mingui Zhang
>>                           Dacheng Zhang
>>         Filename        : draft-ietf-trill-over-ip-10.txt
>>         Pages           : 41
>>         Date            : 2017-05-31
>>
>> Abstract:
>>    The TRILL (Transparent Interconnection of Lots of Links) protocol
>>    supports both point-to-point and multi-access links and is designed
>>    so that a variety of link protocols can be used between TRILL switch
>>    ports. This document specifies transmission of encapsulated TRILL
>>    data and TRILL IS-IS over IP (v4 or v6). so as to use an IP network
>>    as a TRILL link in a unified TRILL campus. This document updates RFC
>>    7177 and updates RFC 7178.
>>
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-trill-over-ip/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-trill-over-ip-10
>> https://datatracker.ietf.org/doc/html/draft-ietf-trill-over-ip-10
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-trill-over-ip-10
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>
>
>
> _______________________________________________
> trill mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trill
>
>

---

From: Joe Touch <[email-masked]>
Date: Fri, 2 Jun 2017 11:42:54 -0700

Hi, Donald,

On 6/2/2017 9:47 AM, Donald Eastlake wrote:
> 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.

> ...
> 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
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.

> 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