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

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

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.
 
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 ;)
 
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 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

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

---

From: akatlas at gmail.com (Alia Atlas)
Date: Mon, 17 Oct 2005 12:01:49 -0700

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...

> 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
> *From:* 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
>
>
>
> > 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
> 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)
> 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
> _______________________________________________
> 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/d489ce06/attachment.html