Re: [Pppext] TRILL, IS-IS, and System ID

James Carlson <carlsonj@workingcode.com> Wed, 01 June 2011 14:54 UTC

Return-Path: <carlsonj@workingcode.com>
X-Original-To: pppext@ietfa.amsl.com
Delivered-To: pppext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC29E07D1 for <pppext@ietfa.amsl.com>; Wed, 1 Jun 2011 07:54:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.781
X-Spam-Level:
X-Spam-Status: No, score=-102.781 tagged_above=-999 required=5 tests=[AWL=-0.182, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWjasFyqbO3A for <pppext@ietfa.amsl.com>; Wed, 1 Jun 2011 07:54:11 -0700 (PDT)
Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by ietfa.amsl.com (Postfix) with ESMTP id 88535E07DC for <pppext@ietf.org>; Wed, 1 Jun 2011 07:54:10 -0700 (PDT)
Received: from [10.50.23.149] (gate.abinitio.com [65.170.40.132]) (authenticated bits=0) by carlson.workingcode.com (8.14.2+Sun/8.14.4) with ESMTP id p51Es3bv008414 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Jun 2011 10:54:04 -0400 (EDT)
Message-ID: <4DE6528B.7070501@workingcode.com>
Date: Wed, 01 Jun 2011 10:54:03 -0400
From: James Carlson <carlsonj@workingcode.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: William Allen Simpson <william.allen.simpson@gmail.com>
References: <4DE51FC3.2070301@workingcode.com> <BANLkTikrJ217TLvKz61mCBcacgQUs317MA@mail.gmail.com> <4DE63C68.9070102@gmail.com>
In-Reply-To: <4DE63C68.9070102@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-DCC-Misty-Metrics: carlson; whitelist
Cc: PPP Extensions <pppext@ietf.org>, rbridge@postel.org, Stewart Bryant <stbryant@cisco.com>
Subject: Re: [Pppext] TRILL, IS-IS, and System ID
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pppext>, <mailto:pppext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pppext>
List-Post: <mailto:pppext@ietf.org>
List-Help: <mailto:pppext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pppext>, <mailto:pppext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jun 2011 14:54:11 -0000

William Allen Simpson wrote:
> Therefore, James is also wrong.  This is not an operator issue.  You
> should *NOT* put this burden on operators.  It would really help for
> anybody with aspirations of designing protocols to have actually been an
> operator, and pay attention to discussions on the NANOG list!

It's worth noting that I said "implementor" not "operator."  Perhaps the
language I'm using isn't clear.  By "implementor," I mean the person who
designs the hardware and software components that will be sold as a
product claiming to support TRILL.  I do not mean the person who buys
these products and installs them in a network.

Like you, I do not believe that it's appropriate or reasonable for
general-purpose TRILL implementations to require any sort of action on
the part of the person installing and using the equipment -- that is,
the "operator."  I've never suggested that as a solution, so the straw
man doesn't work here.  Nor do the ad-hominem jibes.

However, unlike you, I do not believe that the IETF must resolve this
potential system-level design issue.  Instead, I still strongly prefer
to leave it up to the people designing and building systems.  If they
can't resolve this relatively simple problem in a reasonable way then,
frankly, I have no faith that they can get any of the other million or
so complex system design decisions right.

Most importantly, I don't want to be dictating anything about IS-IS
design issues from within the PPP Extensions working group.  It's just
not appropriate or even feasible.  That's why I agree with the ideas
behind Stewart Bryant's text.

All that said, I don't really care.  This is a tempest in a teapot.  I
can mash together both texts if the Routing ADs are willing to accept a
passing reference here to a draft that, in their words, hasn't even been
considered by the IS-IS community.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>