Joe: As WG chair, I need to manage the last of the WG calls for the TRILL. We are closing the TRILL WG and pushing to handle all the drafts in an effective manner. Therefore, I am going to be more blunt that I normally am.
Are you asking to utilize TLS/DTLS instead of IPSEC tunnel mode on a link? Are you suggesting to run a routing protocol should intermix with data forwarding without security? If you are asking a draft to be rewritten at this point to explain these issues, I would like some substantiating background or theory from the routing side to indicate why you feel TLS/DTLS is better than an IPSEC tunnel or that a routing protocol should not be protected within a secure tunnel against data traffic. The directions you are asking to document has not be successful in routing IGPs or path vector protocols. If you are suggesting a tutorial is added to a protocol document, provide operational reasons why this should be contained within a TRILL protocol specification. If you feel that these reasons for these choices should be document in an independent draft, then you are welcome to suggest this to Alia Atlas. I'm sure that Donald Eastlake will consider an independent draft explain reasons if Alia Atlas thinks it is useful. I will hold the WG LC for trill-over-ip until Monday morning at noon ET (9am PT) while you start a focused discussion on this topic. By Monday at noon ET, this discuss needs to come to a conclusion. Sue Hares Trill co-chair -----Original Message----- From: trill [mailto:trill-boun...@ietf.org] On Behalf Of Joe Touch Sent: Friday, February 2, 2018 10:34 AM To: Magnus Westerlund Cc: Donald Eastlake; tsv-...@ietf.org; trill IETF mailing list; draft-ietf-trill-over-ip....@ietf.org Subject: Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10 Hi, all, This doc is very confusing. Its title and discussion throughout indicates “TRILL over IP”, including figs in Sec 4, but the only actual encapsulations described are TRILL over UDP and TRILL over TCP. IMO, this needs a very deep scrub to resolve. It would help to understand that the root issue is that the encapsulation headers are *all* those added to the TRILL packet trying to transit the IP network; there’s no “inserting” of encapsulation between IP and TRILL. That includes: - explaining why you require IPsec tunnel mode, when the encapsulations presented would be completely secure using TLS/DLS or any variant of IPsec on the encapsulated traffic - explaining the relation between TRILL MTU discovery and the MTU of the transport level, and how these interact (or could interfere) with each other - why are not other more obvious encapsulations being considered, notably any TCP/UDP encapsulation that already supports Ethernet, including GRE (which might then allow this doc to be condensed to instructions for configuration, rather than trying to specify a new encapsulation system) Joe _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill _______________________________________________ trill mailing list trill@ietf.org https://www.ietf.org/mailman/listinfo/trill
