Re: [Pppext] proposed TRILL IS-IS System ID text

Donald Eastlake <d3e3e3@gmail.com> Mon, 31 January 2011 03:36 UTC

Return-Path: <d3e3e3@gmail.com>
X-Original-To: pppext@core3.amsl.com
Delivered-To: pppext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91E973A6B74 for <pppext@core3.amsl.com>; Sun, 30 Jan 2011 19:36:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.391
X-Spam-Level:
X-Spam-Status: No, score=-103.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bKZKYD9vjUC for <pppext@core3.amsl.com>; Sun, 30 Jan 2011 19:36:23 -0800 (PST)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 739413A6B62 for <pppext@ietf.org>; Sun, 30 Jan 2011 19:36:23 -0800 (PST)
Received: by wyf23 with SMTP id 23so5299704wyf.31 for <pppext@ietf.org>; Sun, 30 Jan 2011 19:39:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=lD/E62Kwd9eoNNuHCG42KNyQHfq48krMMry1fjwqnaE=; b=PNnxRJn87Wfl5Z/cTU7VlTcjUTcb7waV8Ak5Pi/mZSQvw8J1Yxu0v6J1MjQuxSNcql lHRABGQXVRnFKYEVJviBm7oRSQyweewt1s9/54AVTu7drn+qTddGlqvUdYsO7Urd1YZT Q7vCp9f3erqV9q4UP1x5GJ8/j6hr3Url/3PLw=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=jr7Jh7g2E39lxL0sVtSOezyC/rEVzK9h3wMx90LEGoaqb1U0CvMjSkjIFkeL/LnJcK KLqBPSoY1Smqoj0u3FxotNm/73qLkmEQhzZ3GUJhfBDI+aH1mAtmtkGxJP66TqzEYzFo gOHtlhg+GBB6ZECfh+SG9AENiDu24U4pA2htk=
Received: by 10.227.144.213 with SMTP id a21mr813865wbv.8.1296445175989; Sun, 30 Jan 2011 19:39:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.227.61.81 with HTTP; Sun, 30 Jan 2011 19:39:13 -0800 (PST)
In-Reply-To: <4D41D6DC.2040406@workingcode.com>
References: <4D415111.4010009@gmail.com> <4D41ABED.5070308@gmail.com> <4D41D6DC.2040406@workingcode.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sun, 30 Jan 2011 22:39:13 -0500
Message-ID: <AANLkTikppOVBJTmDchVr15s_3K6MCkrG51gTbUi9-CHn@mail.gmail.com>
To: pppext@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: rbridge@postel.org
Subject: Re: [Pppext] proposed TRILL IS-IS System ID text
X-BeenThere: pppext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: PPP Extensions <pppext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 31 Jan 2011 03:36:24 -0000

 On 01/27/11 12:31, William Allen Simpson wrote:
> On 1/27/11 6:03 AM, William Allen Simpson wrote:
>> 3. An implementation that has only PPP links might have no previously
>> configured Media Access Control (MAC) that can function as an
>> IS-IS System ID. In this case, the System ID is formed by adding
>> a randomly generated 14-bit leading number (in place of an OUI) to
>> the link's unique LCP Magic Number.

I think it is a very bad idea to mandate this method which, as far as
I know, is radically different from all methods currently in use. For
example, some manufacturers just allocate a 48-bit number related to
their MAC address space for each switch and use that as the System ID
regardless of the type of any switch interfaces or the MAC addresses
of any interfaces that have MAC addresses. Why should they change
their behavior just because it happens that they have all PPP
interfaces? Having all PPP interface is a state that could change
dynamically.

I would suggest, at a minimum, the following changes:
- Replace the beginning with something more like "An RBridge that has
only PPP interfaces might not have a conveniently available MAC
address from which a System ID that would be unique across the campus
can be derived. A possible statistical source of a System ID that
implementors may wish to consider would be formed by ...."

- Add a reference to [RFC4086] after "randomly generated".
- Add a reference to [RFC5342] after "OUI".
- The reference to "the link" is obviously problematic if their are
more than one. Suggest changing to "a link".

Even with the above changes, I'm pretty dubious.

>>   The Magic Number MUST be
>> unique for all links and all known link peers.

My impression from other posts is that you are not just trying to
change how people do IS-IS, but aspects of how they do PPP as well.

>>   This pseudo-MAC
>> MUST have both the "locally-assigned" and "broadcast/multicast"
>> (group) bits set to 1; that is, the least significant two bits of
>> the most significant octet are both set to 1.
>
> Looking at this again, and remembering how fanatic the new RFC Editors (TM)
> are about abbreviations, probably needs to expand OUI, too:
>
>                .... In this case, the System ID is formed by appending
>   the link's unique 32-bit LCP Magic Number after a randomly generated
>   14-bit number in place of an Organizationally Unique Identifier (OUI).

Sure.

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3@gmail.com