[rbridge] VLAN Scoping / MAC Uniqueness
Radia.Perlman at sun.com
Tue Mar 13 11:26:11 PDT 2007
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
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
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
>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.
More information about the rbridge