Subject: [rbridge] Arch Issue #1

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 14 Dec 2005 15:36:33 -0500

Joe,

	We're not converging in this discussion and part of the
reason why appears to be that there is still some considerable
confusion about the first principles of what we're trying to 
accomplish, and how those principles affect the architecture.

	Consequently, I believe we should break this discussion up 
and start new discussions on the following NEW architectural 
issues:

o What Are the Important Aspects of Bridge Behavior and How Do
  They Impact RBridges and/or the TRILL Architecture?
o What is the Role of the Hello Protocol?
o What Are the Assumptions About How Hello Protocol Works?
o How do RBridge Campus Models map to BPDU Handling Modes?
o (When) Does Block (BPDU Handling Mode) Work?
o Sub-Optimality Issues of Block Mode(s)
o What Does Participate (BPDU Handling Mode) Mean?
o Sub-Optimality Issues of Participate Mode(s)
o What Does Forward (BPDUs) Mean?
o Sub-Optimality Issues of Forward Mode(s)

To close on relatively minor sub-issues:

-> > Many things do not participate in STP now and some forward 
-> > (like the above) while others block.
->
-> Far as I've been able to find out, the things that block are 
-> known as "broken". 

Nice, ringing, phraseology - however, not true.

Let's take a typical current technology - bridging-capable
routers.

Word around this list is that routers (want to) terminate 
a broadcast domain at each router interface.  Sadly, they 
don't always have the option to do this.

If a broadcast domain on one router interface surreptitiously
becomes connected to a broadcast domain on another interface
of the same router, one of three things happens:

1) The network breaks (not the most robust alternative)
2) The router switches to bridging mode between the now
   connected interfaces (including participating in STP)
3) The router recognizes that the two interfaces share
   a common broadcast domain and adopts a reasonable mode
   of operation consistent with this knowledge (including 
   load sharing, ARP sharing, etc. - and _NOT_ including 
   STP participation or forwarding).

You might ask "why would a router adopt behavior number
3 when behavior number 2 works?"

To answer this, look at these two scenarios:

1)         (N1)        (N2)        (N3)
               \_    _/    \_    _/
                 \  /        \  /
                  R1          R2
                _/  \_      _/  \_
               /      \    /      \
           (N4)        (N5)        (N6)
               \_                _/
                 \_____    _____/
                       \  /
                        B*

2)         (N1)        (N2)        (N3)
               \_    _/    \_    _/
                 \  /        \  /
                  R1          R2
                _/  \_      _/  \_
               /      \    /      \
           (N4)        (N5)        (N6)
               \_    _/
                 \  /
                  B*

In both of these cases, separately routed networks have
become a single broadcast domain through the addition of
a new bridge (B*) added between the previously separate
networks (N4+N6 in example 1 and N4+N5 in example 2).

So, the answer to the question above is that there is no
_good_ reason why scenario 1 should work and scenario 2
should not.  However, a very quick analysis will tell you
that scenario 1 works.  N4+N6 is topologically identical
to either N2 or N5 in that it connects R1 to R2.

Consequently, scenario 2 should work and - by analogy -
the _best_mode_ would be for it to work in the same way
that scenario 1 works.  This mode is both less traumatic
and more efficient...

-> If you can point to something specific that blocks that is 
-> widely used - or that is compliant with spec - that'd be 
-> useful.
-> 

So this is a rediculous request.  The "spec" you refer to
is presumably the 802.1 specification, consequently it is
not possible to "point to something that blocks [and] is
compliant with the spec" and it is not very interesting to
"point to something that blocks [or] is complaint with the 
spec".

Simply consider that not everything in the world is going
to be consistent with the spec and yet things still work.

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

We have talked about this, unless you've been letting someone
else use your E-Mail account.

You argued - fairly convincingly - that it would not normally
be possible for there to be more than one RBridge campus in a
single broadcast domain.  How did you suppose this to be the
case if we were not considering "internal transit requirements"?

-> > 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.
-> 
-> We really need to resolve the discussion of what an 'internal 
-> rbridge interface' is before this sentence can be interpreted 
-> completely.
-> 

