[rbridge] (more efficiently) announcing "which multicast roots"

[Radia Perlman]

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 4.2.3.4, 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 (4.2.3.4, 
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 
prefer).

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.

Comments?

Radia