Subject: [rbridge] Traffic storms

From: Radia.Perlman at sun.com ([email-masked])
Date: Fri, 03 Nov 2006 17:23:05 -0800

And since we don't have to be backwards compatible with existing IS-IS implementations, we could make
the IS-IS loop avoidance enhancement mandatory in RBridge IS-IS.

Radia

----- Original Message -----
From: Pierre Francois <pfr at info.ucl.ac.be>
Date: Friday, November 3, 2006 5:10 pm
Subject: Re: [rbridge] Traffic storms

> 
> Silvano,
> 
> See http://www.ietf.org/internet-drafts/draft-francois-ordered-fib-
> 02.txt,for a loop avoidance mechanism for IS-IS/OSPF.
> 
> See you in SD,
> 
> Pierre.
> 
> 
> 
> On Fri, 3 Nov 2006, Silvano Gai wrote:
> 
> > Eric,
> >
> > Also I suggest that people that have solved the problem of having 
> a loop
> > free topology using ISIS, submit proposasl so that we can compare 
> them.> Unfortunately I don't have one.
> >
> >
> >
> > -- Silvano
> >
> >
> >
> > ________________________________
> >
> > From: rbridge-bounces at postel.org [rbridge-bounces at postel.org] On
> > Behalf Of Gray, Eric
> > Sent: Friday, November 03, 2006 11:54 AM
> > To: Gideon Kaempfer; Radia Perlman
> > Cc: rbridge at postel.org
> > Subject: Re: [rbridge] Traffic storms
> >
> >
> >
> > Gideon,
> >
> >
> >
> >     "Drop BPDUs" is not (exactly) the same as ignore them.  We 
> use the
> > term
> >
> > as short-hand for the one of three options we considered for 
> handling> BPDUs:
> >
> >
> >
> >     Drop (do not participate actively in STP, and do not pass BPDUs
> > through),
> >
> >     Transparent (pass BPDUs through - potentially altering them 
> in some
> > way),
> >
> >     Participate (have each RBridge participate in STP as if it 
> were a
> > bridge).
> >
> >
> >
> > Hence, when we say "Drop BPDUs" we are not saying that we cannot 
> look>
> > at them, we are just saying that we're not doing one of the other 
> two> choices.
> >
> >
> >
> > --
> >
> > Eric
> >
> >
> >
> >
> > ________________________________
> >
> >
> > 	From: rbridge-bounces at postel.org
> > [rbridge-bounces at postel.org] On Behalf Of Gideon Kaempfer
> > 	Sent: Friday, November 03, 2006 1:40 AM
> > 	To: Radia Perlman
> > 	Cc: rbridge at postel.org
> > 	Subject: Re: [rbridge] Traffic storms
> >
> > 	Radia,
> >
> > 	Wouldn't this create a link between TRILL and STP we are trying
> > to avoid?
> >
> > 	Relying on the fact that a LAN segment has some kind of unique
> > identifier (such as the root bridge ID) seems like a very practical
> > solution to me, but strongly reliant on the fact that the Rbridges
> > actually process BPDUs. I thought they were just meant to discard 
> them.> Is this acceptable?
> >
> > 	Regrads,
> >
> >          Gidi
> >
> >
> >
> > 	On 11/3/06, Radia Perlman <Radia.Perlman at sun.com> wrote:
> >
> > 	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.
> >
> > 	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.
> >
> > 	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.
> > 	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".
> >
> > 	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.
> >
> > 	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.
> >
> > 	Radia
> >
> >
> >
> >
> >
> >
> > 	Gideon Kaempfer wrote:
> >
> > 	>Following mention by Silvano of broadcast and multicast storms
> > (and the need
> > 	>to protect against them), I played around with different
> > scenarios and came
> > 	>upon one I would appreciate your comments on (in the hope I am
> > pointing out
> > 	>a non-existent issue with TRILL). I believe a broadcast and
> > even a unicast
> > 	>storm could be created as the result of a loop that isn't
> > protected by TTL
> > 	>nor by STP in the case of a link connecting two separate LAN
> > segments coming
> > 	>to life.
> > 	>
> > 	>- RB1 ---- RB2 -
> > 	>   |        |
> > 	>-  B1 --x-- B2 -
> > 	>   |        |
> > 	>   H1       H2
> > 	>
> > 	>1. The network (segment) involved consists of two Rbridges
> > (RB1, RB2), two
> > 	>bridges (B1, B2) and two hosts (H1, H2). They are physically
> > connected as
> > 	>depicted.
> > 	>2. State A: the direct link between B1 and B2 is down. B1 and
> > B2 find
> > 	>themselves on different LAN segments and hence different
> > spanning trees. RB1
> > 	>and RB2 are both designated Rbridges (each for the segment of
> > the
> > 	>corresponding bridge).
> > 	>3. State B: the direct link between B1 and B2 goes up (someone
> > connects a
> > 	>cable). B1 and B2 discover each other and establish a common
> > spanning tree.
> > 	>RB1 and RB2 both find themselves attached to the same LAN
> > segment and hence
> > 	>RB1 (without loss of generality) will eventually become the
> > designated
> > 	>Rbridge for it.
> > 	>4. Just before RB1 and RB2 identify that they are both on the
> > same segment
> > 	>and RB2 stops functioning as a designated Rbridge the following
> > scenario
> > 	>seems possible:
> > 	>  a. H1 sends a broadcast frame.
> > 	>  b. B1 receives it and forwards to RB1 and B2.
> > 	>  c. RB1 (encapsulates and) forwards to RB2.
> > 	>  d. B2 forwards to RB2 and H2.
> > 	>  e. RB2 forwards the copy from RB1 to B2 (and the copy from B2
> > to RB1).
> > 	>  f. (RB1 forwards to B1.)
> > 	>  g. B2 forwards (again) to H2 and to B1.
> > 	>  h. B1 forwards to H1 (see remark below regarding filtering
> > table
> > 	>contamination) and to RB1.
> > 	>  i. Etcetera etcetera.
> > 	>5. A broadcast storm is born, created by a loop that is not
> > protected by TTL
> > 	>(due to the fact that forwarding between the Rbridges is only
> > across a
> > 	>single hop) nor by STP (due to the fact that Rbridges do not
> > participate in
> > 	>STP).
> > 	>6. If forwarding commences at the hardware level and no
> > broadcast rate
> > 	>limiting is in place, the storm may cause severe damage in a
> > very short time
> > 	>(note that replicated frames are sent to H1 and H2 (or any
> > network they
> > 	>could represent).
> > 	>7. Another unfortunate effect of this storm is that B1 and B2
> > no longer know
> > 	>where H1 is located (due to the contamination of their
> > filtering tables by a
> > 	>frame from H1 that arrives from the wrong direction (and in
> > fact from
> > 	>multiple directions). As a result, a possible unicast frame
> > from H2 to H1
> > 	>will just join the storm over the loop at least in one
> > direction (RB2 will
> > 	>forward it to RB1) but will not arrive at H1...
> > 	>
> > 	>One possible solution could be for RB2 to identify the fact
> > that it is
> > 	>receiving a frame from a host with a MAC address that is
> > associated with a
> > 	>segment it thought it isn't connected to. Hence, it may trigger
> > an immediate
> > 	>neighbor discovery / designated Rbridge election. However,
> > because Rbridges
> > 	>should allow host mobility, this frame may need to be forwarded
> > (and hence
> > 	>the storm commences).
> > 	>
> > 	>As mentioned above, any comments are welcome.
> > 	>  Gideon Kaempfer
> > 	>
> > 	>_______________________________________________
> > 	>rbridge mailing list
> > 	>rbridge at postel.org
> > 	> http://mailman.postel.org/mailman/listinfo/rbridge
> > <http://mailman.postel.org/mailman/listinfo/rbridge>
> > 	>
> > 	>
> >
> > 	_______________________________________________
> > 	rbridge mailing list
> > 	rbridge at postel.org
> > 	http://mailman.postel.org/mailman/listinfo/rbridge
> >
> >
> >
> >
>