[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