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

From: rute.sofia at siemens.com (Sofia, Rute)
Date: Mon, 17 Oct 2005 19:17:55 +0200

> 
>   This is one reason for the dominance of OSPF over RIP at L3. 
> 
>   Shortest paths are of course of interest in the MAN but 
> other reasons
> why Rbridge is attractive in the MAN consist of future uses 
> of its link
> state topology. In particular as Alia pointed out, RAPID 
> style rerouting
> (loop free alternates) is possible. Also the link state topology is
> useful for constraint based routing. So let's not rule out 
> larger scale
> in the future, especially since this is where Rbridge will 
> really shine.
> 
Besides the fact that having "all" the topology at hand provides greater
flexibility to decide on how to forward information, scalability issues
concerning Rbridges imply more than just the forwarding algorithm of
choice. 

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

- backward compatibility issues currently being discussed (i.e., whether
to have Rbridges as termination of STs). If the use of Rbridges within
the MAN is not to be disregarded, then there is a cost related to having
Rbridges interworking with legacy bridges. By not allowing Rbridges to
intervene in the ST (using BLOCK) then the Rbridge placement must be
carefully chosen, or performance will degrade. 

- scalability due to broadcasts. As Saikat stated, there are better
approaches to treat broadcasts and not really requiring much more
computational power (given that all the information is local)

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

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

Regards,
Rute

---

From: akatlas at gmail.com (Alia Atlas)
Date: Mon, 17 Oct 2005 11:37:03 -0700

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

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

> But this scenario does not seem to make the same sense, if a MAN scope

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/a325c0dd/attachment.html

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 18 Oct 2005 08:08:09 +0200

-Regarding scalability problem of high number of flat MAC addresses in 
the MAN,
   There is no such problem,  provided each campus network uses routers 
to participate in the MAN. In this case the only MAC addresses to be 
handled by the
Rbridges are the MACs of the routers used to accesss the MAN.(See Link 
State Over MAC, Garc?a and Duato 2003   proposal for such an example)
- Another aspect to analyze consider in the MAN environment is the 
interoperability with provider bridges (.1ad .1ah) and their 
encapsulations.
Guillermo

Sofia, Rute wrote:

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