[rbridge] it's time to summarize things

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Saikat Ray wrote:
> The simplest, if not the most rigorous, explanation is as follows. Replace
> each legacy part of the network by a hub (i.e., first remove all RBridges
> from the topology. Then choose a legacy bridge and replace this bridge and
> all legacy bridges that have a path to it by a single hub, and let all
> end-hosts served by those legacy bridges be connected to this hub. Repeat
> this procedure until all legacy bridges are replaced. Then finally put the
> RBridges back.). Now, one and only one RBridge forwards and receives
> unencapsulated packets from each hub (through designated RBridge). Thus for
> a loop formation, a packet must loop back to a designated RBridge, which is
> not possible since RBridges use their own spanning tree for sending
> (encapsulated) broadcast traffic.

Here's a variant that maps to only existing technologies:

	- remove the rbridges (as Saikat said)
		this leaves some number of disconnected
		bridged ethernet segments

	- replace the entirety of each bridged ethernet segment
	with a single hub (again, as Saikat said)
		I'm not positive this is valid; it will
		be if you replace the segment with a bridge, though.
		I'm worried about doubly-connected hosts, etc.

	- replace the rbridge campus with a bridge
		FORCE that bridge to be the root of the spanning tree

*IF* there is at most one rbridge campus in a LAN *AND* that campus can
end up knowing it is root of all the edge spanning trees, there can't be
a loop.

The key are the IF and AND clauses.

The IF is effectively forced by the HELLO messages; all rbridge devices
will coalesce into a single campus. This means you can't use multiple
campuses to handle scalability in a LAN, however.

The AND is assumed; if there is any other device that tries the same
trick and makes the same assumption (whether another rbridge, or an
rbridge-like system that doesn't use rbridge messages), the assumption
will be invalid.

Joe


> 
> Hope this helps.
> 
> 
>>-----Original Message-----
>>From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
>>Behalf Of Tim Shepard
>>Sent: Thursday, December 15, 2005 6:42 PM
>>To: Developing a hybrid router/bridge.
>>Cc: Radia.Perlman at Sun.COM; 'Joe Touch'
>>Subject: Re: [rbridge] it's time to summarize things
>>
>>
>>
>>>Let us suppose that an RBridge is connected to a legacy bridge's port
>>>directly, and all RBridges block BPDUs. Then the RBridge looks like,
>>
>>from
>>
>>>the perspective of the legacy brige, either (i) a single end-host (with
>>
>>the
>>
>>>MAC address that of the RBridge) if the RBridge is not the designated
>>>RBridge, or (ii) a shared media (like a hub; is the standard term
>>>"segment"?) with potentially a lot of MAC addresses attached to it (in
>>
>>fact,
>>[....]
>>
>>>So what exactly do you think is the problem with ARP?
>>
>>
>>I'm not sure I follow all of the postings on this issue.
>>
>>But after reading through this thread, I'm still left wondering what
>>is supposed to make sure packets don't loop forever when there are a
>>mix of bridges and rbridges plugged together (in some crazy accidental
>>way, creating whatever kind of loop involving bridges and rbridges
>>that causes the most trouble).
>>
>>It seems to me that if rbridges block the spanning tree forming
>>packets, but do forward (e.g.) ARP traffic, then there could be loops
>>that are not broken by either the rbridge system or the usual bridge
>>spanning-tree-forming algorithm.
>>
>>Could someone explain succinctly (for someone who is just barely
>>following this thread) how a system (of mixed bridges and rbridges,
>>plugged together by some Byzantine net admin) will ensure that packets
>>are not forwarded in a loop?
>>
>>(And ARP is a good example, since it is supposed to go everywhere, but
>>not loop.)
>>
>>
>>Or will there be configuration rules that forbid some ways of plugging
>>together bridges and rbridges?
>>
>>			-Tim Shepard
>>			 shep at alum.mit.edu
>>_______________________________________________
>>rbridge mailing list
>>rbridge at postel.org
>>http://www.postel.org/mailman/listinfo/rbridge
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDozGxE5f5cImnZrsRAp52AJoDJK5R9khUkkMo9TTDNBqKftcAZACfeefA
ajxeO9YPH9+MkJBwbaww00E=
=MENV
-----END PGP SIGNATURE-----