I don't think anyone other than you is having trouble with 
the meaning of 'internal rbridge interface' in this context.
It is simply an interface that forms a circuit either with 
one or more additional RBridges, or zero or more additional
RBridges and another interface of itself.  That is, if the 
RBridge is an ingress or egress RBridge, an internal RBridge 
interface is one on which it will transmit frames it is the 
ingress for, or receives frames it is the egress for.

The definition - if you want to be picky about it - can be
harder to get your head around than the concept it defines.
See the figure (about 2 inches) below...

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

Yes, that is what a bridges do, but I think you'll find a root 
bridge typically does not have any non-forwarding interfaces.

But this is not the point.  If one of the working group goals
is to make efficient use of link bandwidth, then - in the figure
below - we do not want any 'internal RBridge interfaces' to be in
a non-forwarding mode.

      __________
     /     i.1_ \    ___ i.3
    (      i.2_>RB-1<___ 1.4
     \          /
      \ campus /            i.1 and i.2 are internal interfaces
       \______/             i.3 and i.4 are external interfaces

That is to say, RB-1 _might_ put i.3 or i.4 in non-forwarding
mode (I do not consider this either necessary or ideal), but 
it should not put i.1 or i.2 in non-forwarding mode.  That is
why blocking STP is the optimal approach.

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

These decisions do not have to be "coordinated" in the same sense
that they would be coordinated between interfaces of a single box.

What we've talked about so far (in terms of coordination) is how
we might use IS-IS to share information among RBridges that will
allow each edge RBridge to build what is effectively a filtering
database.  The model for frame forwarding within a RBridge campus
is supposed to be based on routing rather than bridging.

Consequently, the decision as to which external interfaces are 
used to (receive) ingress and (transmit) egress frames is both 
a local decision (which must be made consistently) and a result
of collective forwarding based on frame routing within a campus.

In other words, frames should be allowed to arrive at an egress
RBridge by whatever interface happens to correspond to the SPF
path to that egress from any ingress.

The bit of coordination that we need to work out is along the 
lines of who is the designated egress for what frames when more
that one RBridge is connected to the same 'external' LAN segment.

-> 
-> > That would be a non-trivial exercise using your favorite proprietary 
-> > approach; it would be impossible to standardize.
-> 
-> Things like the HELLO protocol already start in this direction; 
-> are you suggesting that HELLO will be impossible to standardize? ;-)
-> 

In what way is the HELLO protocol going to be involved in working
out forwarding between RBridges?  As far as I know, in absolutely
_no_way_ at all.

HELLO protocol is involved in determing neighbor relationships and
indirectly allows RBridges to determine campus topology.  That can
certainly be done.

Based on the neighbor relationships that RBridges determine, they
then use link-state routing to determine topology and - finally -
SPF to determine forwarding. 

Saying that the HELLO protocol is involved in determining forwarding
is getting a little ahead of ourselves... 

-> > 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.
-> 
-> Bridges think that's true for BPDUs too; if rbridges block them,
-> then it is the rbridge that becomes the disfunctional component.
-> 

RBridges are not bridges.  Maybe we should call them NBridges
to make that clearer?

-> > [D]evices (other than RBridges) will not be able to 
-> > distinguish RBridge hello/discovery messages from any
-> > other traffic.
-> 
-> Will they be encrypted? If not, we cannot make this assumption.
-> 

Let's not be cryptic.  There's a difference between:

A) being able to distinguish RBridge hello/discovery messages 
   through some deliberate analysis of frames based on - at 
   least - a priori knowledge of the existence of RBridges, 
   TRILL and the hello and discovery protocols, and 

B) being unable to distinguish RBridge hello/discovery messages 
   because they are frames like every other frame it is the 
   fundamental purpose of LAN devices to forward.

LAN devices - because they are in the business of forwarding
frames - will not reject some frames and pass others without
some prior knowledge and justification.  We need to make sure
that we do not choose a poor frame format that we know will
be rejected by existing technology and we need to rely on a
belief that future technologies will not decide to discard 
TRILL hello/discovery frames without due consideration of the
effects of doing so.

Any other set of assumptions is essentially pathological.

Due consideration is what we are in the process of doing now.
Note that "due consideration" and "slavish compliance" are 
not the same thing.  If we want to do something different, we
are free to do so, as long as we consider the implications.

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 14 Dec 2005 14:31:40 -0800

Gray, Eric wrote:
> o Sub-Optimality Issues of Forward Mode(s)]

