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

[Radia Perlman]

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