[rbridge] (slight) modification of how to choose mulitcast trees
erik.nordmark at sun.com
Wed Apr 2 10:53:12 PDT 2008
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.
More information about the rbridge