Subject: [rbridge] seeking input on abstract for problem and applicabi lity statement

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 18 Oct 2005 16:44:40 -0300

Joe,

	There are two ways to look at what we are doing.  One is to
start with the conclusion that we don't want an RBridge to do any
thing different than a bridge.  The other is that we do want the
RBridge to do something different than a bridge but we want it to
be compatible in a "drop-in" mode with bridges.

	I doubt that the former is the correct perspective, as the
immediate question that comes to my mind (at least) is why are we
doing anything at all then?

	For the latter, we have to work from a better understanding
than "[STP] is there for a reason."  STP is there to establish a
_single_ path for full network connectivity among devices that do
not have any other protection against forwarding loops.

	If we plan to design RBridges with the specific intent of
A) having more than one path for full connectivity and B) provide 
appropriate additional protection against forwarding loops, then 
we have to analyze how this impacts STP and vice versa.  We do not
have to blindly accept STP as the only answer - nor should we, at
least among RBridges, as the intent of STP works directly against
the intention of developing RBridges.

	The answers given already show that it is straight-forward
for a RBridge to determine it has a loop through the bridges in
the network - via, for example, a hello protocol.  That takes care
of the case where a connected set of bridges, hubs and lower-level
layer two devices are all that is between one port and another of
the same RBridge.  The case where the path between two ports of an
RBridge also includes another (one or more) RBridge(s), only makes
this slightly harder.

	In order to solve the slightly harder case, it is sufficient
- for example - to simply say that the only RBridge that does not
forward "Hello" message is the one that originated it.  What this
would mean is that all of the RBridges have to forward some type 
of "Hello" message unless they originated it (meaining - obviously
- that we need to come up with an essentially fool proof way to 
allow them to determine which messages they originated), rather 
than simply receiving and consuming it.

	It may be the case that there is more than one type of 
"hello" message in the "hello protocol" - loop detection hello
messages and peer discovery hello messages.  I don't know that
it will be necessary to make this distinction, but it will be
simpler.  There may be other approaches that work just as well, 
but - as I said earlier - it is sufficient to show that at least 
one solution exists.

	Note that this approach relies on exactly the same thing
as you're concerned about - the fact that broadcast messages
will be broadcast throughout a broadcast domain, irrespective
of what equipment is used and what cheats each equipment uses.

	If that is not true, then the network is already broken
and we're not making it worse.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Joe Touch
--> Sent: Sunday, October 16, 2005 3:33 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] seeking input on abstract for problem and
--> applicabi lity statement
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Earlier, you wrote:

Harald Tveit Alvestrand wrote:
> 
> --On s?ndag, oktober 16, 2005 09:21:57 -0700 Joe Touch <touch at ISI.EDU> 
> wrote:
> 
> 
>>>What we should be thinking of (to my mind) is "how do we discover that
>>>we're up the creek" - for this particular disaster, sending out a
>>>broadcast packet and watching it come back should be quite sufficient
>>>for the "detect" part....
>>
>>What if you send a packet and it creates a broadcast storm? Sure, you
>>know you're up the creek, but how do you paddle back?
> 
> if I have an one-packet answer to "how to take down a network", that 
> network is certainly in trouble without me..... but others have certainly 
> suggested forms of probing (hello packets?) that might be more gentle.

My concern is that every reason for allowing BLOCK for rbridges is a
reason to allow them for bridges as well.

SPT is there for a reason - to avoid the possibility of loops, and thus
such one-packet problems (deliberate or otherwise). I don't understand
why that's the required default for bridges (AFACT - regardless of
vendor offerings) but can be relaxed here.

> I'd very much like to design a network that is stable in the presence of a

> person with a laptop, an ordinary bridge port and no conscience....

Agreed.

Joe