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

[Silvano Gai]

If we want to use the "inner.vlan = not present" to distinguish the core
instance from the per VLAN instance, we must specify that all TRILL
frames MUST have an explicit inner.vlan unless they are the ISIS core
instance.

-- Silvano

> -----Original Message-----
> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
On
> Behalf Of Anoop Ghanwani
> Sent: Thursday, June 28, 2007 7: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
> >
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge