[rbridge] IS-IS per VLAN ?

[Dino Farinacci]

    Sorry for the long email.

>> 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.

    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).

>> 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.

    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.

>> 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.

    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.

>> 1) if most RBridges support most of the VLANs, then it's clearly better 
>> to just flood all the information
>> in one instance

    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.

>> 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.

    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.

>> 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.

    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