[rbridge] VLAN Scoping / MAC Uniqueness

[Caitlin Bestler]

Radia Perlman wrote:
> The current spec (and my understanding) is that membership of
> VLAN A would be distributed as link state information in
> IS-IS. If we include this in the link state information in
> the core instance, then every RBridge has to store it all,
> since IS-IS flooding requires every RBridge to store all (the
> most recently generated from each RBridge) link state
> information. R1 doesn't just look at the link state
> information and decide what it's interested in and delete the
> rest. R1 has to keep it in order for the reliable flooding to work.
> 
> With the way the current spec is written, endnode information
> is *NOT* distributed in the core instance.
> Instead, VLAN A information
> is distributed like a VLAN A multicast data packet, which
> means the core RBridges distribute it along a tree, filtered
> so as not to unnecessarily go on branches that don't lead to
> VLAN A links.
> 
> With that design, the only RBridges that would see
> information about VLAN A endnode membership are RBridges
> attached to VLAN A.
> The topology that the IS-IS instance for distributing VLAN A
> sees is as a single hop, with all RBridges attached to VLAN A being
> neighbors. 
> 
> There is a variant of this design that would have the
> property you are imagining; that all endnode information goes
> everywhere, gets seen by all RBridges, and that only RBridges
> in VLAN A have to actually store the information. That is to
> have a multicast distribution tree that sends things to *all*
> RBridges that attach to endnodes. This is a subtly different
> distribution mechanism than the core instance. If there are
> core RBridges, not attached to any endnodes, they would just
> pass the link state information along. And a "border" RBridge
> R2 (one that does attach to endnodes) would be allowed, if it
> chose, to simply scan VLAN A information and then delete it,
> since R2 would never need to forward this link state
> ifnormation to a neighbor.
> 
> I still prefer the way the spec is now, since I think the
> advantage of noticing endnodes moving to a different VLAN is
> outweighed by the downsides (more cost to distribute endnode
> information, and the ability for nasty behavior of an endnode
> in VLAN A to disrupt VLAN B maliciously, and confusion when
> nonmaliciously an endnode resides on multiple VLANs with the
> same MAC address.
> 
> Radia
> 

It might be sufficient to merely note that any RBridge attempting
to maintain global scoping of MAC Addresses needs to be aware that
the distribution of endnode information is optimized for per-VLAN
scoping. Because of this it MUST NOT rely on prompt notification
of migration of a MAC Address to a new VLAN on a different RBridge.

I also agree that it makes sense to optimize the wire protocol
on the assumption that typical RBridges will do per-VLAN learning.