[rbridge] Per-VLAN DRB elections?

[Caitlin Bestler]

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.

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.