[rbridge] I got some answers from the IS-IS mailing list

[Anoop Ghanwani]

Radia,

Using learning at the edge Rbridges definitely
addresses the scaling issue for unicast.

>From your note below it's not clear if we're
still going to have per-VLAN instances of
IS-IS.  If we do, I still think we would 
have problems with it.

One can always make an argument that a 
802.1Q bridge doesn't realistically need
to support 2K or 4K or whatever number 
of VLANs.  However, they do support it, 
and there are customers out there that 
configure that many VLANs.

If TRILL is even moderately successful,
we will likely encounter networks where
an rBridge needs to participate in 1000s
of VLANs.

Anoop

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Radia Perlman
> Sent: Friday, June 15, 2007 9:12 PM
> To: rbridge at postel.org
> Subject: [rbridge] I got some answers from the IS-IS mailing list
> 
> 1) They have deployed a variant of IS-IS, and the way they 
> distinguish their instances is based on having a new 
> multicast address. I wrongly remembered IS-IS, and thought 
> that PSNPs got unicast, but even those are multicast (and I 
> remember the reasoning at the time this was decided 100 years 
> ago, which was to suppress lots of routers sending the same 
> PSNP). So, for encoding TRILL IS-IS, it can be differentiated 
> from layer 3 IS-IS by having a different multicast address. 
> The bit in the header works too, however.
> 
> 2) I checked to make sure that "0" would be OK to use as an 
> area address, and it is.
> 
> 3) The solution I proposed to the scalability issue of having 
> a zillion pseudonodes on a LAN (having the DR give the same 
> name to all the pseudonodes that get spawned by running the 
> Hello protocol on a link according to each VLAN the DR 
> supports) works. 
> I was worried
> about nontransitive connectivity (R1, the DR, names the 
> pseudonode R1.1, and issues an LSP on behalf of the 
> pseudonode claiming to be attached to all the RBridges on the 
> link that can talk to R1 via any of the VLAN tags. But even 
> though R2 can talk to R1 (using VLAN tag A) and R3 can talk 
> to R1 (using VLAN Tab B) does not mean that
> R2 and R3
> can talk to each other.)
> 
> Interestingly, way back when IS-IS was DECnet phase V, and we 
> were worried about weird hardware problems creating 
> nontransitive connectivity, we put in what R2 should do when 
> the link state database implies R2 can talk to R3 through the 
> pseudonode, but
> R2 can't really talk to R3 -- R2 sends to the DR).
> 
> So we can use this solution. So does that (and learning from 
> data packets rather than announcing all endnodes in per-VLAN 
> instances of IS-IS) answer everyone's scalability concerns?
> 
> Radia
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge