[rbridge] (more efficiently) announcing "which multicast roots"
Radia.Perlman at sun.com
Wed Oct 29 11:41:58 PDT 2008
The spec originally allowed each RBridge to enumerate any set of tree Roots.
Then we had the highest priority RBridge, R1, limit the total number of
tree roots, to be the value "n" specified in R1's
LSP. That limited the eligible set of tree roots to be the top n
(selected based on the top n of (priority, ID)).
The spec (section 22.214.171.124, item 5) has, in R2's LSP, a list of nicknames
of tree roots that R2 might specify (and of
course these would have to be among the top n, or else other RBridges
wouldn't have calculated a tree based on them).
It says if the list is empty, that R2 will only use the highest priority
distribution tree root.
R2 already says the number of roots, say "J" it would like (126.96.36.199,
item 4). It seems like, with little loss of
generality, we could remove item 5 from the LSP, and assume that R2 will
want to use the top J roots (unless J>n, in
which case it is n).
The only loss in generality is that R2 might have a different priority
ordering of the roots (for instance, preferring roots that
are close to R2, or R2 might be manually configured with which roots to
So it seems like the possibilities are:
a) leave the spec as it is -- (leaving out item 5 in the LSP means "I'll
only use the highest priority root")
b) reinterpret the omission of item 5 to be "I want the top J roots" (or
the top n, if J>n), where "J" is the number I specified
in item 4
c) do b), but also allow item 5 if R2 is unhappy about using the top J
roots and wants to specify them independently.
None of these is a major change from the spec. I prefer b over a, since
it seems to get "for free", the ability to specify multiple
roots (assuming that R2's top choice of roots really is the top J).
Proposal c gives the most flexibility, and does not require inclusion of
this information except when R2 really prefers some subset of the top n
roots other than the top J.
If we are leaving out item 5, then R2 could get the same functionality
by specifying "J"=n, and it can use any of the top n it wants.
The cost of that is that "R2" will appear on the filtering lists of the
(n-J) roots that it is not intending to specify.
More information about the rbridge