[rbridge] How many spanning trees?
Radia.Perlman at sun.com
Mon Jun 27 15:54:48 PDT 2005
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
as many as we want without further protocol messages. The possibilities are:
a) one spanning tree: This is simplest, obviously.
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
(all of them...not just those attached to VLAN A) choose the RBridge,
has the lowest ID, AND that is attached to VLAN A. A spanning tree is
with RA as root. THat spanning tree is pruned so that only branches that
other VLAN A links survive.
Why bother: If only a few links are VLAN A, then this allows more
of multicast/unknown frames within the VLAN A broadcast domain.
c) one per RBridge
Why bother: for IP multicasts, if RBridges do IGMP snooping, then this
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
have to be sent over a spanning tree rather than on the shortest path
from S to D.
I personally don't have strong opinions on this. If only a miniscule
the traffic is multicast/unknown, then one spanning tree seems good
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
And if we did one per ingress RBridge, would it be worth computing all
in advance just in case, or only computing one when necessary?
More information about the rbridge