[rbridge] Per-VLAN DRB elections?

[Silvano Gai]

Caitlin,

> -----Original Message-----
> From: Caitlin Bestler [mailto:caitlinb at broadcom.com]
> Sent: Wednesday, May 09, 2007 1:30 PM
> To: Silvano Gai; Eric Gray (LO/EUS); Radia.Perlman at sun.com
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] Per-VLAN DRB elections?
> 
> 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 the VLAN grouping is FYI only, I don't have a big objection, but I
still don't understand why TRILL needs to deal with it in the basic
protocol draft. Why don't you write a separate draft that defines a
separate IS-IS TLV to carry this information?

It can still be done in the TRILL WG.

-- Silvano 

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