Subject: [rbridge] Traffic storms

From: sanjays at cisco.com (Sanjay Sane (sanjays))
Date: Mon, 6 Nov 2006 18:13:36 -0800

Radia,

as per this proposal, 
if a rbridge is connected to the same bridging cloud by n ports, 
AND if the rbridge treats each of the ports as separate STP instances,
THEN it would break that single bridging cloud into n disjoint trees. 
Is that accurate? 

btw, it could be that multiple ports of the same rbridge may, in fact, connect distinct bridging clouds. In such a scenario, it would not be a good idea for the rbrdige to merge the STP instances. 

-Sanjay

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On Behalf Of Guillermo Ib??ez
Sent: Monday, November 06, 2006 2:52 PM
To: Radia Perlman
Cc: rbridge at postel.org
Subject: Re: [rbridge] Traffic storms

Radia,
       As you know, I support this approach. I have a doubt, however. 
The ID used is the RBridge ID or a different ID per port?
 I assume it is by RBridge ID. Then, as far I understand, several ports of an RBridge could be connected to the same bridged link. In other words, an RBridge port may have to compete against other port of same RBridge for "root bridge" election. In this case, if the ID is the same (the RBridge ID), the link will split into two separate trees near the equal cost point if that is possible (at least a bridge exists between RBridge ports) to balance the cost of link connected to each of the root bridge ports, or by any of the standard tie breaking mechanisms like port ID if no there is no bridge interposed.
Regards
Guillermo
Radia Perlman escribi?:
> 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
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>   
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 06 Nov 2006 19:05:32 -0800

Interesting question.

If the RBridge is on the cut set of the link, then, indeed, the cloud 
would get
partitioned into multiple spanning tree domains all connected via the 
RBridge. But
that's a good thing.

If there *is* connectivity between two of the RBridge's ports through
the link, the RBridge will recognize this because the Root isn't simply 
"R", but "R" concatenated with
a port number. So RBridge R will state it is root "R.1" on one port and 
"R.2" on the other.
So R.1 will be the Root. So R's other port will decide "Oh...I'm not the 
Root, so I'm not Designated
RBridge on this link and therefore I won't forward traffic to/from this 
link.

Radia

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 07 Nov 2006 09:33:19 -0800

Actually---not sure what I said is correct. If there was actually 
connectivity (not through bridges)
it would act like I said (where the other ports would turn off).

However, beyond one hop, each port would still be reporting "R" as the 
root, so this would
actually partition the bridged cloud. Which is I think what we'd want. 
And what Sanjay said
would happen.

And this might also be the thing that does the right thing in the 
"wiring closet" case.

Radia