[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