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

From: Radia.Perlman at sun.com ([email-masked])
Date: Mon, 17 Oct 2005 07:32:04 -0700

We pick block because things will converge much more quickly.

With blocking:

The spanning tree domains are smaller, and therefore will converge more quickly.

There is no feedback between the RBridge algorithm wormholing BPDUs into random places
within a spanning tree, confusing the spanning tree convergence.

*******
With forwarding, or sometimes forwarding based on configuration (I'm not sure what people are
proposing:

a) things will converge much more slowly

b) there are scary dependencies between bridge spanning tree and RBridges algorithms

c) no advantage as far as I can see. I don't know why we are discussing this.

Radia
-------------- next part --------------

Peter Ashwood-Smith wrote:
>   This lack of understanding of the DRs seems to be the cause of a lot
> of this debate. 

IMO, it's the belief that there will only ever be one DR or DR-like
(BLOCKing) device. I agree that this all works when it works.

>   Also, the 'problems' that people are attributing to blocking and not
> processing BPDUs [BLOCK] are also 'problems' when no STP is running.

'problems'? (why the quotes?)

OK, let's just shut off spanning tree in bridges and it all works just
fine now?

Now I'm *really* confused.

AFAICT, this all works when there is at most one rbridge campus in an L2.

WHEN (note the use of 'when', not 'if', since there's *nothing* that can
be done to enforce this) this isn't the case, the following problems arise:

	a) there is no way to detect the error

	b) loops *will* occur

If we want to say "BLOCK *MAY* work, but *MAY* silently fail", and
"PARTICIPATE and TRANSPARENT will always work with current standards",
that's fine (and, AFAICT, true), but I also don't see how we pick BLOCK
as a default in that case.

Joe
-------------- next part --------------
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://www.postel.org/mailman/listinfo/rbridge