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

[Silvano Gai]

I disagree; current bridges distinguish control frames (BPDUs, CDP,
LLDP, GARP, etc) on reserved MAC addresses.

Remember that these control frames need to bypass the blocked port state
(due to ST or DRB election). 

Today we have port logic that checks a set of registers for MAC
addresses of frames that need to bypass the port state. 

It is much more difficult to parse a frame to understand if applying or
not the port state.

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Eastlake III Donald-LDE008
> Sent: Saturday, June 16, 2007 8:11 PM
> To: rbridge at postel.org
> Subject: Re: [rbridge] I got some answers from the IS-IS mailing list
> 
> 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
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge