[rbridge] Per-VLAN DRB elections?
Caitlin Bestler
caitlinb at broadcom.com
Wed May 9 13:30:18 PDT 2007
Silvano Gai wrote:
> Caitlin,
>
>>
>> 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.
>
An RBridge that does support VLAN Grouping is not required to
do anything with this information. It is clearly of value and
leads to simpler configuration for RBridges that do support
VLAN Grouping. I don't see the value in excluding information
that has no real cost to other RBridges from the exchanged
information. We are talking about one extra VLAN-ID in the
per-VLAN instance (an optional VLAN ID of the master group).
It is easily initialized to NULL, and even more easily ignored.
If RBridge implementations are allowed to support VLAN Groups
*anyway* then the benefit of having this information available
in a standard way clearly outweighs the cost of two bytes of
storage per instance.
More information about the rbridge
mailing list