Subject: [rbridge] Traffic storms

From: sgai at nuovasystems.com (Silvano Gai)
Date: Fri, 3 Nov 2006 12:19:05 -0800

Eric,

TRILL needs to be a well defined spec that guarantees products that are
interoperable.

If you write in the spec that BPDUs must be ignored, I will drop them.

If I need to do something different with BPDUs, then let's spell it out
in the spec.

I don't like the attitude, "oh, the spec is broken, but there is some
magic that will fix it".

Let's write in the spec what is this magic.

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 [mailto: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
[mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/rbridge/attachments/20061103/72300623/attachment-0001.html

---

From: pfr at info.ucl.ac.be (Pierre Francois)
Date: Sat, 4 Nov 2006 02:10:11 +0100 (CET)

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.