[rbridge] STP and ISIS

[Radia Perlman]

I agree with what Mike said, but just to clarify...although there are 
spanning trees computed in order
to send multicast packets, and packets for unknown destinations, and IP 
multicasts, the spanning
trees (yes, multiple ones) are computed from the information already 
distributed in the link
state protocol. There's no need for an extra protocol to compute a 
spanning tree.

Radia



Mike Hughes wrote:

>--On 21 September 2005 12:04 +0530 Tom Sanders <toms.sanders at gmail.com>
>wrote:
>
>  
>
>>So, is the proposal to totally do away with STP et. al and run only
>>ISIS instead? The spanning tree is then computed with the topology
>>information provided by ISIS. Is this correct?
>>    
>>
>
>The proposal is to give a more optimal alternative for spanning tree in a
>"campus" L2 network.
>
>The problem with spanning tree, as you correctly assert, is that you end up
>with blocked links. In more complex L2 topologies, you can end up with
>significant numbers of blocked links. Blocked links = wasted bandwidth,
>which is especially expensive/wasteful at something like 10Gig/nx10Gig.
>
>Blocked links also mean sub-optimal, rather than shortest path, forwarding
>within the network.
>
>The proposal (almost) completely replaces STP within a "campus" L2 network
>of switches/bridges. (I say almost, as it looks like a spanning tree will
>still need to be used for things like network layer broadcast frames.)
>
>It has the potential to be more efficient, and more elegant, as for known
>unicasted frames, delivery will be done via the shortest/most optimal path.
>The proposed encapsulation of payload will also add a TTL to manage
>temporary forwarding loops during convergence.
>
>While rbridge was originally concieved for managing redundancy and mobility
>within a campus, I can think of other applications, such as within L2 metro
>networks (like the one I operate) where moving to an L3 routed solution is
>not an option.
>
>Regards,
>Mike
>  
>