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

Joe Touch <touch@isi.edu> Fri, 11 July 2014 23:44 UTC

Return-Path: <touch@isi.edu>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740FF1A0070 for <trill@ietfa.amsl.com>; Fri, 11 Jul 2014 16:44:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.251
X-Spam-Level:
X-Spam-Status: No, score=-4.251 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4eiD34dOuGK for <trill@ietfa.amsl.com>; Fri, 11 Jul 2014 16:44:04 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9CF1A006F for <trill@ietf.org>; Fri, 11 Jul 2014 16:44:04 -0700 (PDT)
Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s6BNhWtb005197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Fri, 11 Jul 2014 16:43:32 -0700 (PDT)
Message-ID: <53C076A4.7070906@isi.edu>
Date: Fri, 11 Jul 2014 16:43:32 -0700
From: Joe Touch <touch@isi.edu>
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 <d3e3e3@gmail.com>, "trill@ietf.org" <trill@ietf.org>
References: <20140704111902.18356.26893.idtracker@ietfa.amsl.com> <53BC708F.3070708@isi.edu> <CAF4+nEFh8i9g37xvEvX6eaJVdcyu7gcY3R7BeFn-X60Q-gMRrA@mail.gmail.com>
In-Reply-To: <CAF4+nEFh8i9g37xvEvX6eaJVdcyu7gcY3R7BeFn-X60Q-gMRrA@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: http://mailarchive.ietf.org/arch/msg/trill/Vmr6mjClZfUL24XLGyAVzPgqzlg
Subject: Re: [trill] I-D Action: draft-ietf-trill-over-ip-01.txt
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Jul 2014 23:44:06 -0000

Hi, Donald,

On 7/11/2014 1:02 PM, Donald Eastlake wrote:
> On Tue, Jul 8, 2014 at 6:28 PM, Joe Touch <touch@isi.edu> wrote:
>> Hi, all,
>
> Hi Joe,
>
> First off, I'd like to thank you for your contributions to this draft.
> In particular, section 10.1 on Recursive Ingress was included in
> response to comments that, as I recall, came primarily from you.

I can't find any posts I made that were involved in this topic other 
than to question its necessity.

>> I don't see TRILL as needing a specific solution, given ethernet can already
>> be bridged using IP any number of ways (including GRE or L2VPN approaches).
>
> Well, I suppose you would get different answers from different people
> as to whether or not having convenient default security keying
> leveraging IS-IS keying, zero configuration under some circumstances,
> saving 14 or 18 or so bytes on every packet, having protection against
> recursive ingress, etc., are worth it.

I saw some of those come up two years ago when I asked the same question 
before this was adopted by the WG.

 > But in the context of TRILL,
> this has already been decided.TRILL over IP is specifically part of
> the work in the TRILL Charter, that Charter was approved by the TRILL
> WG and the IESG, it has been determined that there is a TRILL WG
> consensus to use UDP encapsulation, and, in my opinion, most of the
> work, although not all of it, has already been done as per this draft.

It can be decided, but that doesn't mean it has been addressed within 
the document. The document fails to explain why this is needed vs. the 
numerous ways to extend L2 over L3.

I would strongly suggest an extended discussion of the need for this 
solution as a key part of this document - esp. vs. other known approaches.

I would also strongly suggest a discussion of the limitations of this 
approach, i.e., that it should NEVER be used to extend the number of 
components or geographic distribution beyond that which L2 can support. 
I recall that being a core part of the TRILL problem statement that has 
been lost in the weeds.

Joe