[rbridge] Margaret's question about VLANs

[Greg Daley]

Hi Radia,

Radia Perlman wrote:
[cut]
> 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).

This actually helps to reduce the total cost of bridging in the spanning
tree where there is assymmetric traffic in the bridged network.

The existing STP doesn't include measurements of traffic flows in its
root bridge calculations.

If there's an RBridge which is likely to be the STP source or sink of a
lot of traffic, I think it's easy to show that even with symmetric
segment cost metrics, the sum of the traffic costs to the exit point is
lower when the entry/exit point is root bridge.

I'd have to revisit the calculation of this, but the idea has been
kicking around for a while. I'll post some of my thinking on this in the 
next mail.

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

This is a fair assumption.  I'm not sure how IS-IS would do this, but
if it was OSPF, you could have the Designated Router with the lowest
metric (likely to be selected as the best), and the Backup Designated
Router as the next most likely (with a slightly bigger preference
value), for simplicity's sake.

When links went up or down, and an STP recalculation was required, the
routers could advertise their preferences based on their Routing
protocol status within the LAN (and maybe use their 802 MAC addresses
as a tiebreaker).

Greg