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

Fri Jun 29 12:55:43 PDT 2007

Hi,

I've been thinking about this some more and come to the conclusion that,
with the arrangement added in protocol specification -04 where a TRILL
Header is always present, we don't need a bit to distinguish TRILL IS-IS
frames from TRILL data frames. That's because we can do so using the
inner MAC destination address.  There isn't any need for any additional
multicast addresses.

There are different ways to order the tests that are equivalent but here
is how I think of it (leaving out some details like VLANs for clarity):

The first thing to do is to test if the Ethertype is TRILL.

(1) If the Ethertype is not TRILL, you have a native frame and I believe
the processing described in the -04 draft, while it could be more
detailed, is correct, starting with discarding the frame unless you are
acting as the Designated Rbridge (DRB).

(2) If the Ethertype is TRILL, your DRB status doesn't matter. If the
frame is well formed, the outer MAC destination address will either be
All Rbridges or a unicast address. If its unicast and not addressed to
you, you discard the frame. At this point, you can check the inner MAC
destination address.

(2A) If the inner MAC destination address is not All Rbridges, you have
a TRILL data frame.

(2B) If the inner MAC destination address is All Rbridges, you have a
TRILL IS-IS frame. If the inner VLAN tag is absent, it is a core
instance frame. If the inner VLAN tag is present, it is a per VLAN
instance frame.

So, it now appears to me that a Header flag bit to distinguish TRILL
data from TRILL IS-IS is not necessary.

Thanks,
Donald

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Friday, June 29, 2007 3:10 PM
To: Silvano Gai; Eastlake III Donald-LDE008
Cc: rbridge at postel.org
Subject: RE: [rbridge] a clarification about the core IS-IS instance

Silvano/Donald/Radia,

I would prefer to see a different multicast address
used for the TRILL IS-IS instances.  Was there any
consensus on this at the time it was discussed.  I
do remember seeing the discussion, but I can't remember
how it concluded.

Anoop 

> -----Original Message-----
> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> Sent: Thursday, June 28, 2007 1:54 PM
> To: Eastlake III Donald-LDE008; Anoop Ghanwani
> Cc: rbridge at postel.org
> Subject: RE: [rbridge] a clarification about the core IS-IS instance
> 
> Donald,
> 
> Radia confirmed that all the ISIS messages are sent to multicast
> addresses and therefore we discussed the possibility to use separate
> multicast addresses instead of the V bit
> 
> -- Silvano
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
> On
> > Behalf Of Eastlake III Donald-LDE008
> > Sent: Thursday, June 28, 2007 8:46 AM
> > To: Anoop Ghanwani
> > Cc: rbridge at postel.org
> > Subject: Re: [rbridge] a clarification about the core IS-IS instance
> > 
> > If it were not for the V bit, how would you distinguish an IS-IS
> routing
> > packet conveying layer 3 routing information being sent 
> inside a TRILL
> > data frame from a layer 2 TRILL per VLAN IS-IS packet being sent
> inside
> > a TRILL IS-IS frame?
> > 
> > Donald
> > 
> > -----Original Message-----
> > From: Anoop Ghanwani [mailto:anoop at brocade.com]
> > Sent: Thursday, June 28, 2007 10:34 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 again.
> > 
> > What's the function of the V-bit in all
> > of this?  What does an RBridge gain by looking
> > at this, that it cannot get by looking at
> > fields that it already has to?
> > 
> > Anoop
> > 
> > > -----Original Message-----
> > > From: Eastlake III Donald-LDE008
> > > [mailto:Donald.Eastlake at motorola.com]
> > > Sent: Thursday, June 28, 2007 7:30 AM
> > > To: Anoop Ghanwani
> > > Cc: rbridge at postel.org
> > > Subject: RE: [rbridge] a clarification about the core 
> IS-IS instance
> > >
> > > 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
> > > >
> > >
> > 
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> 