[rbridge] VLAN Scoping / MAC Uniqueness

[Radia Perlman]

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



Caitlin Bestler wrote:

>Radia Perlman wrote:
>  
>
>>With IS-IS flooding, an RBridge can't simply scan the
>>information for VLAN A and then delete it.
>>It has to store it, since LSPs have to be flooded reliably,
>>so each RBridge would have to keep all endnode information for all
>>VLANs. 
>>
>>    
>>
>
>I'm not following. If an RBridge is using globally scoped MAC
>addresses, and it receives endnode information for a VLAN that
>it does not support, the only thing I can see that it would have
>to do is to delete any information it had on the same MAC address
>on a different VLAN.
>
>It would never send to VLAN A, so why would it retain any information
>once the contradictory data was eliminated? A deleted record can be
>considered to be reliably delected, can't it?
>
>If it's knowledge of MAC Addresses is VLAN scoped then nothing
>about VLAN A is ever relevant. That is why it is a very simple
>solution, but one that creates an RBridge requirement for scoped
>learning that does not apply to simple Bridges.
>
>  
>