Subject: [rbridge] loops in trill networks

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 12 Oct 2005 12:18:23 -0300

Joe,

	If RBridges are connected by a single broadcast domain,
"outside" of the RBridge domain, this is the same as having a
common LAN/broadcast-domain inside the RBridge domain.  The
term "outside" is topologically meaningless.

	Consequently, the potential for looping traffic through
this "outside" broadcast domain is exactly the same as looping
traffic through an "inside" broadcast domain.  Therefore, the
same process for selecting a designated forwarder would be used
for either common broadcast domain.

	It should _not_ be done using STP. It is not necessary 
and results in the same disuse of redundant capacity as would
be the case without RBridges.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Joe Touch
--> Sent: Tuesday, October 11, 2005 6:39 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] loops in trill networks
--> 
--> 
--> -----BEGIN PGP SIGNED MESSAGE-----
--> Hash: SHA1
--> 
--> 
--> 
--> Radia Perlman wrote:
--> > Let me try explaining it a different way.
--> > 
--> > You start with one giant bridged campus. There is one 
--> spanning tree.
--> > 
--> > Then you replace some of the bridges with RBridges.
--> > 
--> > Pretend that the RBridges don't forward ANY packets.
--> > 
--> > Now the campus is likely partitioned into several pieces, 
--> let's say 5, 
--> > with no connectivity
--> > between the pieces.
--> 
--> That's not necessarily likely. That would only occur if the 
--> network were
--> wired as a spanning tree; if we could expect that, we 
--> wouldn't need to
--> generate one.
--> 
--> I.e., it's more likely that such partitioning might not 
--> occur - however,
--> the rbridge system might not provide a benefit in those 
--> cases. AFAICT,
--> an rbridge helps only where it does partition the bridges as above.
--> 
--> Let's thus assume that's the case, as engineered:
--> 
--> > Each piece computes its own spanning tree, with its own 
--> Root bridge. So you
--> > have 5 independent, disconnected spanning trees.
--> > 
--> > Now think of each of those 5 pieces as a single link. The 
--> fact that each 
--> > piece
--> > is glued together with spanning tree with bridges is 
--> invisible outside 
--> > that piece. So we
--> > can stop thinking about bridges, and now only look at the 
--> next layer 
--> > up...the RBridges.
--> 
--> Those links can touch the rbridge in multiple places - 
--> there's no reason
--> they necessarily connect to a single port. While this is OK for the
--> rbridge egress (it picks one designated rbridge on that link to send
--> things out), it's entirely possible that a broadcast will 
--> end up cycling
--> back over that link to another ingress port.
--> 
--> That's why the rbridge needs to be in the spanning tree protocol.
--> Otherwise the 'links' outside can loop back onto the rbridge.
--> 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDTD7mE5f5cImnZrsRAp+lAJ91dAP3vrxQDXiaU2gRHC1a+1slQwCg3Ssk
--> UPKxoEu4qB+tJlVtDS8ylRo=
--> =wc2h
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->