These sound good to me.

> a broadcast domain at each router interface.

As per RFC1812.

> Sadly, they 

That's when they're not routers anymore.

> 1) The network breaks (not the most robust alternative)

This seems like the right thing; the network breaks when you break its
protocol requirements.

>    connected interfaces (including participating in STP)

At that point it behaves like a bridge connected to a router, i.e., that
the bridge connects the two interfaces, which are also bridged to the
router. That's fine, and understandable as a commercial device.

>    STP participation or forwarding).

That's when the router is starting to second-guess what it means do be a
bridge, 'assuming' it knows what to forward and why. And when the
second-guessing is incorrect, things (predictably) break.

> 3 when behavior number 2 works?"

Indeed ;-)

> should not. 

Agreed.

> However, a very quick analysis will tell you

Agreed.

> Consequently, scenario 2 should work

Agreed.

> and - by analogy -

This is the point where second-guessing comes in. That's what STP is
there for - so the router doesn't have to second-guess.

> So this is a rediculous request. 

We're talking about protocols; the spec I'm referring to is 802.1D (or
thereabouts), i.e., STP (and its derivatives).

I'm asking why we are trying to support something. Either that something
is compliant with the spec OR it's in wide use. Both of those are
reasons to support it.

If all it does is violate the spec, then what's the point in trying to
support it?

> The "spec" you refer to
> compliant with the spec"

I used "or", not "and".

> and it is not very interesting to

I said "blocks that is widely used".

I intended the latter alternative to be "blocks that is compliant with
the spec" (i.e., a valid interpretation of the spec that allows blocking).

> to be consistent with the spec and yet things still work.

This argues that 'we' should violate the spec (i.e., not based on
whether others have before). How can we assert stability or safety of a
system where we violate an exising spec, when that stability/safety
assumes that all successors obey _our_ spec?

The more recent point is that such requirements persist whether there is
more than one rbridge campus or not, since you cannot know whether there
are such multiple bridges.

> the meaning of 'internal rbridge interface' in this context.

Few others have participated in this part of the discussion except you,
Guillermo, and I. It's hard to assert anything general given three inputs.

> ingress for, or receives frames it is the egress for.

The issue isn't that the meaning is hard to understand; the issue is
that the term is inaccurate. Hosts can - and will - sit on that
interface. I was trying to reserve internal/external for a distinction
between traffic between rbridges and traffic from ingress/egress to
hosts - where inside/outside meant 'inside the campus' (invisible to
hosts) and 'outside to the hosts' (visible to hosts).

It's not clear what 'internal' implies in the definition above, or why
it's useful to consider rbridge-rbridge interfaces the same way as
rbridge-self interfaces.

> bridge typically does not have any non-forwarding interfaces.

Given two or more interfaces on the same non-bridged segment, the root
bridge should not forward between those.

> below - we do not want any 'internal RBridge interfaces' to be in

See above. That's why I don't like that definition of internal.

The above seems to imply that i.1 and i.2 carry encapsulated traffic and
i.3 and i.4 do not; if _that_ is the definition of internal/external, I
agree. But not otherwise.

> of collective forwarding based on frame routing within a campus.

Agreed - that seems to refer implicitly back to the tunnels I was
referring to.

> path to that egress from any ingress.

I'm not sure what the point of this assertion is.

> that one RBridge is connected to the same 'external' LAN segment.

Agreed.

> is getting a little ahead of ourselves... 

That's why I said "start in this direction" rather than solve it.
They're clearly involved in the first phase, though.

> RBridges are not bridges.  Maybe we should call them NBridges

Rbridges are not bridges, but I still think the correct (and best) model
for an rbridge campus is a bridge.

>    TRILL and the hello and discovery protocols, and 

It depends on what the messages look like. If they're broadcast frames
of a control type with a content that is unrecognized, they could be
blocked without a-priori knowledge of their existence.

>    fundamental purpose of LAN devices to forward.

So YOU are allowed to assume that bridges will forward HELLOs because
they ought to be handled like any other frame. The rbridge campus is
supposed to look like a single L2, but rbridges can block BPDUs (which
is never done inside an L2), so the bridges cannot expect similar known
behavior that you expect?

> some prior knowledge and justification.

See above for an example.

> We need to make sure

And the benefits, and whether the benefits outweigh the implications.

