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

[Eastlake III Donald-LDE008]

While I think that multicast addresses are cheap, so we could certainly
get two, I don't see any advantage to having two: presumably
"All-Rbridges-Data" and an "All-Rbridges-ISIS" multicast addresses. You
definitely want different multicast addresses if you have different
listeners, but in this case all Rbridges would have to list for both
multicast addresses.

Both TRILL Data and TRILL IS-IS messages have the same structure of
TRILL header and it seems easier to figure things out from that header
rather than having to keep track of one extra bit from earlier in the
frame from the multicast address.

The variant of IS-IS that the IS-IS working group deployed did use a
different multicast address from the one used for level one IS-IS
routers, the multicast address "All-Level-1-ISs". We are already using a
different multicast address from that, just like they did, by using the
multicast address "All-Rbridges".

Thanks,
Donald

PS: There is also an "All-Level-2-ISs" multicast address in IS-IS which
isn't relevant as the TRILL usage of IS-IS is Level 1.

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Silvano Gai
Sent: Saturday, June 16, 2007 11:24 AM
To: Radia Perlman; rbridge at postel.org
Subject: Re: [rbridge] I got some answers from the IS-IS mailing list


If this is the case I will use the multicast address to distinguish
TRILL ISIS not an extra bit in the header.

-- Silvano

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

_______________________________________________
rbridge mailing list
rbridge at postel.org
http://mailman.postel.org/mailman/listinfo/rbridge