Subject: [rbridge] RBridge/bridge interaction

From: erik.nordmark at sun.com (Erik Nordmark)
Date: Thu, 20 Oct 2005 07:23:34 -0700

We've had some useful discussion on this mailing list.
It would be good if somebody can capture the results (perhaps as a long 
email) that we can fold into the draft(s) later. Any volunteers?

I don't know if we will have additional issues in this space or that it 
otherwise makes sense devoting agenda time to it in Vancouver.

For instance, while I'm convinced that BLOCK works, I wonder if there is 
something in PARTICIPATE PER PORT that can make the interaction work better.

Two cases to consider:
1. The elected forwarder dies and a new one gets elected. How quickly 
can packets sent by stations in the bridged cloud fail over to go to the 
new elected forwarder?

2. We have two separate bridged domains, each with their elected 
forwarder. Somebody connects the two bridged domains together with a 
wire. This can cause a temporary loop until a single elected forwarder 
is picked by the RBridges.

Can some form of PARTICIPATE PER PORT scheme makes things work 
better/faster in those two cases?

    Erik

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Thu, 20 Oct 2005 22:19:29 +0200

I volunteer for some work on the capture, although my english might be 
not too understandable.  From what date should the capture to be done?

Regarding PARTICIPATE PER PORT:
Although I do not have a clear position, and it requires detailed 
analysis, it seems to me that PARTICIPATE PER PORT is better integrated 
with spanning tree, while maintaining the basic decoupling that BLOCK 
provides.
With PARTICIPATE PER PORT it would be possible to force the elected 
Rbridge to become the sbridge root of the bridged domain by modifying 
its bridge priority when it gets elected as Designated by IS-IS (this 
could be an optimization). In this way the path length is minimum  from 
all bridges of bridged domain to the DR.

>can packets sent by stations in the bridged cloud fail over to go to the 
My understanding is that if the forwarded dies, the sbridge domain 
should handle  it as  a topology change notification, tables   of 
sbridges should be  flushed according to the spanning tree rules, so the 
sbridge domain must know the DR will not forward frames as it used to. 
It seems Rbridge shall issue a Topology Change Notification via sbridge 
domain to flush MAC tables. Is a fast analysis, probably I miss details.

>is picked by the RBridges.
In this case the PARTICIPATE PER PORT seems superior, as the two merged 
bridged domains will merge their spanning trees into one and both DRs 
will compete to be the root of the merged tree, this mechanism will 
likely be faster (via RSTP fast transit to forwarding state over the 
bridged domain)  than  Designation to select the unique DR. In other 
words , the mechanism of root election in sbridge could be used to help 
in DR designation and/or viceversa.
So I see in PARTICIPATE PER PORT, some coupling between DR status and 
root status of sbridge domain that can be used
 to speed up convergence and coherence of both domains. It seems that 
sbridge domains should be under the control of  Rbridges, but the 
sbridge mechanims should be used by Rbridges to keep the network 
consistency and reconfiguration capabilities of RSTP.
Guillermo