These links weren’t hard to find. That shouldn’t be surprising - there have 
been line-rate hardware encapsulated and encrypted Ethernet links for a while 

They include GRE over IPsec, among others.

The points I want to make are brief:
        - this solution isn’t remotely needed because *existing* commercial 
devices and protocols are sufficient
        - the solution as described is incoherent from a transport perspective

Fixing the title and/or polling vendors won’t change the above.

This document, in its current form, is unnecessary and incorrect. If nobody 
else can see why, then there are bigger problems than I can fix here.


> On Feb 19, 2018, at 4:35 PM, Susan Hares <> wrote:
> Joe: 
> Thank you for the post on cavium’s and Cisco’s GRE.   I hope the vendors with 
> TRILL products and these hardware devices will investigate this solution.  
> However, the suggestion IPSEC + upper layers came from those vendors with 
> TRILL products.  
> As to the name, I acknowledge the issue.  If you have a proposed solution 
> that you think fits,  we’re listening (Alia, Jon, I and the authors) are 
> listening.  The document title can change during the IETF LC process.    
> Sue 
> From: Joe Touch [] 
> Sent: Monday, February 19, 2018 4:40 PM
> To: Susan Hares
> Cc: trill IETF mailing list;; Alia Atlas
> Subject: Re: [trill] WG LC on draft-ietf-trill-over-ip-14.txt - Consensus 
> reached
> On Feb 19, 2018, at 1:06 PM, Susan Hares < 
> <>> wrote:
> Greetings: 
> Thank you for your comments on the draft-ietfd-trill-over-ip-xx.txt   The WG 
> has reached consensus on the draft, and it will be sent forward to the IESG. 
> I want to thank Magnus Westlund, Ines Robles, and Joe Touch for their 
> targeted reviews.  
> Joe asked two important questions that I want to chat about in announcing the 
> result.  
> 1)      Why IPSEC + TCP/UDP tunnels 
> 2)      Why the name TRILL over IP? – it is really TRILL over IP enabled 
> Transport port protocols 
> During this WG LC, I spent time looking back into my notes to check our 
> evaluation of the alternatives GRE, TLS, or DLTS.  I also asked the  WG 
> leadership team (Jon, Sue, and Donald with Alia Atlas help) to discuss these 
> points that Joe raised.     Here’s what I found. 
> 1)      Why IPSEC and TCP/UDP tunnels
> After I walked through the WG archives, I found that over several IETFs we 
> debated TLS, DTLS, and GRE.   Our most substantive debate was at IETF 91.   
> The WG had settle on utilizing GRE, TLS, or DLTS – until hardware vendors 
> implementing TRILL came to chat with the WG at IETF 91.   The hardware 
> vendors asked that we would utilize IPSEC and higher layer tunnels (TCP/UDP) 
> so that TRILL switches could operate at line speed using these IPSEC 
> processing chips off board.  The WG decided to listen to vendor creating and 
> deploying TRILL capable devices. 
> The hardware vendors reasoning still seems valid to the WG chairs and the 
> WGs.   If in the future hardware comes up with TLS, DTLS or GRE at Ethernet 
> switch line rates and vendors want a TRILL product with these tunnels, I’m 
> sure that a Routing AD or  the RTGWG draft will sponsor such a draft.  
> <>
> <>
>> 2)      Is the name TRILL over IP valid? 
>> Now as to the name, Joe was correct the name should be changed since it is 
>> really TRILL over IPSEC + Transport.   Donald’s make the change to the title 
>> of the document, and in the document.   
> “IP transport” implies using IP as a tunneling layer, which is not part of 
> this document’s proposed approach.
> Further, the description of how it interacts with TCP is incoherent to anyone 
> familiar with TCP transport (“slicing” packets and claiming to place them 
> directly into TCP payloads).
> Joe

trill mailing list

Reply via email to