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

[Eastlake III Donald-LDE008]

Anoop,

See below at @@@

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Monday, June 18, 2007 4:51 PM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] I got some answers from the IS-IS mailing list

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.

@@ I may be wrong but I thought he wanted to use a different multicast
address for all TRILL IS-IS frames because they are control messages and
thus should get through when an Rbridge port is "blocked" (not DRB). But
TRILL data frames should get through also.

Then you mentioned that we wouldn't really need
to do filtering in the trill core based on 
port state.

@@2 What is the "trill core"? If you are not DRB for some port/VLAN, you
need to discard incoming native data frames and not emit native data
frames no matter where in the campus you are.

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.

@@@ Sorry, but I find you use of "filter" a little confusing. Yes, that
check and others are performed on multicast TRILL frames when they are
received by any Rbridge. I still don't know what you mean by "trill
core". There are no "trill core Rbridges" as opposed to "peripheral
trill Rbridges" or something...

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.

@@@ To me, "port state" for an Rbridge is whether it is Designated
Rbridge for a particular port/VLAN. Sure, this affects whether or not it
will accept or emit native data frames. But this "port state" has no
effect on whether it will process any TRILL Ethertype frame. Nor does
the "port state" have any effect on whether that TRILL frame meets any
of the various tests such as, if it is multicast, the tree test you
mention.

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.

@@@ All frames sent to the All-Rbridges multicast address are TRILL
Ethertype. There are also unicast TRILL data frames. How a frame is
affected by port state corresponds to whether or not it is TRILL
Ethertype. How a frame is affected by port state does not correspond
with whether or not it is sent to the All-Rbridges multicast address.
The filtering on port state has nothing to do with whether a frame is
"TRILL IS-IS" versus "TRILL data".  I do not see how port filtering
would be helped by having a different TRILL IS-IS multicast address.
Whether there are one or two multicast addresses, it is still the case
that trying to filter based on a combination of port state and multicast
address(es) will be incorrect but filtering based on port state and
Ethertype will be correct.

Anoop

@@@ Donald