[rbridge] (slight) modification of how to choose mulitcast trees

[Radia Perlman]

Dinesh suggested the following, as a way of making configuration easier 
for how to choose multicast trees.

1) Each RBridge is configured with a priority for being selected a 
multicast tree root (with of course a default being a medium priority)

2) Each RBridge R1 s also configured with a parameter indicating "total 
number of trees in the campus", which R1 announces in its LSP

3) RBridges are ranked by (priority, ID). The RBridge with the 
numerically lowest priority, and then numerically lowest ID being the
tie breaker, dictates the total number of trees all the other RBridges 
must calculate (the number that R1 announces in its LSP according
to rule 2 above.

4) An RBridge calculates n distribution trees, where n is the number 
announced by the lowest (priority, ID) RBridge R1, in R1's LSP,
as the "total number of trees". The n trees computed are the ones using 
the n numerically lowest (priority, ID) RBridges as roots

5) if RB1 is ingress RBridge on port p, and (*note another parameter 
"k"*) is configured to do k-way path splitting on that port for
multidestination frames, the k tree roots that RB1 chooses consist of 
the three for which the triple "(cost of root to me, priority, ID)" are
the k smallest.

Intuition: suppose there is a topology with a lot of "leaf" RBridges., 
and "next level" RBridges that the leaf RBridges connect to.
If there are m leaf RBridges connected to next level RBridge RBx, then 
there is no reason to compute trees with any of the leaf
RBridges as root -- the tree rooted at RBx will be the same tree, and 
will indeed be a shortest path tree for each of the attached
leaf RBridges. If a leaf RBridge is attached to several next-level 
RBridges, the most significant number in the triple -- "cost
of root to me" will cause the leaf RBridge to multipath the multicast 
among multiple shortest-path trees.

This seems completely safe, and easier than configuring, for each 
RBridge, the set of root RBridges to choose for multicast tree roots.
It also means that you can configure in one place a total number of 
roots, rather than possibly having too many RBridges volunteer for
being tree roots, and winding up with too much overhead on RBridges 
because they'll have to compute a tree for every RBridge that
says it will want to be a tree root.

There might be a concern about volatility -- when an RBridge with 
numerically low priority goes down, it might cause:
a) a change to the total number of trees to be computed by everyone 
(since the next best might be configured with a different number)
b) a change to the list of "tree roots I will choose" announced by RB2 
when one of the roots for the k best (cost to me, priority, ID) goes down.

Other than that, I can't think of any possible problems.

Radia