[rbridge] I got some answers from the IS-IS mailing list
Anoop Ghanwani
anoop at brocade.com
Mon Jun 18 13:51:10 PDT 2007
Donald,
I think Silvano mentioned it is better to use
a multicast MAC address to identify IS-IS frames.
I assume this refers to the core IS-IS instance.
Then you mentioned that we wouldn't really need
to do filtering in the trill core based on
port state.
At which point I clarified that in the trill
core, when an rBridge receives a frame
it is required to filter multicast frames
if they are received on a port which is not
part of the tree indicated by the egress
rBridge address.
Thus there is some dependence on port state
even in the TRILL core and the kind of frames
that the rBridge would be willing to accept
and process from a port.
We could use the Ethertype or the MAC address
for this filtering, but right now, with the
MAC address for all multicast frames being
set to all-rbridges, it looks like the only
option we have is to use the Ethertype.
That's fine too.
Anoop
> -----Original Message-----
> From: Eastlake III Donald-LDE008
> [mailto:Donald.Eastlake at motorola.com]
> Sent: Monday, June 18, 2007 12:36 PM
> To: Anoop Ghanwani
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
>
> Anoop,
>
> Sure, but I was interpreting "blocking" to be the sort of things that
> 802.1 bridge ports do in any state other than the Forwarding
> state. That
> is, data doesn't go through and is not processed (except possibly to
> learn addresses). However, when blocked, 802.1 bridges still receive,
> process, and send BPDUs. (I'm ignoring all the various possible
> "port-to-port" things like 802.1AB and 802.1AE etc.)
>
> The corresponding thing for Rbridges is to not be the
> Designated Rbridge
> (DRB) on a port/VLAN pair. When you are not the DRB, native
> data doesn't
> go through and is not processed. However, any TRILL Ethertype frame is
> fine to receive, process, and, if appropriate, send. That
> processing may
> cause the frame to be discarded, as you point out below, but I just
> don't think of that as the same thing as throwing away a frame as soon
> as you notice that it is a native data frame received from a port/VLAN
> where you are not DRB or not emitting the native data frame inside a
> TRILL data frame you have received onto any port/VLAN pair because you
> are not DRB.
>
> Maybe we are just arguing about what words to use.
>
> In any case, my point was that in connection with "blocking" as I mean
> it above, I don't see any difference between TRILL IS-IS frames and
> TRILL data frames. So there is no particular reason to have two
> multicast addresses. In fact, depending just on the multicast
> address to
> by-pass blocking isn't right, because unicast TRILL data
> frames need to
> get through and, if there were any unicast TRILL IS-IS frames, they
> would need to get through also. Looking for the TRILL Ethertype seems
> like the best way to determine if a frame gets through "blocking".
>
> Donald
>
> -----Original Message-----
> From: Anoop Ghanwani [mailto:anoop at brocade.com]
> Sent: Monday, June 18, 2007 2:10 PM
> To: Eastlake III Donald-LDE008; Silvano Gai; rbridge at postel.org
> Subject: RE: [rbridge] I got some answers from the IS-IS mailing list
>
> Donald,
>
> Even in the TRILL network, you have to block frames
> with the all-rbridges address if the come in on a
> port that is not part of the tree identified by the
> egress rbridge address in the frame.
>
> Anoop
>
> > -----Original Message-----
> > From: rbridge-bounces at postel.org
> > [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III
> > Donald-LDE008
> > Sent: Sunday, June 17, 2007 8:57 PM
> > To: Silvano Gai; rbridge at postel.org
> > Subject: Re: [rbridge] I got some answers from the IS-IS
> mailing list
> >
> > I've got no problem with using destination address to bypass
> > blocked port state but the only thing you need to block are
> > native data frames.
> > Once a frame has been admitted by a DRB and converted into a
> > TRILL data frame, there is no reason to port block it. So
> > anything to the All Rbridges multicast address is fine.
> >
> > Donald
> >
> > -----Original Message-----
> > From: Silvano Gai [mailto:sgai at nuovasystems.com]
> > Sent: Sunday, June 17, 2007 1:22 AM
> > To: Eastlake III Donald-LDE008; rbridge at postel.org
> > Subject: RE: [rbridge] I got some answers from the IS-IS
> mailing list
> >
> > 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
> >
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> >
>
More information about the rbridge
mailing list