[rbridge] VLAN Scoping / MAC Uniqueness
Radia.Perlman at sun.com
Mon Mar 12 18:35:32 PDT 2007
I'm not sure I understand what you're saying. But I think the issue is
how link state information is distributed.
The core instance link state information is flooded to all RBridges, but
transmitted hop by hop. That means
every RBridge, including core RBridges that do not attach to any VLANs,
have to store this information,
in addition to forwarding it, in case it needs to be retransmitted to a
neighbor, or transmitted to a new
neighbor that might come up later.
As the spec currently is, the endnode information is multicast. So R1,
attached to VLAN A, just multicasts
a single copy of its VLAN A information, and it gets distributed by the
core like any VLAN A multicast
data packet. It magically gets received just by RBridges attached to
VLAN A. Only RBridges actually
attached to VLAN A need to store this information. It is not sent
reliably neighbor-to-neighbor. Only
R1 has to ensure that all the relevant RBridges have received the link
state information about VLAN A.
THe intervening RBridges just forward it and forget it.
So as I said, you could get rid of running the per-instance IS-IS
hellos, by just listing, in the core
instance LSP, which VLANs you attach to. There really isn't anything
that the per-VLAN instance
of the hello protocol
needs to know that isn't already in the core instance link state
information, so we could eliminate running
4000 Hello and Designated RBridge elections.
However, the per-VLAN link state information (listing the endnodes) is
potentially large enough that
I believe it is useful to avoid having non-VLAN-A RBridges keep track of
the VLAN A endnodes (and
VLAN A IP groups and multicast routers).
And if we are using multicast to distribute, I don't see how R1 can
choose which RBridges to send the
information to, or to format it differently depending on the recipient.
For as many as possible of these sorts of things that are OK to do
either this way or that way, I think we should choose,
rather than making it a parameter.
Caitlin Bestler wrote:
>One suggestion that I think is adequate:
>RBridge Hello messages would be from the core instance
>and sent to core instance. It would list the VLAN IDs
>and whether it maintained a single destination database
>or a per VLAN database.
>In the latter case, other RBridges would only forward
>relevant advertisements to RBridges that advertised the
>relevant VLAN. An RBridge using an unscoped database
>would be send all address advertisements.
>Alternately, we could explicitly require per VLAN scoping.
More information about the rbridge