Re: [trill] I-D Action: draft-ietf-trill-over-ip-01.txt

Joe Touch <> Tue, 15 July 2014 17:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0A0081A0AD1 for <>; Tue, 15 Jul 2014 10:30:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RP2xPiJFelTA for <>; Tue, 15 Jul 2014 10:30:01 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C06A51A0ABB for <>; Tue, 15 Jul 2014 10:30:01 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s6FHTeqa024782 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 15 Jul 2014 10:29:40 -0700 (PDT)
Message-ID: <>
Date: Tue, 15 Jul 2014 10:29:40 -0700
From: Joe Touch <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Donald Eastlake <>, "" <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
Subject: Re: [trill] I-D Action: draft-ietf-trill-over-ip-01.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 15 Jul 2014 17:30:04 -0000

On 7/15/2014 10:01 AM, Donald Eastlake wrote:
> Hi Joe,
> Sorry for delay in response. I was traveling and am now being kept
> busy at a meeting in San Diego.
> On Mon, Jul 14, 2014 at 1:12 PM, Joe Touch <> wrote:
>> Hi, Donald,
>> I raised these concerns at the time the doc was proposed as a WG item, and
>> these issues were never really addressed. ...
> Well, you get to decide whether you believe your concerns have been
> adequately addressed.

First of all, I raised concerns during the WG confirmation of consensus 
during the last IETF. Since there was NO response, it's very clear my 
concerns were not addressed at all.

> And the WG Chairs get to decide what the
> consensus of the WG is. None of your concerns have been, in my
> opinion, technical, in the sense of arguing that something will not
> work or will not be interoperable.

The need for yet another layer of encapsulation, and the complexity that 
entails, is absolutely technical.

 > Your concerns appear to me to be
> matters of opinion, such as whether something is "needed", on which
> reasonable people might have different opinions.

Necessity can be demonstrated. Your jumping to the conclusion that, in 
the absence of need, it's a matter of opinion as to whether a new 
protocol is appropriate or not. I agree, but only if you're claim is 
that there is no demonstrable need.

> To the extent that your concern is that someone will think that using
> TRILL over IP somehow, in itself, significantly changes TRILL's
> scaling characteristics, I do not think there is anything in this
> draft or any TRILL document saying that a choice of link protocol on
> one or more links in a TRILL campus will do that. In any case I'd be
> fine with adding a sentence or two to Section 2 of the draft,
> clarifying this.

I think that would help. However, that's independent of whether TRILL 
goes over an existing Ethernet-over-IP solution or a TRILL-specific UDP 

>> I see your points about keying, zero-config, etc., but those argue for a new
>> layer to support TRILL use of existing encapsulation, not for a totally new
>> encapsulation.
> I do not agree with your analysis. Creating a "new layer" seems to me
> to be a lot of unnecessary work compared with using the method of
> transporting X over IP by using UDP of which there are multiple
> examples.

You are creating a new layering here, but you're also importing a bunch 
of stuff you don't necessarily need to re-specify. TRILL runs over 
Ethernet. Ethernet already runs over lots of things.

Is this WG intending to develop a TRILL-over-X specification for every X 
for which there is an Ethernet-over-X specification?

If so, it strongly suggests that TRILL has a significant architectural 
flaw. Either it runs over Ethernet or not. If it does, it should run 
over anything Ethernet runs over - without the need for anything else.

>> Although I appreciate the IESG's "let a thousand flowers bloom" viewpoint,
>> the result is a thousand wheels get reinvented, and it's nearly impossible
>> to ensure that past mistakes are not repeated.
> I don't think that there are 1,000 link protocols and I don't think
> that a guarantee that no mistake be made should be a condition for a
> standards effort.
> In any case, the TRILL WG has thus far specified how to send TRILL
> directly over 2 technologies, Ethernet (RFC6325) and pseudowires
> (RFC7172), and the PPPEXT WG specified how to send TRILL over PPP
> (RFC6361).

It would have been more useful to specify Ethernet over PPP.

 > This draft would increase the universe of link protocols
> directly, interoperable, and efficiently usable by TRILL for 3 to 4 by
> adding IP, which seems to me to be a particularly prominent and widely
> deployed technology.

The key issue being ignored is that Ethernet already runs over IP (using 
GRE, among others), and that TRILL thus already runs over IP.

By specifying this, you just add yet another mechanism, one that the 
uninformed would think is necessary, but is clearly not.

 > I do not remember any proposal being made thus
> far in the TRILL WG for any further TRILL over X standards track
> documents.

Why not? Surely TRILL over SONET is useful. How about TRILL over 
powerline? TRILL over coax?