Hi Joe,

On Wed, May 31, 2017 at 6:37 PM, Joe Touch <[email protected]> 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 protected]

> 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 protected]
>
> On Wed, May 31, 2017 at 6:16 PM, <[email protected]> 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 protected]
> https://www.ietf.org/mailman/listinfo/trill
>
>

_______________________________________________
trill mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trill

Reply via email to