[rbridge] IS-IS per VLAN ?
Radia.Perlman at sun.com
Thu Sep 22 09:37:10 PDT 2005
The reason for multiple instances is so that a core RBridge that is not
attached to VLAN A will
not have to store information for endnodes in VLAN A.
An alternative is to just flood all the endnode information for all
VLANs in a single instance of IS-IS.
This is certainly conceptually simpler. And the VLAN A endnode
information would not have to
appear in the forwarding table of an RBridge, R, that was not attached
to VLAN A. However, because
of link state reliable flooding, R *would* have to store the endnode
information in memory in
order to make sure that information gets flooded reliably to R's neighbors.
With multiple instances, R *still* needs to forward the information
(assuming R is on the spanning
tree for VLAN A), but R would only be forwarding in "datagram" mode, as
if the IS-IS instance
running over VLAN A were just normal data traffic.
So it's an interesting tradeoff. I don't have strong opinions about this.
So, for clarity, I see the choices we're discussing as:
a) single instance, where VLAN A information is flooded as essentially
opaque data by non-VLAN A
RBridges, but is reliably stored as part of the link state information
b) per-VLAN instance, where the core instance gives enough information
for RBridges to have the
link state information and the RBridge-VLAN info necessary to flood VLAN
to just VLAN A RBridges. Then an instance of IS-IS for VLAN A would use
to flood to just VLAN-A links in order to have the VLAN A RBridges share
with each other. Note the VLAN-A instance would see the topology as just
being a single link,
where all VLAN A RBridges were direct neighbors.
As for the tradeoffs I see:
1) if most RBridges support most of the VLANs, then it's clearly better
to just flood all the information
in one instance
2) if only a very few RBridges support a given VLAN, then having
multiple instances saves memory
in other RBridges. Furthermore, it saves traffic, because VLAN A
information only has to be sent on
a tree from the RBridge injecting the VLAN A information to the RBridges
that attach to VLAN A.
Note from the IS-IS implementers I talked to, they seemed to think that
having multiple instances
was not a big deal, but it would be better to have the discussion in
email on the list if anyone
has strong opinions.
Mike Hughes wrote:
>--On 22 September 2005 20:26 +0530 Ganesh CS <gsankara at cisco.com> wrote:
>> From end node learning preso(
>>http://www.postel.org/rbridge/trill-ietf63/trillendnodelearn.pdf ) I see
>>that IS-IS per VLAN has been recommended. Since there can be 4096 VLANs
>>per 802.1Q it looks like we may have to run 4096 IS-IS instances. Are we
>>going for this approach ? Is this a scalable solution ?
>I'm not 100% certain what this would gain in a core-type rbridge transport
>network. You would assume that all VLANs would be "flooded" throughout the
>core transmission infrastructure (so in the STP world could be done with a
>single spanning tree).
>MISTP/PVST seems to primarily be offered as a solution for dealing with
>making better use of redundant links by allowing different blocked links to
>exist for each VLAN, or where the VLAN and physical topologies are
>Unless I'm missing something, I can't work out what multiple instances of
>ISIS would achieve.
More information about the rbridge