Subject: [rbridge] seeking input on abstract for problem and applicabilitystatement

From: michsmit at cisco.com (Michael Smith (michsmit))
Date: Wed, 12 Oct 2005 09:26:12 -0700

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Here's a proposed abstract.
> 
> Thoughts appreciated.
> 
> Joe
> 
> - -----
> 
> RBridges are layer-2 devices that automatically aggregate 
> into a virtual device that emulates a single bridge on a 
> conventional 802.1 Ethernet.

Within this mailing list, I think the above statement is understood but
to the rest of the community, I think it would be very confusing.  It
gives the impression that the set of rbridges are managed as a single
device, source L2 protocols as if from the same device, etc.  I would
summarize Rbridges as simply a new form of L2 bridges which use routing
protocols as the control plane.  A secondary point is that they
terminate the spanning tree domain of current bridges and attempt to
retain as much of the "plug-and-play" aspects of current bridges as
possible.  They don't really emulate a single bridge.

Michael

> 
> (I had thought that was a concise description, but with 
> recent discussion about non-participation in some bridge 
> protocols, I'm not sure. I still think the rbridge MUST 
> participate in order to avoid loops, but if that's 
> contentious it can't be part of the abstract yet...)
> 
> They combine layer 2?s ability to allow hosts to reattach 
> without renumbering with layer 3?s routing benefits. RBridges 
> use existing link state routing to provide higher internal 
> cross-section bandwidth, faster convergence under 
> reconfiguration, and more robustness to link interruption 
> than an equivalent set of conventional bridges using existing 
> spanning tree forwarding. They are intended to apply to similar
> L2 network sizes as conventional bridges and are intended to 
> be backward compatible with those bridges as well. This 
> document describes the need for RBridges and describes 
> situations where it will be useful.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDTFz0E5f5cImnZrsRAh/nAKCbhP6eVoNCX97zC9/L2zT0WXq9rQCdHBz/
> j6oUNPt5Rmv657FhszmCZzg=
> =EpCS
> -----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: Wed, 12 Oct 2005 10:09:07 -0700

Michael Smith (michsmit) wrote:
> -----
>> protocols as the control plane. 

That's better, IMO.

>> A secondary point is that they

Agreed - but I'm not sure whether the abstract needs to address spanning
tree termination - does it? It should say the part about retaining... as
well.

Joe