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

Christian Hopps <chopps@rawdofmt.org> Mon, 06 June 2011 16:09 UTC

Return-Path: <chopps@rawdofmt.org>
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 BD6FE11E8170; Mon, 6 Jun 2011 09:09:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.203
X-Spam-Level:
X-Spam-Status: No, score=-102.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, 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 XE13aB3E5t75; Mon, 6 Jun 2011 09:09:15 -0700 (PDT)
Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1273E11E817A; Mon, 6 Jun 2011 09:09:15 -0700 (PDT)
Received: by pzk5 with SMTP id 5so2177592pzk.31 for <multiple recipients>; Mon, 06 Jun 2011 09:09:14 -0700 (PDT)
Received: by 10.68.22.197 with SMTP id g5mr2065311pbf.254.1307376554528; Mon, 06 Jun 2011 09:09:14 -0700 (PDT)
Received: from rtp-chopps-8711.cisco.com (rtp-isp-nat1.cisco.com [64.102.254.33]) by mx.google.com with ESMTPS id p5sm3771950pbd.92.2011.06.06.09.09.11 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 06 Jun 2011 09:09:13 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Christian Hopps <chopps@rawdofmt.org>
In-Reply-To: <4DE644F8.5060800@cisco.com>
Date: Mon, 6 Jun 2011 12:09:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <11EFD6B0-5CD7-4D4A-890F-59AE7C52AFD5@rawdofmt.org>
References: <4DE51FC3.2070301@workingcode.com> <BANLkTikrJ217TLvKz61mCBcacgQUs317MA@mail.gmail.com> <4DE63C68.9070102@gmail.com> <4DE644F8.5060800@cisco.com>
To: stbryant@cisco.com
X-Mailer: Apple Mail (2.1084)
X-Mailman-Approved-At: Mon, 06 Jun 2011 09:13:00 -0700
Cc: PPP Extensions <pppext@ietf.org>, rbridge@postel.org, Christian Hopps <chopps@rawdofmt.org>, "isis-wg@ietf.org list" <isis-wg@ietf.org>, William Allen Simpson <william.allen.simpson@gmail.com>
Subject: Re: [Pppext] [Isis-wg] 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: Mon, 06 Jun 2011 16:09:15 -0000

[Adding in correct isis-wg address..]

On Jun 1, 2011, at 9:56 AM, Stewart Bryant wrote:

> Bill
> 
> The discussion of suitable methods of ISIS and hence TRILL
> SystemID uniqueness needs to take place on the ISIS list
> (copied) regardless of the data link technology under
> consideration.
> 
> James I am fine with your proposed text.
> 
> Stewart
> 
> 
> 
> On 01/06/2011 14:19, William Allen Simpson wrote:
>> Obviously, Stewart is wrong.  We've gone to great lengths to ensure PPP is
>> zero configuration.  We never need to buy and burn IEEE MAC identifiers.
>> 
>> TRILL seems to have zero configuration design goals, too.
>> 
>> 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!
>> 
>> As a personal example, just last summer I spent *many* hours trying to
>> figure our what was happening as a political campaign couldn't get their
>> wireless access point to work.  It was very flaky.  At long last, traces
>> discovered that the AP had a conflicting MAC with another device at
>> another office somewhere else in the Comcast region.  You cannot expect
>> political operatives (and quite frankly any other business) to fix this.
>> 
>> Therefore, this is a protocol design issue.  I've been trying to live with
>> the various compromises on language, but this goes too far!
>> 
>> Technically, that MUST is certainly wrong.  There's no guarantee of
>> uniqueness, and uniqueness is required by both ISIS and TRILL.
>> 
>> Moreover, there's no guarantee that a hot swappable or card or board based
>> device will not become (even temporarily) a PPP-only device.  To meet that
>> MUST, every vendor of PPP devices will have to burn an IEEE number for
>> every device.  Yet, it still might not work!
>> 
>> That's simply wrong!  There's a lot of nonsense in IETF protocols, but we
>> don't have to add more here and now.
>> 
>> 
>> On 5/31/11 2:20 PM, Donald Eastlake wrote:
>>> James,
>>> 
>>> I'm fine with your suggested tweak of Stewart Bryant's wording.
>>> 
>>> Thanks,
>>> Donald
>>> =============================
>>>  Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>>  155 Beaver Street
>>>  Milford, MA 01757 USA
>>>  d3e3e3@gmail.com
>>> 
>>> 
>>> On Tue, May 31, 2011 at 1:05 PM, James Carlson<carlsonj@workingcode.com>  wrote:
>>>> As part of IETF review, the Routing ADs are looking over
>>>> draft-ietf-pppext-trill-protocol-06.  Not too surprising to me -- given
>>>> that I still think it's far out of scope -- the text concerning IS-IS
>>>> System IDs is causing trouble in that review.  See this thread:
>>>> 
>>>> http://www.ietf.org/mail-archive/web/rtg-dir/current/threads.html#01533
>>>> 
>>>> I wish I could leave the worms safely in the can, but it's looking like
>>>> that might not be one of the options.
>>>> 
>>>> Instead of the reference to Bill Simpson's draft, Stewart Bryant
>>>> suggested replacement text like this:
>>>> 
>>>>  ISO/IEC 10589 states that it is the responsibility of the routeing
>>>>  domain administrative authority to enforce the uniqueness of the
>>>>  system ID. In cases where a zero configuration system is
>>>>  supplied the system manufacturer MUST install a suitable
>>>>  unique identifier at manufacturing time. One way to achieve
>>>>  this is for the manufacturer to use a unique IEEE MAC address
>>>>  following the allocation procedures normally used in the
>>>>  manufacture of an Ethernet interface.
>>>> 
>>>> This tosses the issue back into the implementor's lap (which,
>>>> incidentally, is exactly where I think the problem belongs), and
>>>> suggests an existing and known solution where a MAC identifier may be
>>>> allocated for the system itself and used as a global ID to construct the
>>>> necessary IS-IS System ID.
>>>> 
>>>> For use in this draft, I would alter the wording slightly to indicate
>>>> that zero-configuration is strongly preferred for TRILL (as guidance),
>>>> and that obtaining a suitable identifier is the implementor's
>>>> responsibility, rather than just saying "in cases where."
>>>> 
>>>> Would this change fly without breaking consensus?  Or do we have to
>>>> start over?
>>>> 
>>>> -- 
>>>> James Carlson         42.703N 71.076W<carlsonj@workingcode.com>
>>>> _______________________________________________
>>>> Pppext mailing list
>>>> Pppext@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/pppext
>>>> 
>>> _______________________________________________
>>> Pppext mailing list
>>> Pppext@ietf.org
>>> https://www.ietf.org/mailman/listinfo/pppext
>>> 
>> 
>> 
> 
> 
> -- 
> For corporate legal information go to:
> 
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg