Subject: [rbridge] seeking input on abstractfor problemand applicabili tystatement

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 14 Oct 2005 18:55:36 -0300

Joe,

	You said: I'm not sure whether the 802 specs allow for 
	a non-hub device to not participate in the spanning tree 
	alg. Anyone else know?

The 802 specs mostly address Ethernet forwarding and bridge
behavior for STP.  A lot of bridge behavior (like the entire
section on bridge learning) was removed in more recent versions
of the specification.  As an aside, the reason I know this is
that we (Cabletron at that time) had filed a patent application
that listed the removed text as "prior art" and - consequently
- had to dig up a prior version to hand over to the USPTO.

As pointed out by Dino earlier, irrespective of what 802 says,
many implementations allow STP to be turned off for specific
bridge ports.  Clearly this can work.

	You also asked: If a spanning tree is attached to the 
	rbridge in more than one place, what happens with 
	broadcasts? Won't they create a loop?

Radia had earlier answered this question for me though it may
have been in an unrecognizably similar form.  I had asked what
would happen if I deploy one RBridge into a network that does
not segment it.  Note that this is an isomorphism of the situ
you ask about.

The answer turns out to be straight forward.  RBridges do not 
have to completely ignore STP, so an RBridge can determine it
has more than one port on the same local bridged network (Erik
was uncomfortable with referring to it as a "local broadcast
domain"). Also, even if it does not do this, the RBridge will
hear its own hello messages on different interfaces - allowing
it to conclude that it has more than one interface on the same
local bridged network.

Note that - like bridges during STP - RBridges SHOULD not be
forwarding frames until they have determined how to do so.

Note that the same observation applies whether the interfaces
for which this is true are "internal" or "external" to the
RBridge campus.

Once the RBridge has determined that it has more than one port
in the same local briged network, then what it does next will
depend on whether it "hears" another RBridge on that same local
bridged network.  

Note that - again - this could occur for either the "internal" 
or "external" case, since nothing exists to preclude connecting 
one RBridge campus to another.

If the RBridge hears one or more additional RBridges on the same
port, then it will determine appropriate SPST paths via routing
protocol interactions with that (or those) other RBridge(s). If
it does not, then it may decide to only forward broadcast frames
on one of those interfaces - either way - thus preventing loops
in broadcast/multicast traffic, or it might do something clever
(that we do not need to specify in this context).  It is enough
to show that there is a single proof of concept way in which to
prevent looping broadcast frames.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Joe Touch
--> Sent: Friday, October 14, 2005 4:50 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] seeking input on abstractfor problemand
--> applicabilitystatement
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->