[rbridge] How many spanning trees?

[Radia Perlman]

You are right that paths will not be the same from A to B as from B to A 
with an A-rooted tree (towards B)
vs a B-rooted tree (towards A), at least if we do a straightforward 
calculation of spanning trees. I think trying
to accomplish symmetric routes might
require source/destination pair route computation. So hopefully we won't 
require symmetric routes.

Radia



Guillermo Ibáñez wrote:

>Guillermo Ibáñez wrote:
>This is my feedback on the "how many spanning trees" issue.
>
>
>Radia Perlman wrote:
>
>  
>
>>It would be nice to get opinions on remaining issues, and I think each
>>issue should be in a different email thread, so I'm starting one.
>>
>>How many spanning
>>trees should RBridges compute? Given the link state database, they can 
>>calculate
>>as many as we want without further protocol messages. The possibilities are:
>>
>>a) one spanning tree: This is simplest, obviously. 
>>
>>    
>>
>The poor performance in the core for multicast is an important argument 
>against it. Other possibilities should exist, at least as an option.
>
>  
>
>>b) one per VLAN: How it would work:each RBridge announces, in its link state info, which VLANs that
>>RBridge is attached to.  To calculate a spanning tree for VLAN A, the 
>>RBridges 
>>(all of them...not just those attached to VLAN A) choose the RBridge, 
>>RA, that
>>has the lowest ID, AND that is attached to VLAN A. A spanning tree is 
>>calculated
>>with RA as root. THat spanning tree is pruned so that only branches that 
>>reach
>>other VLAN A links survive.
>>
>>Why bother: If only a few links are VLAN A, then this allows more 
>>optimal delivery
>>of multicast/unknown frames within the VLAN A broadcast domain.
>> 
>>
>>    
>>
>
>It seems that with this implementation  compatibility (interoperability) 
>with bridges running Multiple Spanning Tree Protocol (MSTP) is 
>excluded.  If bridges running MSTP exist  in the campus network, they 
>must be confined in one or several MST regions with their specific 
>VLAN-to-spanning tree instance mappings and,  like happens with STP or 
>RSTP, the trees will end at the region boundary with an rbridge. This 
>means that there could coexist "regions" running MSTP with their own 
>VLANs and multiple spanning trees inside the region, these regions 
>inserted between rbridges that use another type (range or IDs) of VLANs. 
>My understanding is then that the only VLANs capable of traversing the 
>campus end-to-end would be the VLANs handled by Rbridges, as the other 
>would be stopped by Rbridges if they are not known by them. 
>
>c) one per RBridge
>
>  
>
>>Why bother: for IP multicasts, if RBridges do IGMP snooping, then this 
>>allows
>>optimal delivery from source to the receivers of a particular multicast.
>>
>>Another reason is that it minimizes out of order delivery of packets in the
>>case when S it talking to D, and initially D is unknown by the RBridges 
>>and packets
>>have to be sent over a spanning tree rather than on the shortest path 
>>    
>>
>>from S to D.
>  
>
>> 
>>
>>    
>>
>One tree per bridge is very efficient together with IGMP snooping, 
>assuming a core of rbridges. The plus point is that in this case the 
>multiple trees can also perform routing of unicast traffic, if used 
>together with the MAC address learning mechanism. In other words: 
>assuming a core formed by rbridges,  using an spaning tree per rbridge 
>may be enough to perform all the routing via minimum paths. This 
>requires that the  address learning mechanism works over the trees (the 
>trees coincide in opposite directions A to B and B to A, a tricky issue 
>when path costs can be equal).  So it seems that there is some 
>overlapping or overkillling using multiple spanning trees for 
>broadcast/multicast and Dijkstra routing for unicast and simplifications 
>are  possible.
>
>  
>
>>********
>>I personally don't have strong opinions on this. If only a miniscule 
>>amount of
>>the traffic is multicast/unknown, then one spanning tree seems good 
>>enough. If
>>there's high volume IP-derived multicast applications, then perhaps one per
>>RBridge would be worth it.
>>
>>So I guess I'd be inclined to either just have one spanning tree, or one per
>>ingress RBridge.
>>
>>And if we did one per ingress RBridge, would it be worth computing all 
>>those trees
>>in advance just in case, or only computing one when necessary?
>>
>>Radia
>>
>>_______________________________________________
>>rbridge mailing list
>>rbridge at postel.org
>>http://www.postel.org/mailman/listinfo/rbridge
>>
>> 
>>
>>    
>>
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>  
>