[rbridge] it's time to summarize things

[Joe Touch]

Gray, Eric wrote:
> 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.

For internal traffic, sure. For ingress/egress traffic, this would need
to hijack ARP to work.

To external nodes, the rbridge MUST act like a transit, not a source or
sink.

> 	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. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051215/eb849e85/signature.bin