[rbridge] Margaret's question about VLANs

Radia Perlman Radia.Perlman at Sun.COM
Mon May 2 18:03:46 PDT 2005



Margaret Wasserman wrote:

>(2) How will TRILL be compatible with existing (dynamic and 
>non-dynamic) VLANs?
>

I was thinking about why it might be relevant how an RBridge learned 
that its link
was in VLAN A, whether it was configured, or found out because an endnode
attached (and the endnode knows what VLAN it's in or the RBridge figures it
out based on the endnode's IP address or something?) The current 
proposed design
seems compatible with both dynamic and non-dynamic VLANs.

However, now that you mention it, assuming by "dynamic VLAN", you mean
a link that becomes a VLAN A link because a VLAN A node attaches
to it, and stops being a VLAN A link when the endnode goes away),
I think there is one optimization I'd propose to make
dynamic VLANs work better, and which probably we should do anyway, even 
without
dynamic VLANs, which is to allow configuration of "priority" for an 
RBridge to
be chosen Root for a spanning tree to be computed from the link state 
database.
We should have an RBridge R not only inject "I am attached to VLAN A" into
the link state protocol, but it should also have a configurable 
priority, so that
it says "I am attached to VLAN A, and I have priority x for being the 
tree root for
the VLAN A spanning tree". That way, if R keeps "changing its mind" 
about whether
it's attached to VLAN A (based on whether there are any endnodes 
attached at this
moment), it will be less disruptive to the VLAN A spanning tree (since the
root won't be changing). Even without VLANs, where the entire campus is one
broadcast domain, I could imagine someone wanting to tweak which Rbridge is
the root of the computed spanning tree (the one for unknown 
destinations, and for
multicasts).

Even if it's not a parameter, I could imagine having an RBridge inject a 
default priority
if it's hard-configured to be attached to VLAN A, and a different 
default priority if
its attachment to VLAN A might be transitory (because it's based on what 
endnodes happen
to be attached).

Radia




More information about the rbridge mailing list