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

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 27 Jun 2007 18:41:42 -0700

>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

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Thu, 28 Jun 2007 00:08:34 -0400

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

Anoop

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 28 Jun 2007 07:00:10 -0700

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

> 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
> 
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani
> 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
>

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Thu, 28 Jun 2007 10:29:30 -0400

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,
Anoop

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Thu, 28 Jun 2007 07:33:42 -0700

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 

> Sent: Thursday, June 28, 2007 7:30 AM
> To: Anoop Ghanwani
> 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
> 
> 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 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
> > 
> > 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
> > 
>

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 28 Jun 2007 07:46:25 -0700

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

> Sent: Thursday, June 28, 2007 7:00 AM
> Subject: Re: [rbridge] a clarification about the core IS-IS instance
> 
> Hi Donald,
> 
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Thu, 28 Jun 2007 11:45:53 -0400

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.

Anoop

---

From: sgai at nuovasystems.com (Silvano Gai)
Date: Thu, 28 Jun 2007 13:53:49 -0700

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

> Behalf Of Eastlake III Donald-LDE008
> Sent: Thursday, June 28, 2007 8:46 AM
> To: Anoop Ghanwani
impression

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 29 Jun 2007 01:02:47 -0700

Donald,

Yes, I kind of got that after sending this note.
I guess it would be needed if someone intended
to use the per VLAN IS-IS instances.

Anoop

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Fri, 29 Jun 2007 12:10:21 -0700

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 

> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
> Sent: Thursday, June 28, 2007 1:54 PM
> To: Eastlake III Donald-LDE008; Anoop Ghanwani

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Fri, 29 Jun 2007 15:55:43 -0400

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,

Anoop

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 29 Jun 2007 22:26:44 -0700

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:
>>> From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org]
>>>       
>> On
>>     
>>> 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
>>>
>>>> Subject: RE: [rbridge] a clarification about the core 
>>>>         
>> IS-IS instance
>>     
>>>> Hi Anoop,
>>>>
>>>> Subject: RE: [rbridge] a clarification about the core 
>>>>         
>> IS-IS instance
>>     
>>>> Hi Donald,
>>>>
>>>>> 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
>>>>         
>>>>> 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
>>     
>>>>> DRB, will drop all frames whose Ethertype does not 
>>>>>           
>> indicate trill?
>>     
>>>>> Anoop
>>>>>
>>>>>

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Fri, 29 Jun 2007 22:49:44 -0700

I think your analysis is correct.

Radia