[rbridge] it's time to summarize things

[Gray, Eric]

Joe,

	I've addressed this issue before, just as you have
raised it before.

	Assuming that "external nodes" below refers to the
portions of the L2 broadcast domain that are topologically
outside of the RBridge campus, the RBridge campus actually
looks to external nodes as if it is a (possibly largish)
collection of L2 frame sources and sinks.

	In other words, from the perspective of any existing 
technology, external nodes (those that are outside of the
RBridge campus) see what looks like a shared ethernet link
with (possibly very many) directly attached L2 sources and
sinks.

	On the other hand, non-RBridge nodes that make up a
part of the infrastructure within the campus see only the
RBridges themselves (along with possibly locally attached
L2 sources and sinks) as L2 sources and sinks.

	We have to be careful about understanding this.  For
one thing, we have to realize that - within this common L2
broadcast domain - there can be no "back-routes" by which
an external node can become confused in filtering database
learning as a result of "hearing" the same source MAC from
more than one direction.  But this can be managed - mostly
because "external" (outside the RBridge campus) back-routes
cannot exist (any such back-route indicates that RBridges
are connected over it and it is therefore not ouside of the
RBridge campus).

	Inside the RBridge campus, ambiguity is resolved by
IS-IS routing, and by well-made RBridge implementations.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
--> Sent: Thursday, December 15, 2005 11:03 AM
--> To: Radia.Perlman at Sun.COM; Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] it's time to summarize things
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

Earlier, you wrote (paraphrased for context):

> An RBridge campus should look like a single broadcast domain
> to layer 3 devices, but that doesn't mean an RBridge should
> participate in spanning tree, any more than that if it had
> two token ring interfaces, that it should pass the token from
> one interface to another. (though hopefully this analogy won't 
> confuse people, since a station on a token ring *does* have to
> pass the token within that ring...
> however an Ethernet endnode does NOT have to participate
> in spanning tree (nor should it), and likewise, an RBridge
> does not have to participate in spanning tree.

That logic is makes as much (or as little) sense as an rbridge
correlating to a router. Routers and hosts on L2 are L2 sources 
and L2 sinks. To the existing L2, external traffic transits the 
rbridge; the rbridge sources and sinks no traffic to these 
external nodes.