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

From: petera at nortel.com (Peter Ashwood-Smith)
Date: Sat, 15 Oct 2005 11:11:57 -0400

> FWIW, nobody has answered the basic question:
> replace an rbridge in BLOCK mode with a bridge
> run whatever rbridges run internally within the bridge
> (i.e., emulate it)
> would THAT device be able to replace a bridge?
> would THAT device be able to partition the STPs of its leaves?

  Let me take a crack at it. 

  If I take one big STP domain and pick some point in the middle and
block
the BPDUS, clearly what I get is two independent trees that won't know
about 
each other. Broadcast packets on one side will get to the other as if
there
were a host on the far side, but would potentially loop if there were
two links
between the trees. To fix this, somebody has to block one of the links
in
both directions at one end or the other, or both ends.

  Now, if we take the code on rbridge that elects a desgnated rbridge to

act as the interface between these domains, run that same
logic on this new 'bridge'. Then yes. It could replace a bridge at this
boundary
since it would decide which link between the trees to use and would
block the
others.

  Anyway the key to eliminating this confusion is to understand that the
designated rbridge allows only one link between the trees. This concept
can be used to join two
trees together regardless of how they are created and only has to be
done by one
side or the other, not both. You could have two statically configured
trees with two or more links betwen them and this concept will pick one
link to use and ignore/block the others.

  Peter Ashwood-Smith

---

From: touch at ISI.EDU (Joe Touch)
Date: Sat, 15 Oct 2005 08:22:45 -0700

> link to use and ignore/block the others.

OK - thinking about this further, I think I get it - with a caveat.

BLOCK works fine, provided the rbridge campus is the ONLY "device" in
the L2 who thinks it's appropriate to BLOCK. As such, it knows that it
can't form a loop by tying together edge trees.

I.e., this works because all rbridges join to make a single campus.
If there are two or more campuses in the same L2, or if some other
device or pseudodevice (sbridge ;-) decides to play this game, the
rbridge campus can't BLOCK; it MUST be PARTICIPATE or TRANSPARENT.

I don't believe it is therefore appropriate to BLOCK; if we break the
'all bridges/hubs must play in spanning tree' rule, we can't ensure that
there won't be any other device that will do this too.

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

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Sun, 16 Oct 2005 12:15:09 +0200

> there won't be any other device that will do this too.

actually we *can't* ensure that all bridges and hubs play the spanning tree 
game no matter what we do, given that spanning tree is a configuration 
option on switches.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://www.postel.org/pipermail/rbridge/attachments/20051016/890e06e4/attachment.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Sun, 16 Oct 2005 09:21:57 -0700

Harald Tveit Alvestrand wrote:
> actually we *can't* ensure that all bridges and hubs play the spanning
> tree game no matter what we do, given that spanning tree is a
> configuration option on switches.
> 
> 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?

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

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Sun, 16 Oct 2005 20:25:59 +0200

--On s?ndag, oktober 16, 2005 09:21:57 -0700 Joe Touch <touch at ISI.EDU> 

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

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Sun, 16 Oct 2005 12:33:24 -0700

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

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

Agreed.

Joe

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