Re: [rbridge] Proposed details for announcing endnodes

"Eastlake III Donald-LDE008" <Donald.Eastlake@motorola.com> Wed, 30 April 2008 17:05 UTC

Return-Path: <rbridge-bounces@postel.org>
X-Original-To: ietfarch-trill-archive-Osh9cae4@core3.amsl.com
Delivered-To: ietfarch-trill-archive-Osh9cae4@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36B323A6C26 for <ietfarch-trill-archive-Osh9cae4@core3.amsl.com>; Wed, 30 Apr 2008 10:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 F1fMuGJUp48X for <ietfarch-trill-archive-Osh9cae4@core3.amsl.com>; Wed, 30 Apr 2008 10:05:08 -0700 (PDT)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by core3.amsl.com (Postfix) with ESMTP id C0B993A6A6D for <trill-archive-Osh9cae4@lists.ietf.org>; Wed, 30 Apr 2008 10:05:08 -0700 (PDT)
Received: from boreas.isi.edu (localhost [127.0.0.1]) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id m3UGcN8k006429; Wed, 30 Apr 2008 09:38:24 -0700 (PDT)
Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by boreas.isi.edu (8.13.8/8.13.8) with SMTP id m3UGav7Z005315 for <rbridge@postel.org>; Wed, 30 Apr 2008 09:36:58 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: Donald.Eastlake@motorola.com
X-Msg-Ref: server-6.tower-128.messagelabs.com!1209573414!374593!1
X-StarScan-Version: 5.5.12.14.2; banners=-,-,-
X-Originating-IP: [144.189.100.102]
Received: (qmail 30375 invoked from network); 30 Apr 2008 16:36:55 -0000
Received: from motgate4.mot.com (HELO motgate4.mot.com) (144.189.100.102) by server-6.tower-128.messagelabs.com with SMTP; 30 Apr 2008 16:36:55 -0000
Received: from az33exr01.mot.com (az33exr01.mot.com [10.64.251.231]) by motgate4.mot.com (8.12.11/Motorola) with ESMTP id m3UGasSb004156 for <rbridge@postel.org>; Wed, 30 Apr 2008 09:36:54 -0700 (MST)
Received: from az10vts02.mot.com (az10vts02.mot.com [10.64.251.243]) by az33exr01.mot.com (8.13.1/Vontu) with SMTP id m3UGapAA026471 for <rbridge@postel.org>; Wed, 30 Apr 2008 11:36:52 -0500 (CDT)
Received: from de01exm64.ds.mot.com (de01exm64.am.mot.com [10.176.8.15]) by az33exr01.mot.com (8.13.1/8.13.0) with ESMTP id m3UGajVl026251 for <rbridge@postel.org>; Wed, 30 Apr 2008 11:36:46 -0500 (CDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 30 Apr 2008 12:35:46 -0400
Message-ID: <3870C46029D1F945B1472F170D2D979003C16562@de01exm64.ds.mot.com>
In-Reply-To: <4817EE69.6070209@isi.edu>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rbridge] Proposed details for announcing endnodes
thread-index: Aciqdo2fXlN14P+gTZy88JBk4/xqzwAYd9vw
References: <99f1ccaf6f3b.48120d44@sunlabs.com> <4C94DE2070B172459E4F1EE14BD2364E0153F1D3@HQ-EXCH-5.corp.brocade.com> <48169BD2.5060309@sun.com><4816ADBF.3070205@isi.edu> <48174FF0.7020306@cisco.com> <3870C46029D1F945B1472F170D2D979003C16366@de01exm64.ds.mot.com> <4817EE69.6070209@isi.edu>
From: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>
To: rbridge@postel.org
X-CFilter-Loop: Reflected
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: donald.eastlake@motorola.com
X-MIME-Autoconverted: from quoted-printable to 8bit by boreas.isi.edu id m3UGav7Z005315
Subject: Re: [rbridge] Proposed details for announcing endnodes
X-BeenThere: rbridge@postel.org
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: "Developing a hybrid router/bridge." <rbridge.postel.org>
List-Unsubscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=unsubscribe>
List-Archive: <http://mailman.postel.org/pipermail/rbridge>
List-Post: <mailto:rbridge@postel.org>
List-Help: <mailto:rbridge-request@postel.org?subject=help>
List-Subscribe: <http://mailman.postel.org/mailman/listinfo/rbridge>, <mailto:rbridge-request@postel.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: rbridge-bounces@postel.org
Errors-To: rbridge-bounces@postel.org

Hi Joe,

I partly agree with you and partly disagree. See below at @@@

-----Original Message-----
From: Joe Touch [mailto:touch@ISI.EDU] 
Sent: Tuesday, April 29, 2008 11:59 PM
To: Eastlake III Donald-LDE008
Cc: Dinesh G Dutt; rbridge@postel.org
Subject: Re: [rbridge] Proposed details for announcing endnodes

Eastlake III Donald-LDE008 wrote:
...
> (2) The purpose of Rbridges is to do better than bridges. Arguments of
> the form 'X is a known problem with bridges so we shouldn't solve it'
> seem odd when the main premise of Rbridges is 'spanning tree is a
known
> problem with bridges so we WILL solve it'.

My understanding is that the WG was created with a number of assumptions

that limit how and where rbridges do better than bridges.

@@@ Yes, there were assumptions. But I see these as simply setting goals
for the WG. While they may limit those goals, they do not "limit how and
where RBridges do better than bridges". That would be a limit on
results, not on goals.

Specifically, they do better in replacing spanning tree with 
Internet-style routing protocols.

@@@ They do. But the charter says very little about other performance
related goals or non-goals. It mostly speaks about scope in more general
terms, such as prohibiting the working group from designing a new
routing protocols. I would point out that the WG charter also
specifically states that the starting point is
draft-perlman-rbridge-03.txt which had extensive material on ARP
optimization, etc. The working group has decided to remove such IP
optimizations from the base protocol specification and make them into a
separate document, which is fine, but the effort would also have been
charter conformant if it had left such provisions in the base protocol
document and refined them.

Specifically, they do NOT:
	- scale better than bridges

@@@ As I say, I do not agree that there has been a decision, by the
TRILL working group or in its charter, that Rbridges MUST be no better
than bridges in scaling. It is just not particularly a goal of the group
to have them scale better. Quite possibly they will scale better due to
some Rbridge routing tables scaling with the number of Rbridges rather
than the number of MAC addresses or some other reason.

	- handle dynamic endstation movement better
	- handle silent receiver movement better
	- fix any other deficiency in the 802 suite

@@@ I'd have no problem is you said "they need not" above instead of
"they do NOT". To, in effect, say that it is forbidden to include any
facet in the TRILL protocol which happens to improve scaling or the
handling of dynamic end station movement or the like seems to me to be
unsupported by either our charter or the discussions that have been
held.

@@@ Thanks,
@@@ Donald

I.e., TRILL is focused on the spanning tree issue. We're not here to fix

issues that are not created by our solution. We discussed this with 
respect to scale numerous times, but it seems like it's worth stating in

general.

Joe


_______________________________________________
rbridge mailing list
rbridge@postel.org
http://mailman.postel.org/mailman/listinfo/rbridge