[rbridge] VLAN Scoping / MAC Uniqueness
Radia Perlman
Radia.Perlman at sun.com
Mon Mar 12 15:49:36 PDT 2007
Yes. There are three ways of sending per-VLAN endnode information:
a) a single instance of IS-IS for both "core" information and "endnode"
information. Endnode
information would be marked as (VLAN ID, {set of endnodes}).
RBridges that are
not in VLAN A would need to store the VLAN A endnode information, and
all endnode information would
go to all parts of the campus
b) two instances of IS-IS: one for core information (which RBridges are
connected to which other
RBridges, and which VLANs are attached to which RBridges), and one for
endnode information. Not
sure what advantage/disadvantage this has over a), since all link state
information would go to all RBridges.
c) n+1 instance of IS-IS, where n is the number of VLANs that are in
use. Each RBridge R1 would run
k+1 instances of IS-IS; the core instance, and one for each of the k
VLANs that R1 is attached to.
The advantage of this is that flooding of endnode information for VLAN A
need not be stored by
any RBridges except those that attach to VLAN A. Also, because the core
instance enables flooding
of VLAN multicast just to links that are interested (RBridges that are
attached to VLAN A), there is
further optimization because this information does not need to traverse
all the links in the campus; just
those needed to get the packet from the RBridge that originates the LSP
for VLAN A endnode
information to the RBridges that attach to VLAN A.
I prefer c). I don't think there is that much overhead to running n
instances. It's really like separating
the endnode information into distinct LSPs. Except for...the Hello
Protocol. If all RBridges are connected
to 4000 VLANs, then they'd all be sending 4000 Hellos, one for each
instance. The core instance Hellos
are a bit different -- they only go to direct neighbors. But the VLAN
instances get flooded by the core
to all links throughout the campus attached to that VLAN.
We could eliminate the hello protocol for the per-VLAN instance of
IS-IS, since there's enough information
in the core instance for all VLAN A RBridges to know about each other
and decide which should be
Designated (for sending out CSNPs).
Radia
Erik Nordmark wrote:
> Radia.Perlman at sun.com wrote:
>
>> I don't agree that we have to explicitly advertise which VLAN a MAC
>> address belongs to, because
>> each VLAN runs its own instance of IS-IS in which endnodes are
>> announced. This could be looked
>> at as implicitly advertising the VLAN. In other words, the endnode
>> information is announced in
>> an instance of IS-IS distinguished by having an inner VLAN tag (I
>> think that's how we differentiate it).
>> Core RBridges forward it like a multicast packet for that VLAN. Only
>> border RBridges of that VLAN actually
>> store the information.
>
>
> That is true if you are required to have N IS-IS VLAN instances when
> there are N VLANs in use.
>
> I don't know if that is overkill when all the RBridges are all part of
> all N VLANs - basically when it is just different subsets of
> stations/hosts that make up the different VLANs.
>
> Erik
More information about the rbridge
mailing list