Subject: [rbridge] seeking input on abstract for problemand applicabil itystatement

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 14 Oct 2005 15:49:37 -0300

Joe,

	I want to address specific comments/questions you 
had below:

-> All of this sounds like stuff the rbridge already 
   needs to do; there needs to be an internal spanning 
   tree anyway.

We have not yet decided how many "spanning trees" there
needs to be, and that is a part of the problem.  One of
the goals of the original proposal - as I understand it
- was to allow efficient use of redundant links that may 
exist between RBridges.  

This is why the confusion keeps coming up with the use 
of the term spanning tree.  Its NOT the right term in 
the RBridge context, because the RBridges WILL NOT be
turning ports off and WILL be forwarding distinguishable
streams of frames on as many of the available links as 
it makes sense to use, given the destinations and - for
example - VLAN contexts that apply to each stream.

Another goal - again as I understand it - is to reduce
the time for convergence on spanning trees for those
portions of the network that MUST use STP (the bridges).
For that goal to be achieved, it is a good idea not to
extend STP across the RBridges.

Finally, there is a huge "chicken-and-egg" problem with
any intention to have RBridges participate in STP.

The "spanning tree(s)" determined by RBridges are the
result of shortest path analysis of reachability info
provided by IS-IS.  If this is not the case, then there
was never any reason to suggest using a shortest-path,
Link State Routing Protocol in the first place.

However, before the RBridges can reliably determine
link state and advertise reachability, any "internal"
bridges MUST have already determined a spanning tree
(using STP).  As I pointed out previously, and Radia
stated as well, bridges typically do not forward during 
STP, consequently some or all of the links between the
RBridges will be DOWN as far as IS-IS is concerned.

Also, again as pointeed out previously, "internal" and 
"external" are topologically meaningless terms as far 
as RBridges are concerned - unless that information is
explicitly configured.  Consequently, default RBridge
behavior really MUST be to ignore STP on any port not
explicitly configured to participate in STP.

Also, because the link state between RBridges is not
determined until after any internal STP required has
been completed between bridges that may be involved 
in those links, either the RBridges have to wait a
pre-determined period of time (to blindly allow for 
"internal" STP) or send topology change BPDUs on all 
ports every time they discover new links. Either way 
will result in potentially huge delays in overall STP 
convergence time for the network.

-> I'd like someone to explain which of these are valid 
   if we replace the rbridge campus with an existing 
   bridge.

I am not sure that this concept of a "virtual bridge"
is - or ever has been - a goal for RBridges.  If you 
want a "virtual bridge", one approach that already is
out there is VPLS.  Consequently, why would we need
to specify how to do it with RBridges?

If it is not a goal, then the notion of replacing an
RBridge with a single bridge is not something we need
to consider.

-> My understanding is that PARTICIPATE is valid, if not 
   required. TRANSPARENT seems like it turns the bridge 
   into a hub. And BLOCK would break things.

Assuming that this _is_ a goal, there is no particular
reason why someone would not replace a hub (even a 
"virtual hub") with a bridge.  For reasons explained
above, however, PARTICIPATE - while potentially valid
- is extremely undesirable.

Transparent also is not good because the path through
the RBridges will not exist (or not be complete) until 
A) STP is completed between any "internal" bridges and 
B) the RBridges have converged on a complete LSDB and 
determine SPSTs (shortest path spanning trees).

So, even with Transparent, the insertion of RBridges
would result in increased STP convergence time, even
if the network size has not changed.

In addition, TRANSPARENT would require configuration
of the RBridges to recognize "external" interfaces -
since it is clearly not the case that, even in this 
mode, you would want bridges inside an RBridge campus
to participate with bridges outside that campus.  As
implied previously, having all bridges - both inside
and outside of an RBridge campus - participating in 
forming a single spanning tree would prevent using
redundant paths (and would very likely drop RBridge
ports out of the topology as the corresponding bridge
ports - at the other end of the physical link - are
put in the non-forwarding state).

--
Eric Gray

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Joe Touch
--> Sent: Friday, October 14, 2005 1:21 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] seeking input on abstract for problemand
--> applicabilitystatement
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge

Earlier, Joe Touch burbled...
--> 

