Subject: [rbridge] Time to summarize "forward or block" BPDU thread

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 18 Oct 2005 17:43:47 -0300

Joe,

	Assuming that discovery of another RBridge on a link
means that the link is internal, then any link that connects
two RBridges is internal.  That in turn forces the formation
of a single campus - unless another behavior is configured.

	Conceded.

	However, we do not have to worry about an environment
in which mythical devices that also block STP exist.  That's
because we never could avoid those environments and therefore
always had to allow for them.

	Also, we do not have to worry about a loop external to
the RBridges.  The existence of such a loop indicates either
that there are two ports of the same RBridge on a bridged 
network segment (which the RBridge could handle itself), or 
that the loop is not external (because more than one RBridge 
is on the same bridged network segment).

	If we consider how an RBridge looks to the existing L2
network, if it does block STP, what we find is that the rest
of the network will see each distinct port of an Rbridge as 
a separate Hub with a possibly large number of MAC addresses
attached to it.  It's important to understand this, because
it will have serious effects on bridge stability, both for
STP and bridge learning, if we do not handle this correctly 
in specifying RBridge behavior.

	One simple approach might be to have the whole RBridge
campus behave exactly as a bridge would behave - including 
STP, port blocking, etc.  But that is neither a necessity, 
nor necessarily a good idea.  And, it may not be the simplest 
approach either.

	I think this is the perspective from which many are
currently arguing.  There are at least a couple of reasons
why this perspective makes sense:

1) behaving exactly like a bridge is exactly what we hope
   to get away from, and
2) getting an RBridge campus to behave as one large bridge
   is not itself a simple goal

	The simplest approach - to A) improve on the behavior
of bridges and B) avoid trying to look like a single large
bridge - is to simply block STP.

	As far as what happens if some other device(s) also
block STP, we have to expect that a network having those
devices is expected to work - because otherwise we cannot
improve the situation.  

	If it works, then RBridges will not make the situation 
worse.

	If these - possibly mythical - devices are capable of
creating a loop for frame transport, then the RBridges are
better off not relying on STP as a mechanism to detect this.
If such a loop exists, then it should be easily detected by
sending some form of limited broadcast message.  If it blocks
STP, then what good would it do to participate in STP?  If it
doesn't forward broadcast messages, then what's the problem?

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Joe Touch
--> Sent: Monday, October 17, 2005 10:22 AM
--> To: saikat at seas.upenn.edu; Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Time to summarize "forward or block" 
--> BPDU thread
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

Earlier you wrote:

Saikat Ray wrote:
> AFAICT, this all works when there is at most one rbridge campus in an L2.
> 
> [Saikat] I think that the assumption (definition) is that if two RBridges
> are connected directly (i.e. no IP router in between), then they are parts
> of a single campus, thus must talk to each other. If that is true, then
how
> would you have more than one campuses that are not separated by an IP
> router?

You won't - the rbridge campuses will merge.

But we're the IETF, and we're making 'rbridges', which will BLOCK.

Let's say the IEEE decides to allow another group to make 'sbridges',
which also decide to BLOCK.

Now you can have an rbridge and an sbridge in the same L2 (how do you
know you don't?). They form an undetectable, uncorrectable loop.

--

I.e. - this all works only if everyone plays by OUR rules. Since we're
NOT the IEEE, how is it that we can decide to create a protocol that
relies on us being the ONLY exception?

Joe