Subject: [rbridge] loops in trill networks

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 13 Oct 2005 09:29:16 -0300

Erik,

	I agree that sending a topology change BPDU might be
a better approach.  There are two things for us to look at
if that's what we're thinking of doing: what are the results
of having a device that is enough of a regular bridge to be
able to send topology change BPDUs but not enough of one to
be able to otherwise participate in bridging - and - what
are the consequences to forwarding when we put all of the
bridges in non-forwarding mode while they re-run STP and
then in flooding mode while they re-learn their filtering
DB?

	I think the latter is not so much of an issue, if we
subscribe to the philosophy stated earlier that having the
ability to create a larger L2 domain is an objective.  In
that case, the "trauma" thus induced would be no worse than
if the RBridge that went down was a regular bridge.

	The former issue is something we can maybe finesse,
if we allow RBridges to originate BPDUs but not (in the
normal case) forward them.  In this case, other bridges
will normally construe that an RBridge - rather than being
a host - is a bridge with no transit connectivity.  In that
case, the normal mode would be that local bridges would 
only forward frames to an RBridge that are MAC-addressed
to it.

	For the case where RBridges might forward BPDUs, it
must be the case that they are configured with information
that will allow them to determine which BPDUs to forward
an which not to forward.  Otherwise - for forwarding - it
will not be possible to take advantage of many redundant
paths as the bridges will see the RBridges as part of a 
single spanning tree and will forward and accept frames
only on that single spanning tree.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Erik Nordmark
--> Sent: Wednesday, October 12, 2005 10:35 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> Gray, Eric wrote:
--> 
--> > 	Instead, the normal case should be for RBridges
--> > to terminate the local broadcast domain and the local
--> > STP-based spanning tree. To do this, RBridges should
--> > act as if they were hosts to STP and ignore it.
--> 
--> Eric,
--> I'm not sure we have a useful definition for "local 
--> broadcast domain" - 
--> we have a broadcast domain which spans the whole rbridged 
--> network so 
--> that IP broadcast continues to work as before.
--> 
--> I think that having rbridges act as if they are hosts is a 
--> good starting 
--> point to think about the problem. But the desire to attach 
--> the local 
--> (bridged) segment to multiple rbridges for redundancy makes 
--> things a bit 
--> more complex. Take this picture:
--> 
--> 	   H4
-->              |
--> 	( Rest of rbridged network )
--> 	 |                       |
--> 	RB1                     RB2
-->           |                       |
--> 	( bridged cloud at edge    )
-->           |      |          |
--> 	H1     H2         H3
--> 
--> Suppose RB1 has been elected as the forwarder to/from the 
--> bridged cloud.
--> This means that the bridges have learned (from received 
--> packets) that 
--> packets to MAC addresses in the rest of the network (e.g., 
--> H4) should be 
--> sent towards RB1.
--> 
--> What happens when RB1 fails? RB2 would take over, and the routing 
--> protocol would quickly cause the other rbridges to find out.
--> But packets from H1 to H4 will continue to be forwarded by 
--> the bridges 
--> towards RB1 until those learning tables time out, or until 
--> a packet from 
--> H4 arrives via RB2.
--> 
--> If we want to ensure that the bridges more quickly find out 
--> that they 
--> should use RB2, it would seem like we need to add something in the 
--> interaction at the edge. Effectively we want RB2 to be able 
--> to tell the 
--> bridges in the cloud either
-->   - that they should discard their learning tables, or
-->   - that they should switch to use RB2.
--> 
--> I haven't looked at the options in detail, but perhaps we 
--> can do the 
--> first by RB2 injecting a toplogy change BPDU?
--> For the second approach, one could envision the RBs at the edge 
--> presenting themselves as a bridge with a low cost to an 
--> imaginary root 
--> bridge (which represents the rbridge core)? Of course, we 
--> can't ensure 
--> that the imaginary becomes the root bridge; the best we can 
--> do is to 
--> have it have a high probability of becoming the root bridge 
--> from the 
--> perspective of the bridged cloud at this part of the edge.
--> I don't think this requires that BPDUs be carried across 
--> the rbridged 
--> cloud - each bridged cloud at the edges can be treated as separate.
--> 
--> I don't know how fancy we need to be here, but waiting for 
--> the learning 
--> tables to time out when there is an RB failures seems a bid bad.
--> 
-->     Erik
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->