Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt]

James Carlson <carlsonj@workingcode.com> Mon, 24 January 2011 20:39 UTC

Return-Path: <carlsonj@workingcode.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 4DBF33A6962 for <pppext@core3.amsl.com>; Mon, 24 Jan 2011 12:39:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.33
X-Spam-Level:
X-Spam-Status: No, score=-102.33 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, 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 UknR-0-8GbSV for <pppext@core3.amsl.com>; Mon, 24 Jan 2011 12:39:05 -0800 (PST)
Received: from carlson.workingcode.com (carlsonj-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1d9::2]) by core3.amsl.com (Postfix) with ESMTP id 34F703A692C for <pppext@ietf.org>; Mon, 24 Jan 2011 12:39:05 -0800 (PST)
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 p0OKftqF009445 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 24 Jan 2011 15:41:55 -0500 (EST)
Message-ID: <4D3DE413.80908@workingcode.com>
Date: Mon, 24 Jan 2011 15:41:55 -0500
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: <20110106154501.15655.20204.idtracker@localhost> <4D334595.3030507@workingcode.com> <4D3DADF9.4040009@gmail.com> <4D3DB16B.5080803@workingcode.com> <4D3DC516.1000105@gmail.com> <4D3DCD97.7040005@gmail.com>
In-Reply-To: <4D3DCD97.7040005@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-DCC-x.dcc-servers-Metrics: carlson; whitelist
Cc: pppext@ietf.org, rbridge@postel.org
Subject: Re: [Pppext] working group last call for PPP TRILL protocol control protocol [was Re: I-D Action:draft-ietf-pppext-trill-protocol-02.txt]
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, 24 Jan 2011 20:39:06 -0000

William Allen Simpson wrote:
> I'm staring at the TRILL draft, and cannot find anything in the protocol
> to detect, eliminate, or resolve duplicate System ID numbers.  Obviously,
> I'm missing something.  Please advise.

I don't believe that anything can or will do that.  It's assumed into
existence, as far as I understand.

The System ID is used (among other things) for pseudonode generation and
TRILL nickname resolution.  If those aren't unique, then my
understanding is that the network will fly to bits.

I'm not the IS-IS expert here.  If someone else (preferably on the
RBridge mailing list) has an opinion about running a TRILL IS-IS network
where some of the nodes using only point-to-point links have System IDs
that are possibly non-unique, then now is the time to speak up.

But I certainly don't feel comfortable endorsing this sort of usage in
the PPP TRILL draft without review by at least the TRILL group, and
probably the IS-IS group as well.

> Thus, I got the routing religion....  Never use a bridge where a router
> could be used instead.

Indeed.  I agree completely, though I don't think it's really the
problem at hand.  If the user has PPP TRILL links, he's already decided
(for whatever reason) that he wants to bridge.

> Of course, this assumes that the PPP Magic Number has been implemented
> correctly, and it checks the number against all its interfaces to avoid
> loops.  It also assumes you haven't deployed Junipers with the fairly evil
> "ppp magic-number ignore-mismatch".

I see nothing in RFC 1661 section 6.4 requiring or even suggesting a
check across all of the node's interfaces.  Off hand, I don't know of
any that do that, and I do know of a few implementations where such a
test would be architecturally impractical (if not outright impossible).

In any event, I think this is a detour: the real issue is that the IS-IS
System ID must be unique across the IS-IS campus, and PPP's Magic-Number
option doesn't have that quality, even if it has the checks you're
suggesting.

With Ethernet, the assumption is that MAC addresses among systems that
speak IS-IS are unique per the standards.  Whether any vendor is able to
achieve that and/or whether relying on MAC uniqueness is a smart thing
to do is possibly an interesting topic, but I think is certainly one for
a different mailing list.  It doesn't involve PPP.

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