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

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 18 Oct 2005 18:17:48 -0300

Alia,
 
    Slightly larger is large enough for people who are just a little too
large
to have a simple bridged network.  It may also be large enough if routing
table size is forcing larger L2 networks to be as large as possible and no
other choices exist.
 
--
Eric

-----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
<mailto: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:  <mailto:rbridge-bounces at postel.org> 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
<mailto: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 <mailto:rbridge at postel.org> 
http://www.postel.org/mailman/listinfo/rbridge
<http://www.postel.org/mailman/listinfo/rbridge> 

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