[rbridge] How many spanning trees?

[Radia Perlman]

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.

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.

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.

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