[rbridge] How many trees, and per what

[Radia.Perlman@sun.com]

There is considerable confusion (certainly by me, and I'm sure others) at this point. Let me start a new thread to
specificallly discuss which trees should be computed.

The WG consensus seemed to be to compute per-ingress trees rather than
shared trees. For several reasons, e.g.,

a) the number of packet hops to deliver a packet to just a subset of links (as would be the case with
a packet only going to links for a particular VLAN, or for an IP multicast that is only going to links with
registered receivers plus IP multicast routers) can be a lot more than necessary if we are not using
a per-ingress tree, and instead using a shared tree

b) a few packets in a conversation from S to D are more likely to get out of order if at first D is unknown, and
the packet is sent on a shared tree, and then when D is found, going directly, since the path from S to D might
be much longer in the shared tree than the tree rooted at S's Designated Rbridge

It is true that it would take less memory and computation to use a shared tree, even multiple per-F-tag shared
trees, but they would not have the properties a) and b) above.

So I believe if we do per-F-tag trees, we will be multiplying the number of trees by F-tag, and computing
(# of Designated Rbridges) * (# of F-tag values).

I don't believe we should revisit the per-ingress trees. Especially if the reason is to make better use of
bandwidth by using F-tags, since using per-ingress trees certainly will cut down on bandwidth use for
IP multicast packets and unknown/multicast VLAN-tagged packets.

So the question is whether we should multiply the number of trees by the number of F-tag values. And if so,
how many F-tag values are really needed.

I *think* the only purpose of using multiple F-tag values and trees is to spread traffic around, and engineer traffic
for certain classes of traffic. 

Radia