Re: [Pppext] [rbridge] 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> Wed, 26 January 2011 21:35 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 45A763A6893 for <pppext@core3.amsl.com>; Wed, 26 Jan 2011 13:35:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.464
X-Spam-Level:
X-Spam-Status: No, score=-102.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 q3VkkgOSDIAD for <pppext@core3.amsl.com>; Wed, 26 Jan 2011 13:35:44 -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 2CA123A6873 for <pppext@ietf.org>; Wed, 26 Jan 2011 13:35:44 -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 p0QLca5L021550 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Jan 2011 16:38:36 -0500 (EST)
Message-ID: <4D40945C.1070906@workingcode.com>
Date: Wed, 26 Jan 2011 16:38:36 -0500
From: James Carlson <carlsonj@workingcode.com>
User-Agent: Thunderbird 2.0.0.22 (X11/20090605)
MIME-Version: 1.0
To: Donald Eastlake <d3e3e3@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> <4D3DE413.80908@workingcode.com> <4D3E00B9.7050509@gmail.com> <4D3E247D.9090201@workingcode.com> <AANLkTi=+K-Kzsc+kahrmBoj1oC0WBzj7DYquS5ySCpP6@mail.gmail.com> <4D3F13B3.9070706@workingcode.com> <AANLkTikJjMcc1es7qyabddcXBFS93sRwcRO7XvPQzbe2@mail.gmail.com> <4D3F1EAD.5040901@workingcode.com> <4D4065F2.3080305@gmail.com> <AANLkTimi5vsYbGb0QXhyg_jdE2aCPKkUL9Y_Qj=g0Jpo@mail.gmail.com>
In-Reply-To: <AANLkTimi5vsYbGb0QXhyg_jdE2aCPKkUL9Y_Qj=g0Jpo@mail.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, William Allen Simpson <william.allen.simpson@gmail.com>
Subject: Re: [Pppext] [rbridge] 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: Wed, 26 Jan 2011 21:35:45 -0000

Donald Eastlake wrote:
> I don't understand why you say that. Seem to me that TRILL over PPP
> just involves the formats, code points, and PPP procedures. Anyway, it
> isn't clear to me that anyone will build a practical RBridge that
> doesn't have a MAC address Ethernet interface even if it is just a
> virtual internal interface for a virtual internal end station. If that
> doesn't exist, you can't really address the RBridge for management or
> maintenance.

Sure, you could.  It would just have to be addressed via IP (e.g., via
SNMP, ssh, or even TELNET) rather than by something locked into Ethernet.

One could imagine a large TRILL bridge designed for telecom applications
exclusively on the interior of the cloud, where the only possible links
are point-to-point; no Ethernet need apply.

Whether anyone ever builds that beast -- and, if so, whether it lacks
any built-in mechanism for automatic System ID assignment -- is a
different question.

What we're really discussing is whether failing to cover this case with
some sort of automatic resolution is a hole in the specification (as I
think Mr. Simpson is contending), or whether it's just an unlikely
corner that implementors should be warned away from (as I believe).

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