[rbridge] a clarification about the core IS-IS instance
Radia Perlman
Radia.Perlman at sun.com
Fri Jun 29 22:26:44 PDT 2007
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
>
>
>> -----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
>
More information about the rbridge
mailing list