[rbridge] it's time to summarize things

[Tim Shepard]

> 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