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 <[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. 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 _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
