Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10

Joe Touch <> Fri, 02 February 2018 17:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 74909129C5D; Fri, 2 Feb 2018 09:56:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qk0erc1U0Z1P; Fri, 2 Feb 2018 09:56:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 05E4D124239; Fri, 2 Feb 2018 09:56:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mWpGBYkfoTYDJZOOMBkXcIv8aLgjpbr8NBUBeCNep8g=; b=2Tf+UKlE2h68MT04mdpJ69ynb yQbKqOaxTznw9AGnOBPvTocKLUFCQmoSCXXSdDlpyegHZElmc7fu8+OsGbjVlet9JyXE3JhlUlS9Z 7tO2PhsG4yHRZXJvcFKjxp+k105ZoIgLiys+UI9CAyQxbzM1VAGbv/YeXu08IQpIlchTiP6wGzpU6 3MQdIE92US6k7aXBDh8CsXqdcZYMwouTwWOTUhwNNgHNXZE2gQs+DaLUFPRaieji1DG1ztIdIIf2m J6VU9c/mSf8rectA2pOQ6/tIEi8RqNnY8IDj65i0ycqZ4EigpSQsaJo6PtZ35T1vqT1V1hWcVbWh+ lKmK6yQDg==;
Received: from [] (port=52275 helo=[IPv6:2607:fb90:8507:8674:dc03:d2dd:5e1b:d08f]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from <>) id 1ehfZN-004F3N-KZ; Fri, 02 Feb 2018 12:56:16 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Joe Touch <>
X-Mailer: iPhone Mail (15D60)
In-Reply-To: <046e01d39c49$9db0ed40$d912c7c0$>
Date: Fri, 2 Feb 2018 09:56:12 -0800
Cc: Magnus Westerlund <>, Donald Eastlake <>,, trill IETF mailing list <>,, Alia Atlas <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <046e01d39c49$9db0ed40$d912c7c0$>
To: Susan Hares <>
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [trill] Tsvart early review of draft-ietf-trill-over-ip-10
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 02 Feb 2018 17:56:41 -0000

Hi Susan,

> On Feb 2, 2018, at 9:16 AM, Susan Hares <> wrote:
> 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?   

I’m indicating the doc fails to justify the required use of IP-level security for a transport encapsulation solution. 

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

Trill goes inside TCP or UDP in this doc. For that part of the path anything that protects that payload is sufficient. If the payload needs to be protected elsewhere ie before or after this transit then that is a separate issue. 

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

None of this is relevant to my comment. 

> 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 [] On Behalf Of Joe Touch
> Sent: Friday, February 2, 2018 10:34 AM
> To: Magnus Westerlund
> Cc: Donald Eastlake;; trill IETF mailing list;
> 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