Subject: [rbridge] IS-IS per VLAN ?

From: Vishwas at sinett.com (Vishwas Manral)
Date: Fri, 23 Sep 2005 02:39:17 -0700

Hi Tom,

Extending what you are saying, using GVRP, for each VLAN detected we
would have to start a new instance of the Routing Protocol.

In my view we would not run multiple instances of the LS Routing
Protocol, but be running a single instances but logically divide the
topology. I am not sure, but Multi-topology extensions to Routing
Protocols could help in such a case.

Thanks,
Vishwas
-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Tom Sanders
Sent: Friday, September 23, 2005 2:47 PM
To: rbridge at postel.org
Subject: Re: [rbridge] IS-IS per VLAN ?

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.
_______________________________________________
rbridge mailing list
rbridge at postel.org
http://www.postel.org/mailman/listinfo/rbridge