[rbridge] a clarification about the core IS-IS instance

[Eastlake III Donald-LDE008]

Hi Anoop,

That looks about right, although you also have to check that the inner
length/type field is in the length range. And if you determine that a
TRILL IS-IS frame is for a per VLAN instance, you still don't know if
you should process as well as forwarding it until you check whether you
are DRB for a link with an end station in that VLAN.

Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Thursday, June 28, 2007 10:00 AM
To: Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] a clarification about the core IS-IS instance

Hi Donald,

Thanks for the clarification.  Yes, I do remember
the discussion on the list.  At that time it looked
like the Ethertype would tell if the frame was IS-IS.
It now looks like even the core IS-IS instance will
use a DSAP/SSAP (for some reason I thought we were
going to use a new Ethertype for the core IS-IS
instance).

So, to identify a core IS-IS frame (which all RBridges
should be interested in) one would have to check for:
outer.etype = trill
inner.dsap = xx
inner.ssap = xx
inner.ctl = yy
inner.vlan = not present

The V bit doesn't really seem all that useful since
both the core frames and the per-VLAN instance have
it set, so that bit doesn't tell one whether or 
the packet needs to be processed as a control 
packet at a given RBridge.  The above fields are
necessary and sufficient.  Please let me know if
I'm missing something re the V bit.

Thanks,
Anoop

> -----Original Message-----
> From: Eastlake III Donald-LDE008 
> [mailto:Donald.Eastlake at motorola.com] 
> Sent: Wednesday, June 27, 2007 9:09 PM
> To: Anoop Ghanwani
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Hi Anoop,
> 
> Yes, that was a change that was extensively discussed on the 
> mailing list. There wasn't a formal consensus determination 
> but it was clear that the sentiment of the group was to 
> always have a TRILL Header on TRILL IS-IS frames and use a 
> formerly reserved bit in the header to distinguish a TRILL 
> IS-IS frame from a TRILL data frame whose contents happens to 
> be a (presumably layer 3) IS-IS message.
> 
> I believe your second point is correct. Checking for the 
> TRILL Ethertype is the key to deciding whether to process a 
> frame if you are not DRB on that port and VLAN. (This ignores 
> the bridging/media frames sent to the block of multicast 16 
> addresses reserved for that purpose.)
> 
> Thanks,
> Donald
> 
> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani
> Sent: Wednesday, June 27, 2007 9:42 PM
> To: rbridge at postel.org
> Subject: [rbridge] a clarification about the core IS-IS instance
> 
> From reading the previous version of the draft I got the 
> impression that frames sent as part of the core IS-IS would 
> not contain a trill header or inner header.  However, on 
> reading this version, it looks like the core IS-IS instance 
> would in fact contain a trill header.
> 
> Assuming that the above is true, would it be safe to assume 
> that an RBridge, for a port that is connected to a LAN for 
> which it is not a DRB, will drop all frames whose Ethertype 
> does not indicate trill?
> 
> Anoop
>