[rbridge] IS-IS per VLAN ?

[Radia Perlman]

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