Subject: [rbridge] seeking input on abstract for problemand applicabilitystatement

From: petera at nortel.com (Peter Ashwood-Smith)
Date: Fri, 14 Oct 2005 00:35:57 -0400

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

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

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

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 14 Oct 2005 10:21:04 -0700

> the gather/sort and regeneration. A 'designated virtual bridge' so to

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

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

> _______________________________________________
> 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: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051014/c108b053/signature.bin