Subject: [rbridge] Traffic storms

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 3 Nov 2006 14:49:37 -0500

Radia,

	A few amplifying comments below...

--
Eric 

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
--> Sent: Friday, November 03, 2006 1:25 AM
--> To: gidi at gidik.com
--> Cc: rbridge at postel.org
--> Subject: Re: [rbridge] Traffic storms
--> 
--> The simplest way to put it, I think, is that in certain transitory 
--> situations there might be two RBridges that both think they are 
--> Designated RBridge, and that is bad, but should stop as soon as a
--> single Hello is received by the RBridge who should not be Designated.

Yes, this is what would happen in the least clue-full implementation
possible.  This would be a pretty bad solution in the absence of the
potential for determining that a topology cahnge has occurred (or is
in progress) by other means.

For one thing, the RBridges in this approach would have to employ some
form of priorityzed forwarding in order to inclrease the likelihood
that Hello messages actually get through the storm.

--> 
--> I think PIM has similar transitory situations that can occur, and 
--> bridges can also have (hopefully temporary) problems if a repeater 
--> came up and merged two LANs. I think such things are annoying but 
--> not fatal. But I think it's possible we can with little effort 
--> avoid this problem.
--> 
--> However, with RBridges, because the bridge spanning tree algorithm 
--> elects a Root, there's really a way of uniquely identifying a LAN 
--> (where "LAN" is a bunch of links connected with bridges). The unique 
--> identifier is the root bridge.

I am sure that this is not required.

--> 
--> When the B1-B2 link is down, RB1 and RB2 will see the topology as two 
--> separate links, and each one will have a distinct spanning tree Root 
--> bridge (RB1 will see B1, and RB2 will see B2 as the root).
--> 
--> When the B1-B2 link comes up, the bridges will first merge the two 
--> links, and either RB1 or RB2 will see that the bridge spanning tree 
--> root has changed. This will be discovered before B1 and B2 forward
--> traffic across the link because of the bridge forwarding delay.

Agree.

--> If B1 has better priority as bridge spanning tree root than B2, then RB1

--> will not notice anything different when the B1-B2 link comes up. But RB2

--> will notice something different; the spanning tree root has changed 
--> identities from "B2" to "B1".

Yet another way to detect the change.

--> 
--> Given this, RB2 could temporarily stop forwarding to or from the link 
--> when the Root bridge changes identities, though it should definitely 
--> immediately send IS-IS Hellos (either RB1 or RB2 will be elected 
--> Designated Router in the IS-IS election for that link). If RB2 has 
--> better prioirty for root, the RB1 will immediately stop forwarding to 
--> or from the link when it sees the Hello from RB2.
-->
--> If RB2 has better priority in the IS-IS election, then RB1 should 
--> immediately send an IS-IS Hello when it sees a Hello from a new RBridge 
--> on the link.
--> 
--> So I think this is not a big deal, and that if we are worried, we can 
--> specify that an RBridge should stop acting like the Designated RBridge 
--> for a few seconds after the identity of the Root in the spanning
--> tree algorithm changes.

I believe this is essential only for non-unicast traffic.

--> 
--> Or we could be even fancier and have each RBridge announce in its IS-IS 
--> Hellos which LAN IDs it is Designated for, where a LAN ID is the MAC 
--> address of the Root bridge. So RB1 continue forwarding if the identity 
--> changes from B1 to B2 provided no other RBridge has claimed to be
connected
--> to B2. But if RB2's LSP claims it is attached to B2, then RB1 must stop 
--> forwarding for enough time for the IS-IS election to sort itself out and

--> choose a Designated RBridge.

In addition to being "too fancy" by more than enough, this is not really
necessary, given the plethora of ways to detect that a topology change 
either has already occurred, or may be in progress.

--> 
--> Radia
--> 
-- [snip] --