[rbridge] IS-IS per VLAN ?

[Tom Sanders]

I would prefer to have a single instance of ISIS running, that has all
the vlan information irrespective of whether it is attached to a
subset of vlans or not. I see an issue in running multiple instances:

What if an Rbridge at some later time is configured for vlan A, a vlan
for which it wasnt configured before? If so,  then we need to have an
algorithm that syncs up its LSD for Vlan A.

If OTOH, we have a single instance running then this isnt an issue at all.

Toms.

On 22/09/05, Radia Perlman <Radia.Perlman at sun.com> wrote:
> 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
> A information
> to just VLAN A RBridges. Then an instance of IS-IS for VLAN A would use
> that ability
> to flood to just VLAN-A links in order to have the VLAN A RBridges share
> endnode information
> 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.
>
> Radia
>
>
>
> 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
> >significantly non-concurrent.
> >
> >Unless I'm missing something, I can't work out what multiple instances of
> >ISIS would achieve.
> >
> >Cheers,
> >Mike
> >
> >
>
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
>


--
Toms.