Joe

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Wed, 14 Dec 2005 17:32:30 -0800

I just got back from a bunch of travel, and was trying to catch
up on the mailing list, and it's really so long.

It looks like the thread of whether RBridges participate
in spanning tree popped up again. I thought that had been
resolved.

RBridges should NOT participate in spanning tree, which means
they should DROP spanning tree messages.

An RBridge should NOT merge spanning trees. It should terminate
spanning trees, just like routers do.

However things have
to work properly if two of an RBridge's ports are in the same
broadcast domain (either because they are the same
physical link or because a path of bridges connects those
two ports of the RBridge. Just like routers handle this case just
fine, RBridges will handle the case just fine.

One person (I forget who) brought up a case ahile ago where they thought
it would be advantageous for an RBridge to participate in
spanning tree (so that it could cause itself to be
elected Root). I'm not convinced this is an important
feature, but it can be handled by having the RBridge
pretend to be two boxes glued together: an ordinary bridge,
directly connected to the port, with a point-to-point imaginary
link to an RBridge. The person agreed this idea could be
built, and would give any advantages that might be gained
by having RBridges particpate in spanning tree, while
still maintaining the simple premise that RBridges,
like routers, operate above spanning tree, and do nothing
with spanning tree other than recognize that layer 2
multicast address and drop packets sent to that address.

If this (i.e., RBridges drop spanning tree messages)
is not the understanding at this point, can someone
summarize (succinctly, without cutting and
pasting from zillions of email messages, which I find
hard to follow) what the problem with this is?

Radia

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Wed, 14 Dec 2005 23:11:38 -0600

Dear All (following up from Radia's note),

> spanning trees, just like routers do.

I believe one idea has contributed to this - the idea that an RBRIDGE campus 
should look like a single very large bridge at its interfaces, which implies 
(in at least some e-mail) that it participates in the same spanning tree on 
both sides.

My apologies for cut-and-pasting, but the discussion has looked like this, 
in recent e-mail:

> --> > --> #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.
> --> Participate maps to what bridges do.

My understanding of Radia's note is that an RBRIDGE campus looks like one 
very large router at its interfaces (no spanning tree, so no spanning tree 
merge).

If I am not misunderstanding Radia's note, I like this answer, because it 
looked like a lot of work to figure out what to do, in order to look like 
one very large bridge. If this is the high-order bit, things are clearer.

Am I reading the note correctly? And do others agree?

Spencer

---

From: touch at ISI.EDU (Joe Touch)
Date: Wed, 14 Dec 2005 21:33:38 -0800

> spanning trees, just like routers do.

I'm one of the ones confused by the use of routers as an analog.

Routers terminate L2 broadcasts. Rbridges cannot. Routers decrement L3
TTLs. Rbridges cannot. So the assertion that an rbridge campus should
drop BPDUs - just like routers - doesn't follow.

So at the very least we need to explain the reason for this behavior
more clearly, in a way that does not refer to routers as equivalent.

AFAICT, having an rbridge campus drop BPDUs makes sense only by
effectively considering the rbridge campus as the root of all trees, but
that presumes it is always _the_ root (that there is only one 'drops
BPDU' system per bridged LAN). Since there's no way to enforce that
assertion, it seems problematic.

Joe

-------------- 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/20051214/2fdef187/signature.bin

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Wed, 14 Dec 2005 21:39:25 -0800

Yes Spencer,

You understood my note, and I'm glad you
agree with it. Apparently there was some confusion about
taking the phrase "looking like a bridge" too literally.

An RBridge campus should look like a single broadcast domain
to layer 3 devices, but that doesn't mean an RBridge should participate
in spanning tree, any more
than that if it had two token ring interfaces, that it should
pass the token from one interface to another. (though hopefully
this analogy won't confuse people, since a station on a
token ring *does* have to pass the token within that ring...
however an Ethernet endnode does NOT have to participate
in spanning tree (nor should it), and likewise, an RBridge
does not have to participate in spanning tree.

I think people were perhaps getting hung up on "layer n". Whatever
you call it, bridges are a lower layer than RBridges, and
RBridges are a lower layer than IP. So we could call RBridges
layer 2.5 if we insisted on giving them a layer name.

Radia

Spencer Dawkins wrote On 12/14/05 21:11,:
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

---

From: Radia.Perlman at Sun.COM (Radia Perlman)
Date: Wed, 14 Dec 2005 22:02:01 -0800

Joe Touch wrote On 12/14/05 21:33,:

> drop BPDUs - just like routers - doesn't follow.

I really don't understand what you're saying. RBridges can
terminate some L2 broadcasts, in particular, spanning tree messages.
True, RBridges will not decrement L3 TTLs.
And perhaps the assertion that RBridges should drop BPDUs does not
follow from the previous two sentences, but regardless, they
should drop BPDUs because that's what works, that's what is
simple, that's what makes the combination of bridging and RBridging
more robust than bridging alone, that's what preserves transparency
to layer 3 and yet increases robustness.
> more clearly, in a way that does not refer to routers as equivalent.

Hopefully the above explains why it has to work this way. We want
to break up the spanning tree into smaller and smaller spanning
trees, hopefully eventually getting rid of them entirely and
just having one big link state routed zero configuration infrastructure.

> assertion, it seems problematic.

The above paragraph makes absolutely no sense to me.

Routers drop spanning tree messages, and the world winds up with
lots of isolated spanning trees. The same thing happens with
RBridges. If there were a problem with doing it this way,
IP mixed with bridges would not work.

Radia

---

From: stbryant at cisco.com (Stewart Bryant)
Date: Thu, 15 Dec 2005 08:49:10 +0000

Radia

>they should DROP spanning tree messages.

Which surely means that a dual connected wiring closet gets
worse service from an RBridge network than a ST network
(because all the traffic goes one way rather than being
shared over both paths).

Stewart

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 15 Dec 2005 05:52:35 -0800

I think I might need a picture of what you're saying, but I think it's 
just the
opposite. RBridges can path split, just like routers can, whereas if the
spanning tree turns off one of the links, then a bridge would only use 
one of
the paths.

As I said, not sure of the exact topology you mean by "dual connected 
wiring closet"
(please supply picture), but if that topology works with routers, then 
it will
work with RBridges. Being an RBridge is really like being a router, but 
the destination is a layer
2 address rather than an IP address.

Radia

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Thu, 15 Dec 2005 08:44:16 -0600

Hi, Stewart,

I *know* that I need a picture of what you're saying. My immediate reaction 
was exactly the same as Radia's. I definitely want to better understand why 
I don't understand what you're saying.

In general, there are IP guys in this working group (I am one of them) with 
a decent understanding of bridging, but without a detailed knowledge of 
corner cases. If people who DO have a detailed knowledge of corner cases can 
explain fairly precisely what the situation is, it would help those of us 
who don't have that knowledge.

And, of course, the alternative is having a few people doing the work and 
everyone else trusting them, which can happen perfectly well without an IETF 
working group at all :-)

Thanks,

Spencer

---

From: stbryant at cisco.com (Stewart Bryant)
Date: Thu, 15 Dec 2005 14:54:05 +0000

> spanning tree turns off one of the links, then a bridge would only use 

The SPT situation is as follows:

     +----+
-----|    |    L1
-----| B1 |---------->To core
-----|    |
     +----+
        |
        | L3
        |
     +----+
-----|    |    L2
-----| B2 |---------->To core
-----|    |
     +----+

You want
B1 to connect a bunch of systems to the main network via L1
B2 to connect a different bunch of systems to the main network via L2

So you set B1 and B2 with low priority, so the root is to the
right in the main network, and the ports connecting B1 and B2 to L3
go into blocking.

Say most of the traffic is to some server S. This traffic will
be load balanced over both links L1 and L2.

Now replace the core with an Rbridge network, but leave B1 and B2
running SPT (because you can't upgrade the wiring closets - there are
too many of them)

How does the traffic from B1 and B2 to S get load balanced
via L1 and L2?

- Stewart

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Thu, 15 Dec 2005 16:07:54 +0100

Radia,

Radia Perlman wrote:

>elected Root).
I am the person you refer.

> I'm not convinced this is an important
I do agree

>hard to follow) what the problem with this is?
There is a lot of discussion going on . I make here some fast comments 
to state my position.
The point is that in my opinion DR election among Rbridges connected to 
same "link" (stp bridged area)
may be performed by the Root bridge election mechanism or a combined 
mechanism of both(DR and root election) , to be designed. I see 
advantages in this use of integration with the frame forwarding 
mechanism of stp (root bridge is the best position for it and for 
ingressing traffic into the Rbridge campus)
The current discussion on alternative modes (BLOCK, PARTICIPATE, etc) 
reflects the dilemma that derives from the need  Rbridges have to 
*control the tree connected to them*, to ingress and egrees traffic 
from/to them.
I see two options for predecibility of network.
1.-If only one Rbridge is allowed to become DR (i.e.root) of its link, 
some Rbridges (those not being elected) will not forward traffic of some 
ot the links they are connected to, because other connected Rbridge does 
the forwarding.
2.- If we allow any Rbridge to ingress/egress traffic to the Rbridge 
campus  we need to allow to split the link spanning tree in to 
independent segments, each one connected to an Rbridge (acting as 
independent root bridge or something equivalent). This goes a bit 
against the "unique" spanning tree dogma, but can be safe in an Rbridge 
controlled environment, provided each Rbridge acts as Root bridge to 
inject traffic to core network.
In my opinion, much of the complexitiy and confusion derives from the 
decision to allow bridges to interpose between Rbridges.
This makes many  links internal (whenever there is another Rbridge 
heard) and external (whenever they have an end system connected) at the 
same time. Using this term  in this way is  only confusing.
This flexibility of allowing standard bridges betwen Rbridges, as you 
know well, implies also the need to rewrite the destination Rbridge in 
the frame header at each hop with the next hop, a not very nice feature 
of the protocol proposed.  I find excesive in this case the price paid 
for  full compatibility with standard bridges.
In my recently submitted I-D draft   
(http://www.ietf.org/internet-drafts/draft-gibanez-trill-abridge-00.txt)  
I  propose, among other variants to Rbridges,  the topological 
restriction of  Rbridges being connected directly  by point to point 
links (which make sense talking of  campus network cores, oriented to 
performance).  By using an automatic compatibility mechanism like the 
one used in 802.1D for compatibility between STP and RSTP protocols, a 
port will set itself as "internal"  (core port in the draft) if it hears 
Rbridge hellos (or Rbridge related BPDUs) and  as "external" port 
("access" port) port mode. In this way the "external" links are excluded 
from the Rbridge core and the obtained core is fully composed of 
interconnected Rbridges.
In RSTP, a port hearing STP BPDUs in its link, switches to STP mode. It 
initializes to RSTP mode if it hears RSTP BPDUs upon initialization. 
(Protocol migration state machine).

As a summary I would say that it is difficult to ignore completely stp 
and links, Rbridges must PARTICIPATE in stp only as Root bridges or end 
nodes.
The compatibility clause (B-RB implementation) is acceptable, although 
is not perfect in my opinion  because I see the participation as Root as 
important for controlling the tree below Rbridge and to perform the DR 
function.
Guillermo

-- 
Guillermo Ib??ez
Departamento de Ingenier?a Telem?tica
Universidad Carlos III de Madrid
1.1.B.11 Colmenarejo 91-6241393
4.1.F.13 Legan?s 91-6248794

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Thu, 15 Dec 2005 16:22:39 +0100

Stewart,
    You are right. The core, whatever formed by bridges or Rbridges, 
must "take charge" of the traffic. Letting spanning trees to be
built freely leads to lose control and suboptimality.
Guillermo

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 15 Dec 2005 07:58:29 -0800

Radia Perlman wrote:
...
> IP mixed with bridges would not work.

IP mixed with bridges breaks L2 broadcast - on purpose. I was assuming
that rbridges did NOT do this. Is this incorrect?

Joe

-------------- 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/20051215/e6c6bacc/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Thu, 15 Dec 2005 08:02:59 -0800

Radia Perlman wrote:
> to layer 3 devices,

L3 has two kinds of broadcast: all 1's, and subnet.

All 1's corresponds directly to an L2 broadcast domain; subnet
broadcasts are depricated so we can skip them.

> but that doesn't mean an RBridge should participate

That logic is makes as much (or as little) sense as an rbridge
correlating to a router. Routers and hosts on L2 are L2 sources and L2
sinks. To the existing L2, external traffic transits the rbridge; the
rbridge sources and sinks no traffic to these external nodes.

-------------- 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/20051215/7ff3e1b3/signature-0001.bin