[rbridge] Per-VLAN DRB elections?

[Silvano Gai]

Caitlin,

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Caitlin Bestler
> Sent: Wednesday, May 09, 2007 9:40 AM
> To: Eric Gray (LO/EUS); Radia.Perlman at sun.com
> Cc: rbridge at postel.org
> Subject: Re: [rbridge] Per-VLAN DRB elections?
> 
> rbridge-bounces at postel.org wrote:
> > Radia,
> >
> > 	This gets back to "what is the logical model for
> > RBridge interactions with VLANs."
> >
> > 	If - as Joe has suggested at least once - the logical
> > model for an RBridge (instance) is specific to a single VLAN,
> > then this becomes very straight-forward.  All of the RBridges
> > in a single logical campus are necessarily in the same VLAN.
> >
> > 	There may be no VLANs - equating to a single logical
> > VLAN consisting of the untagged (default) VLAN.
> >
> > 	There may actually be an overlay of any number (up to
> > 4K) of VLANs that use a deployment of RBridge devices, where
> > each device has at least one RBridge logical instance for any
> > VLAN in which it is configured to participate.
> >
> > 	The elegance of this logical model is that there is L2
> > connectivity between only those RBridge instances that are
> > configured to participate in a common VLAN.  Hence, there is
> > a DRB election process that only includes RBridges that are
> > in the same VLAN, on any shared connectivity link.
> >
> > 	The advantage of this elegance is that it allows us to
> > define actual protocol interactions exactly as if there is
> > only one VLAN (which may be the default, unconfigured and
> > untagged VLAN).  It then is up to the implementers to "do the
> > right thing" as far as implementing 802.1Q correctly.
> >
> > 	This - in my opinion - is the way things should be
> > done, and I am curious as to who finds this model to be
unacceptable,
> > and why...
> >
> >
> 
> I agree with your approach, but differ on one very specific point.
> The one aspect of this model that I think is unacceptable is that
> it *requires* the RBridge to represent each VLAN instance separately.
> As covered on prior threads this is not always desirable. But once
> you allow RBridges that wish to support these features to do so
> (by allowing them to publish 'VLAN Group' information) then the
> rest of the interactions can indeed follow the simple model of
> thinking one VLAN at a time.

There is no externally visible VLAN grouping information in legacy
bridges and I am against having any externally visible VLAN grouping
information in RBridges.

The fact that internally RBridges may group VLANs is an implementation
detail, exactly like in legacy bridges.

-- Silvano

> 
> So taken as an absolute I do find exception to the model you propose,
> but I believe it is an exception that is more of an asterisk than a
> serious problem. If others have problems with the "per VLAN" approach
> I'd encourage them to do something similar that allows the feature
> they are considering while allowing RBridges not involved with that
> feature to keep the simple model of thinking about each VLAN
separately.
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge