[rbridge] Traffic storms

[Radia Perlman]

I hesitate to bring this up because I don't want to reintroduce 
confusion about
"participating" in bridge spanning tree algorithm. So, please---what I'm
about to propose does NOT merge links. Bridged links still terminate at 
an RBridge.

The issue is that it can be unpleasant for two RBridges to 
simultaneously think they
are both Designated on the same link, which can happen if a bridge came up
and connected two links. Or for that matter, a repeater.

One way of making sure that a situation like that resolves very quickly,
and absolutely, is to have RBridges act like bridges on each of their ports,
with numerically lowest (i.e., highest) priority for become Root.

Now---I DO NOT MEAN that an RBridge merges the spanning trees on each of 
its ports.
The spanning tree is terminated at an RBridge. If an RBridge has 4 
ports, it will
participate in 4 independent bridge spanning tree instances.

The advantage of doing this is that we could make the Root bridge be the 
Designated
RBridge. Then if two RBridge links merged, the RBridges would notice 
immediately.
If you get usurped as bridge Root, you are also usurped as RBridge 
Designated RBridge.

Since the bridge spanning tree messages are never delayed by 
pre-forwarding delays,
this seems like it might be a nice thing to do.

It would be nice if the same RBridge that would get elected Desiganted 
RBridge in
the IS-IS link election would be elected bridge Root on that link. The 
easiest thing
would be not to bother with IS-IS priority, and have them all have the 
same priority,
with election being solely on ID. Then they can all use the lowest 
bridge root priority,
and the same RBridge would get elected bridge root on the link as would get
elected Designated RBridge on the link.

Radia