[rbridge] listening vs transmitting spanning tree messages

[Radia.Perlman@sun.com]

First -- I am not advocating turning the entire RBridged campus into one
giant spanning tree by *forwarding* bridge spanning tree messages
from one RBridge port to another. Somehow each time we try to
discuss this, some people get confused, and I don't want to
confuse people

The current version of the protocol spec says that RBridges should
transmit bridge spanning tree messages (BPDUs) with highest
priority (numerically lowest) for becoming root bridge, and
an RBridge should be DRB if and only if it becomes the root
of the bridge spanning tree on that layer 2 cloud. Again...this
is per port -- separate spanning tree on each port. Only if
an RBridge has two ports on the same layer 2 cloud (where
"layer 2 cloud" means it's connected with bridges) will
the spanning tree on one port have anything to do with
the spanning tree on another port.

The reason we had RBridges do that is to quickly catch the
case where two layer 2 clouds got merged, so that we
would very quickly stop there being two DRBs on the same cloud.

I think I still prefer this option, but an argument was made that
it is too complex to transmit BPDUs since there are too many
different versions of the spanning tree, and we'd have to
specify which ones must be supported.

So an alternate proposal is that RBridges only *listen* to
BPDUs.

Then, RBridge R1 can detect a potential merging of two layer 2
clouds on one of its ports if the Root bridge changes.

If the Root bridge changes, then R1 would stop forwarding
data packets to/from the link (because there might be another
DRB) for some amount of time.

Personally, I think I prefer transmitting, rather than simply
listening to BPDUs. The reasons:

a) I don't understand why it is more complex to transmit
rather than listen to BPDUs. Don't we have the same
issue with having to understand all the different versions
of the bridge spanning tree? Aren't all of the versions
compatible with the original spanning tree protocol
anyway, so that a bridge with highest
priority (numerically lowest) sending "original spanning
tree" protocol messages will become Root even
if other bridges are doing RSTP or MSTP or whatever? 

b) The rule "you are DRB if and only if you are the root
of the spanning tree" is clear.
With "do something if the bridge Root ID changes"
I think the rules are more squishy. How long
do you wait?

c) there might be bridge root ID changes a lot more
often than due to layer 2 clouds merging, and in
those cases the link will be unnecessarily
orphaned for awhile (while the one DRB waits
in case something is wrong).

Radia