Subject: [rbridge] IS-IS per VLAN ?

From: gsankara at cisco.com (Ganesh CS)
Date: Thu, 22 Sep 2005 20:26:47 +0530

Hi,
 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 ?

Ganesh

---

From: mike at linx.net (Mike Hughes)
Date: Thu, 22 Sep 2005 16:21:06 +0100

> 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
-- 
Mike Hughes     Chief Technical Officer  London Internet Exchange
mike at linx.net   http://www.linx.net/
     "Only one thing in life is certain: init is Process #1"

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Thu, 22 Sep 2005 09:37:10 -0700

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

---

From: toms.sanders at gmail.com (Tom Sanders)
Date: Fri, 23 Sep 2005 14:46:56 +0530

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

--
Toms.

---

From: dino at cisco.com (Dino Farinacci)
Date: Fri, 23 Sep 2005 17:53:52 -0700

Sorry for the long email.

>> not have to store information for endnodes in VLAN A.

    And for the core-switches to not have to process LSPs with potentially
    constantly changing VLAN registration/deregistration. In a larger switch
    network with edge-switcehs with ports in the 100s and even 1000s of ports
    there could be constant change.

    If you use the IS-IS overlay model, then the core-switches just move 
    multicast packets among them to transport such packets to the edge-nodes.

    Also, architecturally, we are doing a hierarchical forwarding model here
    and not a hierarchical addressing model. Therefore, the core-switches, if
    they don't know about edge MACs shouldn't know about edge-VLANs either.

    I view the IS-IS instance that runs among the edge-switches simply as
    a transport of TLV-encoded information. All you need to run at this 
    instance is the Neighbor Hello machinery, DR election, and the flooding
    algorithim. You don't need to run SPF and argubaly you don't even need to 
    keep a link state database (and the LSPs don't have link information only
    VLAN and MAC encoded entries).

>> running over VLAN A were just normal data traffic.

    Just to be clear when I say multiple instances, I refer to a core IS-IS
    instance running among the core switches and another IS-IS instance running
    overlaid on the core among the edge-switches.

    I have heard on this list queries about running an instance per VLAN. I
    made a comment (maybe not very well in Paris) that we will have a tradeoff
    between fault isolation and scalability. If you want one IS-IS instance to
    run independently from the others (i.e. if it crashes only one VLAN is
    effected, if you want to reload that IS-IS with a new software release,
    if you want to limit DOS attacks, etc) then you go with separate instances.
  
    But separate instances will stress memory and CPU resources on the switch.
    Also, there are metro deployments that will want to deploy more than 4K
    VLANs, so the different sets of VLANs will have to be distinguished and
    now there are even more instances.

    This same argument comes up in L3 VPNs when a router designer has to
    decide to support 10,000 VRFs with 10,000 different instances of an IGP
    or BGP. The line seems to be drawn around 50 (or less) for separate
    processes/instances. So some fate-sharing of failures is inevitable at
    the benefit of scalability.

    I propose this:

    o One core-instance
    o One edge-instance
    o n Broadcast trees, one for each VLAN computed by the core-instance.
    o k Multicast trees, that span *across* VLANs so you get best bandwidth/
      link efficiencies where k is the number of sources times number of
      groups, where sources here are source edge-switches and not source end-
      nodes.

>> running over VLAN A were just normal data traffic.

    Yes, we use the broadcast tree for VLAN A here where each VLAN can have
    a different root and the spanning tree is computed by the core IS-IS
    instance.

>> to just flood all the information

    I think this all depends on how topological wide the rBridge network will
    span. You could have geographically close VPNs on a metro deployment 
    where flooding would be rather inefficient.

    I think this list really has to decide how large we anticipate an rBridge
    network is going to be. Traditionally, an L2 network is usually less than
    50 nodes and I would say the average is more like 10. If we stay with
    these sort of numbers, then we can under-optimize in the spirit of more
    simplicity.

>> a tree from the RBridge injecting the VLAN A information to the RBridges 

    The next question would be, would people deploy rBridges to do an 
    alternative to VPLS where the rBridges use tunnels over an IP network to
    connect each other. And then the same question of size should be asked
    for this environment as well.