Peter Ashwood-Smith wrote:
>>But isn't this just what STP does?
>>I.e., a bridge:
>>	
>>	accepts BPDUs as input
>>	determines an internal spanning tree based on port selection
>>	emits appropriate BPDUs on those ports
>>
>>Why isn't this exactly what an rbridge needs to do? I.e., neither a
> 
> bridge
> 
>>nor an rbridge 'transparently' forward BPDUs, but both are nodes in the
>>resulting spanning tree.
> 
> 
> Hmmm so you have added yet a third possibility. At this point I think
> giving them names is probably helpful. Here is what I'd suggest.
> 
>   [BLOCK]       Rbridge block BPDU's 
>   [TRANSPARENT] Rbridge transparently passes BPDU's
>   [PARTICIPATE] Rbridge participates (accepts/modifies/forwards BPDU's)
> 
> 
>>This still provides a benefit for an rbridge - that it is just ONE
> 
> node in > the spanning tree, not O(#rbridges) or even O(#egress
> rbridges).
> 
> Yeah, but its messy to implement this kind of thing. We refer to that as
> an abstract node in routing. Making a network appear as a single node to
> its neighbors. It requires more 'internal' messaging between the
> different 'parts' of the abstract node to create this illusion. For
> example the BPDUs must be gathered and sorted etc. so you'd have to
> elect one of the 'parts' of that node to act on behalf of the others, do
> the gather/sort and regeneration. A 'designated virtual bridge' so to
> speak.

All of this sounds like stuff the rbridge already needs to do; there
needs to be an internal spanning tree anyway.

> I'd suggest that the I.D mention the three (giving them concrete names
> to avoid further confusion). Personally, and I think from the emails it
> sounds like we'd recommend BLOCK, allow TRANSPARENT and leave
> PARTICIPATE for further study? (I can hear the graduate students
> sharpening their pencils already).

I'd like someone to explain which of these are valid if we replace the
rbridge campus with an existing bridge.

My understanding is that PARTICIPATE is valid, if not required.
TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would
break things.

> Oh, speaking of TRANSPARENT, it may be a very useful mode during a
> migration since it allows the installation of rbridges without affecting
> the bulk of the paths. BLOCK would result in a sudden change in root
> bridge on one side of the Rbridged network with resulting sudden shift
> in traffic patterns. For some carefully crafted networks that sudden
> change may be a bit of a shock and an impediment to migration so while
> undesirable in the final state, it may be useful during transition ...
> unless we mandate ships in the night with a quick switchover when all
> bridges were replaced with rbridges ... but I've not seen this done very
> often successfully.
> 
> Peter Ashwood-Smith
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 14 Oct 2005 14:15:17 -0700

> example - VLAN contexts that apply to each stream.

I'm not sure I agree. The edges are individual spanning trees. The
rbridge can have more than one internal path between two edge trees, but
that's it, that's all the redundency that's provided. Turning off ports
on the outside edge of the rbridge has no effect on the internal
multipath potential.

> extend STP across the RBridges.

I definitely disagree with this. Rbridges have nothing to do with the
convergence of the spanning tree external to them, IMO. All they do is
have their INTERNAL routing converge faster than spanning tree would
have - that's where the benefit comes from. I never thought it had
anything to do with an effect on the external trees.

> RBridges will be DOWN as far as IS-IS is concerned.

That's just like adding a bridge to an existing bridged system. The new
bridge doesn't forward frames until STP finishes, but the existing
bridges can finish just fine. The rbridge is the 'new' bridge. All the
other bridges are the existing bridge system. No chicken and egg,
AFAICT; the sequence is determined by rbridge's reliance on bridges.

> explicitly configured to participate in STP.

Yes. And not to forward ingress frames until internal routing (IS-IS in
this case) is established. At that point, STP should be enabled at the
'edges', STP PARTICIPATEd, and -then- ingress enabled.

What's the problem?

> convergence time for the network.

Again, I'm back to 'what would a bridge do'. Either this is a bridge
(PARTICIPATE) or a link (e.g., hub, which means TRANSPARENT). Those are
the only two options that have correlaries in existing L2.

> is - or ever has been - a goal for RBridges.

It's not a goal; it's a definition, IMO.

> If you 

VPLS, depending on where I look, are either pseudowires (virtual hubs)
or L2 over L3. Rbridge is L2 over L2 with routing.

> - is extremely undesirable.

If you replace a hub with a bridge that refuses to PARTICIPATE, what's
the effect? Nothing. That assumes that hubs weren't in rings, which they
weren't supposed to be.

However, you CAN wire bridges in rings and they're supposed to do the
right thing. That's only because they PARTICIPATE, though.

> determine SPSTs (shortest path spanning trees).

I already answered this in a separate email; yes, both of these steps
need to happen in order, and they will.

> if the network size has not changed.

That's an interesting question - that may be the result of having an
internal routing protocol that isn't setup ahead of time. I.e., maybe
rbridges DO take longer to *initially* converge the STP of an existing
net, but react faster *afterwards* to changes.

> of the RBridges to recognize "external" interfaces -

The need to know which interfaces they can reach rbridges on, which can
(and should) be autoconfigured.

> put in the non-forwarding state).

I also already answered this - rbridges can't make redundent paths in
the non-rbridge portion of an L2 net. They can only do so within the
rbridge.

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/20051014/bb5dd0b1/signature.bin