Subject: [rbridge] listening vs transmitting spanning tree messages

From: Radia.Perlman at sun.com ([email-masked])
Date: Wed, 09 May 2007 06:26:26 -0700

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

---

From: eric.gray at ericsson.com (Eric Gray (LO/EUS))
Date: Wed, 9 May 2007 11:13:12 -0500

Radia,

	The simplest approach to correctly eliminating the 
potential for two DRBs on the same shared access link is
via the neighbor discovery and DRB election process itself.

	I prefer the approach of not participating in any STP
as the default (unconfigured) approach for a number of other
reasons.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia.Perlman at sun.com
> Sent: Wednesday, May 09, 2007 9:26 AM
> To: rbridge at postel.org
> Subject: [rbridge] listening vs transmitting spanning tree messages
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>