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

From: anoop at brocade.com (Anoop Ghanwani)
Date: Sun, 1 Jul 2007 13:27:14 -0700

Donald,

This does assume that the IS-IS instance used
by TRILL uses an address (all-rbridges) that is
different than that used today by IS-IS.

Why can't we just get a separate address for
this?  That way, an all-rbridges address must
never appear in the inner mac da field.

Anoop

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Friday, June 29, 2007 12:56 PM
> To: rbridge at postel.org
> Subject: Re: [rbridge] a clarification about the core IS-IS instance
> 
> 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
> > 
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Sun, 1 Jul 2007 13:29:35 -0700

Radia,

I would prefer a separate multicast address.
I think Silvano also said he would prefer it that way.
It makes things a lot simple from a parsing/frame 
validation standpoint.

Anoop 

> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
> Sent: Friday, June 29, 2007 10:27 PM
> To: Anoop Ghanwani
> Cc: Silvano Gai; Eastlake III Donald-LDE008; rbridge at postel.org
> At the time I thought there might be some IS-IS messages sent 
> unicast. 
> If that were
> true (which it turns out it isn't), then differentiating 
> based on multicast addresses would not have worked.
> 
> I don't think this is a big deal either way, and I don't 
> think anyone had strong opinions about it.
> 
> Radia
> 
> 
> 
> 
> Anoop Ghanwani wrote:
> > 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
> >
> >   
> >>> 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 
> >>>> 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
> >>>>
> 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
> >>>>
> >>>>         
> >>>>> TRILL IS-IS frames and use a formerly reserved bit in the header
> >>>>>           
> >> to
> >>     
> >>>>> [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani
> >>>>> Subject: [rbridge] a clarification about the core IS-IS instance
> >>>>>
> >>>>> Assuming that the above is true, would it be safe to assume that
> >>>>>           
> >> an
> >>

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Mon, 2 Jul 2007 14:33:29 -0400

Hi Anoop,

See below at @@@

-----Original Message-----
From: Anoop Ghanwani [mailto:anoop at brocade.com] 
Sent: Sunday, July 01, 2007 4:27 PM
To: Eastlake III Donald-LDE008; rbridge at postel.org
Subject: RE: [rbridge] a clarification about the core IS-IS instance

Donald,

@@@ Right. That's what the current and all previous version of the
Rbridge/TRILL protocol have assumed. You certainly wouldn't want to use
the same multicast address as Layer-3 IS-IS because it would increase
the chances for confusion between Layer 3 IS-IS messages and TRILL IS-IS
messages.

@@@ I don't understand what problem you are trying to solve. In the
current protocol draft (-04), the inner MAC DA field is All-Rbridges if
and only if it is a TRILL IS-IS frame. We could get a "separate"
multicast address for this, say "All-TBD". Then the inner MAC DA field
would be "All-TBD" if and only if it is a TRILL IS-IS frame. Why is it
easier to check for one 48 bit value than another 48 bit value?

@@@ I understood your previous statement to have mean that you would
prefer a different multicast address to a TRILL Header bit. That's fine,
assuming we have to make that choice. In fact, if the multicast
addresses were consecutive, as seems likely, you are really just saying
you would prefer a flag bit in the bottom bit of the multicast address
to a flag bit in the TRILL Header. But it turns out we don't need a flag
bit at all, in either place. So I just don't understand what the purpose
of a second multicast address would be.

@@@ I would have thought you would like the decision tree described
below since
	(1) it uses the current TRILL Header fields as specified in the
current draft and you have said you don't want to move any fields
around,
	(2) it has no dependency on a TRILL Header "IS-IS" Flag or V
field value, as you requested,
	(3) it uses only the fields that you listed as reasonable inputs
to forwarding/processing decisions, and
	(4) it clearly works.

@@@ Thanks,
@@@ Donald

Anoop