>> email on the list if anyone

    Multiple instances seem to be what people want for Virtual Router type
    capability. But they seek to have separate management *and* failure
    domains more so than scalability. But the VPN/VRF folks want it the
    other way, where they want separate management domains but larger number 
    VPNs.

Dino

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Sat, 24 Sep 2005 22:29:57 +0800

Hi, Dino,

>    these sort of numbers, then we can under-optimize in the spirit of more

I agree that discussing a shared vision of the size of an rBridge network is 
a good thing to do. To start that discussion - When you say "L2 network", 
are you talking about a LAN segment, or a collection of bridged LAN 
segments?

Thanks,

Spencer

---

From: dino at cisco.com (Dino Farinacci)
Date: Sat, 24 Sep 2005 09:14:53 -0700

>> are you talking about a LAN segment, or a collection of bridged LAN 

    A collection of bridged LAN segments which usually is IP addressed as
    one IP subnet or in many cases multiple secondary IP subnets. And only
    needing a router if you are going off logical subnet.

Dino

---

From: touch at ISI.EDU (Joe Touch)
Date: Sat, 24 Sep 2005 09:52:21 -0700

> are you talking about a LAN segment, or a collection of bridged LAN 

L2 network should mean anywhere an L2 packet can reach with the its
header intact; that generally includes L2-connected LAN segments, esp.
since 'LAN segment' includes more than two nodes only for shared media
(wireless or somewhat antiquated variants of ethernet). Ways of
interconnecting the segments at L2 include hubs and bridges - which to
me are both kinds of switches.

As to the number of nodes on an L2, I've seen very modest installations
have over 200 in an office, and that doesn't include a university dorm
or cable modem system, which could be much higher.

While we're not defining an architecture by poll, does anyone have a
good estimate of the size of a large L2? (I'm guessing around 1,000, but
it's just a guess)...

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050924/16b54b0a/signature.bin

---

From: spencer at mcsr-labs.org (Spencer Dawkins)
Date: Sun, 25 Sep 2005 05:41:04 +0800

Hi, Dino,

OK, that's what I thought you meant.

Caution: I have managed networks before, but it wasn't recently... people 
with recent experience should probably be saying something :-)

The 10-50 device range is a little higher than what I was used to seeing in 
UNbridged LAN segments. Joe's "200 devices is a moderate size" seemed closer 
to what I expected for a collection of bridged LAN segments.

I look forward to the Problem Statement draft with baited breath, but I 
thought rBridges would be a way of using larger collections of L2 devices, 
since we would be tending to use more paths than just the spanning tree 
path. I think I understand that we're talking about the number of VLANs, not 
the number of L2 devices here, but would expect that there is a fair chance 
we would see larger numbers of VLANs in environments where there are larger 
numbers of L2 devices.

I'll let other people express an opinion now.

Spencer

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Sun, 25 Sep 2005 18:53:29 +0200

> or cable modem system, which could be much higher.

Joe,

are you counting the end-nodes, or just the bridges?

                     Harald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://www.postel.org/pipermail/rbridge/attachments/20050925/5101c616/attachment.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Sun, 25 Sep 2005 12:22:00 -0700

End nodes. I would expect bridges to be 1/5 of that number, roughly.

Joe

Harald Tveit Alvestrand wrote:
> ------------------------------------------------------------------------
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050925/aa28abe6/signature.bin

---

From: harald at alvestrand.no (Harald Tveit Alvestrand)
Date: Mon, 26 Sep 2005 07:30:54 +0200

--On s?ndag, september 25, 2005 12:22:00 -0700 Joe Touch <touch at ISI.EDU> 

> End nodes. I would expect bridges to be 1/5 of that number, roughly.

ah - then the numbers are much more compatible!

But that 1/5 number..... Why?

When I'm in big buildings, I usually see these fat bundles of Cat5 running 
from the panels in the offices to a central switching closet somewhere - 
10, 100 or even 1000 ports off the same switch.

