Subject: [rbridge] MAN scale and future uses of Rbridge

From: petera at nortel.com (Peter Ashwood-Smith)
Date: Mon, 17 Oct 2005 15:50:17 -0400

There is perhaps hope for higher rates of change and/or large scale for
flat addresses spaces. The query routing stuff (P2P networking) in
particular looks promising. Who knows perhaps it can be applied at L2 in
the future.
 
What is 'large enough'? Well increased scale is not necessarily to be
used for larger deployments. An increase in scalability has other more
important (IMHO) benefits. In particular if something can scale well
beyond the deployment scenarios it will be much more stable at the sizes
more commonly deployed. In other words you are not at the edge of your
operating envelope .. you are safely somewhere in the middle with lots
of head room. You can safely change/grow and shrink without worrying
about stability (and can survive spikes such as earthquakes, hurricanes
and ice storms). Anyway, once you increase the possible scale, the next
question of how many routers v.s rbridges is more one of functionality.
The rbridge won't be able to move further out until it has enough
features to take a bite out of its attached routers .. hopefully it can
do that while staying cheaper but at the moment its going to run out of
features before it runs out of scaling oompf. Anyway that's a long
winded way of saying ... beats me ;)

Peter

	-----Original Message-----
	From: rbridge-bounces at postel.org
[mailto:rbridge-bounces at postel.org] On Behalf Of Alia Atlas
	Sent: Monday, October 17, 2005 3:02 PM
	To: Developing a hybrid router/bridge.
	Subject: Re: [rbridge] MAN scale and future uses of Rbridge

	On 10/17/05, Peter Ashwood-Smith <petera at nortel.com> wrote: 

		I think the main impediment to very large scale is the
large flat address space and its rate of change. Not the number or
Rbridge nodes and networks/links. While use of IS-IS or OSPF areas can
help when addressing is hierarchical, they are not going to help much
when you cannot aggregate the addresses into specific areas.

	There are environments where the rate of change could be
reasonably bounded, so that brings it back to the flat address space...

		Then again I don't think that Rbridge needs to scale
that large to be enormously useful. If it pushes the attainable size out
a bit, gives better routes, is more stable and allows future innovations
based on the topology it is going to be very useful. After that .. well
its routers all the way down ;)

	What do you think is large enough?  (I remember the discussion
earlier, but not specific numbers.)
	
	Alia 

		Peter 

			-----Original Message-----
			From: rbridge-bounces at postel.org [mailto:
rbridge-bounces at postel.org <mailto:rbridge-bounces at postel.org> ] On
Behalf Of Alia Atlas
			Sent: Monday, October 17, 2005 2:37 PM
			To: Developing a hybrid router/bridge.
			Subject: Re: [rbridge] MAN scale and future uses
of Rbridge

			On 10/17/05, Sofia, Rute
<rute.sofia at siemens.com> wrote: 

				Considering Rbridges application from a
MAN scope, other scalability
				issues relate to:
				-  storage cost (the price of flat
addressing and of having every
				Rbridge learning both requested and
unrequested MAC destination 
				addresses) may be decreased, but is
something that has not be considered
				up until now, given that the scope is
limited to a campus...

			 What number of MAC addresses is the target for
the rbridge campus?   Do you
			think the constraints are on the memory or on
the notifications required due to changes? 

				- scalability related to the IS-IS
tuning. On this point, (I am not
				completely sure about the price but...),
there is a price to pay to tune 
				IS-IS in order to achieve convergence in
the order of hundreds of
				seconds. This is another issue to be
checked.

			Is there a reason that different areas couldn't
be used in the IS-IS instance for rbridges?
			Do you think this would be adequate?  Are the
topological restrictions (i.e. hub and spoke)
			acceptable?  Could we work around that?

				Summing up, these are issues to be
considered *if* Rbridges is to be
				extended to something larger than a
campus. But going back to the 
				participate vs. non-participate in the
ST issue, then the scope is
				something that may help in deciding this
issue. As I said, I do not see
				that Rbridges need to intervene *if* the
scope is limited to a campus.
				Why? Because as stated in Radia's paper,
Rbridges can simply terminate
				STs, which makes all the sense given
that a Rbridge is a hybrid router.
				But this scenario does not seem to make
the same sense, if a MAN scope
				is considered...

			While improving the scalability may not be
immediately in scope, I think it is
			worthwhile to consider where the restrictions
are coming from.
			
			Alia

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20051017/21802647/attachment.html