[rbridge] Proposed details for announcing endnodes

[Eastlake III Donald-LDE008]

Hi Joe,

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

-----Original Message-----
From: Joe Touch [mailto:touch at ISI.EDU] 
Sent: Tuesday, April 29, 2008 11:59 PM
To: Eastlake III Donald-LDE008
Cc: Dinesh G Dutt; rbridge at 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