In an 100:1 scenario, a 1000-end-node L2 network would have 10 bridges; in 
a 5:1 scenario, it would have 200 bridges. That makes an obvious difference 
to how far we have to make sure TRILL scales.

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 26 Sep 2005 08:07:53 -0700

> But that 1/5 number..... Why?

My guess. No reason, no computational logic. Just an estimate.

> to how far we have to make sure TRILL scales.

Agreed.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050926/76f52d6d/signature.bin

---

From: dino at cisco.com (Dino Farinacci)
Date: Mon, 26 Sep 2005 11:31:02 -0700

>> header intact; that generally includes L2-connected LAN segments, esp.

    You mean the *original* L2 header intact.  ;-)

Dino

---

From: dino at cisco.com (Dino Farinacci)
Date: Mon, 26 Sep 2005 11:35:44 -0700

>> My guess. No reason, no computational logic. Just an estimate.

    Sorry I wasn't clear. I was referring to the number of rBridge nodes, so we
    can understand how both the core-switch and edge-switch network needs to 
    scale.

Dino

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 26 Sep 2005 11:39:18 -0700

>     can understand how both the core-switch and edge-switch network needs to 

I would expect that a set of rbridge nodes could work anywhere a single
bridge could work, but that the overall total number of devices on the
L2 served by the system would not change substantially.

I.e., the primary goal of rbridge is better bandwidth between nodes by
the use of an alternative to a spanning tree inside the rbridge campus,
but it doesn't solve the problem that it's still part of the L2 system
into which it is plugged, and so I wouldn't expect scale to change much
- - EXCEPT where it is limited by spanning tree convergence.

Joe

---

From: dino at cisco.com (Dino Farinacci)
Date: Mon, 26 Sep 2005 15:23:07 -0700

>> - - EXCEPT where it is limited by spanning tree convergence.

    Good point.

Dino

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Tue, 27 Sep 2005 10:30:34 +0200

Joe Touch wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>
>
>Dino Farinacci wrote:
>  
>
I am not sure I understood well the argument provided by Joe on keeping 
the actual scale, so I apologize in advance  if I missed the point.
It seems a bit conservative to assume that the current L2 network size 
will not change.
The limitations to scale that current L2 networks have are well-known :  
broadcast storms that can propagate along the switched domain, spanning 
tree convergence (argument to be reviewed with RSTP), excessive ARP 
broadcast difussion, inefficient links usage by spanning tree algoritm. 
These problems increase with L2 domain  size and need to be alleviated.
Besides this, the Ethernet domains tend to grow in actual campus 
networks: more devices (sensors, PDA, displays) connected.  My 
understanding is that Rbridges should try to improve this situation and 
allow bigger network sizes under a single IP subnet. 
Regards
Guillermo

>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (MingW32)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDOEBWE5f5cImnZrsRAh+jAKCaflVr5EGAatUzPxbL9JHdTSzedACeP/SE
>muZvkqSgacJ5rmJ5J8C+iN4=
>=MU0/
>-----END PGP SIGNATURE-----

---

From: touch at ISI.EDU (Joe Touch)
Date: Tue, 27 Sep 2005 07:29:58 -0700

> Dino Farinacci wrote:
...
> - EXCEPT where it is limited by spanning tree convergence.
> 
> Joe
> 

It's not as much conservative as it is focus of the architecture or an
rbridge.

>> These problems increase with L2 domain  size and need to be alleviated.

While I agree with these issues, the point is that it is NOT the goal of
rbridges to address all of them.

Rbridges focuses on inefficient link use by spanning trees, and also
addresses convergence time.

It does NOT address broadcast storms either due to regular broadcasts or
address resolution. I'm not sure an L2 solution CAN deal with these; the
former is asking to flood, and flooding doesn't scale. The latter can be
replaced with centralized solutions (e.g., as was done in LANE for ATM),
but at the cost of robustness and zero-configuration.

>> allow bigger network sizes under a single IP subnet. 

The goal of an rbridge is better BW first, and hopefully better
convergence. This MAY have the side-effect of encouraging larger
installations, which should be addressed -- but supporting larger
installations is not a primary goal.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20050927/7e4f06f4/signature.bin