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

[Erik Nordmark]

Radia Perlman wrote:
> Dinesh suggested the following, as a way of making configuration easier 

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

Has anybody looked at the volatily when the network comes up e.g., after 
a building power failure?

In that case RBridges will start sending hellos incrementally adding 
adjacencies, and receive flooded LSAs from RBridges that have just appeared.

Clearly if the network builds one RBridge at a time the regular unicast 
tree (the one rooted at the RBridge itself) would end up being 
recalculated up to N times (perhaps even more if the adjacencies between 
the N RBridges come up incrementally).

But here we are adding the fact that the *set of* multi-destination 
trees you to calculate would change as the network powers up. Do we know 
anything about the amount of churn that would cause?
It seems like receiving the first flooded LSA from an RBridge that just 
came up could cause the receiver to conclude that one (or more than 
one?) of the trees it has calculated are no longer needed, and that it 
instead needs to calculate a different set of trees.
A later LSA (from a different RBridge) could cause things to switch back 
to use the trees that were just discarded.

It sounds like this behavior can be quite dynamic.

    Erik