Subject: [rbridge] Arch Issue #1

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 9 Dec 2005 11:15:06 -0500

Joe,

	Please see in-line below...

--
Eric

--> 
--> Gray, Eric wrote:
--> > --> 
--> > --> #1 resolve recommendations for the three modes of 
--> BSTP messages:
--> > -->    (is this part of the PS or ARCH?)
--> > --> 	participate
--> > --> 	forward
--> > --> 	block
--> > 
--> > Block by default.  Optional configuration for forwarding and/or
--> > participating MAY be allowed but SHOULD be considered sub-optimal.
--> 
--> Forward maps to what hubs do.

Hubs, repeaters and simple "Work-Group Switches".  Mnay things
do not participate in STP now and some forward (like the above)
while others block.

--> 
--> Participate maps to what bridges do.

Most bridges.  Mostly agree.

--> 
--> As a result, either of those can easily be considered as 
--> default cases, though forward is clearly suboptimal.

"Participate" can be sub-optimal as well, assuming that we're
talking about simple participation.

In simple participation, an RBridge participates with bridges
both internal and external to the RBridge campus. This makes
for a single spanning tree and effectively cancels any hopes
we might have for efficient use of bandwidth - even internal
to the RBridge campus.  In order for this approach to work,
internal RBridge interfaces MUST be eligible to be put in a
non-forwarding state by the STP, and - once this is done - 
they cannot be used by SPF frame forwarding.

More complex participation - which is what I suspect you are
referring to - would be along the lines of treating external
interfaces of all RBridges in a single campus as part of a
single large bridge (you've previously argued that an RBridge 
campus may be viewed as a single "virtual bridge").  This is
more complicated because the STP block and forward decisions
for all such external interfaces now needs to be collectively
made (and maintained) across a number of RBridges (all of them
within a campus).  That would be a non-trivial exercise using
your favorite proprietary approach; it would be impossible to
standardize.

Neither form of participation is preferrable, in the former 
case because it is sub-optimal and the latter because of the
complexity involved.  So the question is can participation be 
avoided? 

See below for the answer to this question...

--> 
--> As to block:
--> 
--> 1. it seems clear that it works only under a certain set of 
--> assumptions about ALL other L2 devices:
--> 
--> 	a) ALL other L2 devices MUST pass rbridge's HELLO messages
--> 
--> 	b) ALL other L2 devices MUST NOT also BLOCK
--> 
--> Neither rule can be assumed about an rbridge; by symmetry, 
--> why can we assume them about all past and future L2 devices?

So, these assumptions are an over-simplification of the problem
space.

For one thing, assuming that the hello/discovery protocol uses
an appropriate communication layer, then the hello/discovery
messages MUST be delivered over any non-disfunctional path.

There is - by the way - nothing we can, or should try to, do 
about disfunctional paths.

There is a potential issue with uni-directional communication 
paths, but this is addressed by the same approach we've already 
discussed for detecting transitive RBridge connectivity.  That
is, hello/discovery messages are relayed, at least one time, 
from all RBridge interfaces (potentially excepting the one on
which an RBridge receives them), until the are returned to the
originating RBridge.  This has the effect of letting RBridges
know which of their interfaces are "internal" and which are 
external.  Because messages are forwarded on every RBridge
interface, this will also detect unidirectional closure.

Admittedly, it may be early to establish that this is the way
that RBridge discovery will work, but the above description 
has been mentioned before and certainly can be used as a proof
of concept demonstration that there is at least one approach 
that resolves the issues.

Note that using such an approach eliminates issues with any
potentially anti-social behavior on the part of other devices
in the LAN.  Paths over which hello/discovery traffic is not
delivered (is blocked) will not cause loops in other data-plane
traffic forwarding because devices (other than RBridges) will
not be able to distinguish RBridge hello/discovery messages
from any other traffic.

--> 
--> 2. BLOCK + HELLO is basically just a variant of an STP 
--> where the rbridge is in a privileged position of 'ultimate 
--> root' (which is  why it works when the two assumptions 
--> above are valid).

I disagree that the scenarios in which this approach works
are limited to this scenario. 

The hello/discovery protocol would derive its properties from
IGP routing, rather than from bridging and should not involve
- or directly interact with - bridge control protocol in any 
way.

See the explanation above...

--> 
--> We can already assume that STP (or MSTP) works where STP (/MSTP) is
--> supported; why not just PARTICIPATE in STP at that point?

I believe the reasons for not participating in STP have been 
made abundantly clear.

--> 
--> The HELLOs are just equivalent to BPDUs that discover which edge ports
--> are connected on the outside anyway. Why not just BPDUs at that point?

I disagree that hello/discovery messages are anything at all
like BPDUs.  They are used purely for peer discovery and to
make the coarse topological distinction between internal and
external links/interfaces.  They do not get directly involved
in SPF path calculations once a set of interfaces is found to
be internal to the RBridge campus.

--> 
--> Joe
--> -----BEGIN PGP SIGNATURE-----
--> Version: GnuPG v1.2.4 (MingW32)
--> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
--> 
--> iD8DBQFDmKg+E5f5cImnZrsRAku1AKCNmYMTRjr1gRToob+Uh6LV443DcgCffQ1Q
--> 0DAGlCFmevHRYsQ6yyHgHeY=
--> =4ck0
--> -----END PGP SIGNATURE-----
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 09 Dec 2005 09:55:38 -0800

Gray, Eric wrote:
> Hubs, repeaters and simple "Work-Group Switches". 

Those are all what I've been calling 'hubs'.

> Mnay things

Far as I've been able to find out, the things that block are known as
"broken". If you can point to something specific that blocks that is
widely used - or that is compliant with spec - that'd be useful.

> to the RBridge campus.

We haven't talked about the internal transit requirements before;
bridges there ARE going run STP/MSTP and coalesce into trees anyway (you
can't stop that). It doesn't matter if such trees touch two rbridges -
there can still be independent paths between the rbridges (though that
needs to be engineered; if they connect anywhere in the middle, the as
you note, the bridging will end up killing the possibility of multipath).

> In order for this approach to work,

We really need to resolve the discussion of what an 'internal rbridge
interface' is before this sentence can be interpreted completely.

However, putting an interface (any interface) into a nonforwarding state
is just what a root bridge would do anyway, which is why I consider this
a variant of PARTICIPATE.

> within a campus). 

Those decisions already need to be coordinated. Until you decide what's
in and out of an rbridge, you don't know what 'internal' means anyway.

> That would be a non-trivial exercise using

Things like the HELLO protocol already start in this direction; are you
suggesting that HELLO will be impossible to standardize? ;-)

> messages MUST be delivered over any non-disfunctional path.

Bridges think that's true for BPDUs too; if rbridges block them, then it
is the rbridge that becomes the disfunctional component.

> about disfunctional paths.

Agreed - except not creating them either ;-)

> not be able to distinguish RBridge hello/discovery messages

Will they be encrypted? If not, we cannot make this assumption.

> be internal to the RBridge campus.

That's just what BPDUs would do if this were a root. HELLO presumes that
the rbridge is the absolute root; whenever that assumption is incorrect,
there are problems that cannot be resolved.

Joe

> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

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