[rbridge] encoding of TRILL IS-IS frames

[Donald Eastlake]

There seems to have been no further comment on this.

Just to be sure people understand what is being adopted: There is no
change in TRILL data frames. TRILL core IS-IS frames have a different
outer multicast destination address from data, presumably
All-IS-IS-RBridges, and are not TRILL encapsulated. The remaining case
is ESADI IS-IS frames which are, by default, treated almost exactly
like data. The should have an All-RBridges outer DA and be
encapsulated, like data, but have some new special inner destination
MAC address: All-ESADI-RBridges.

Thanks,
Donald

On Sat, Oct 11, 2008 at 7:37 AM, Dinesh G Dutt <ddutt at cisco.com> wrote:
> Donald,
>
> Donald Eastlake wrote:
>>
>> for core TRILL IS-IS frames, I don't see any particular reason why you
>> couldn't just use the existing All-Rbridges multicast address so that
>> RBridges need to listen for only one multicast address to receive
>> TRILL frames.
>>
>
> I do. We want to make it easy for the hardware to distinguish between
> control and data frames so that the control frames can be trapped easily and
> sent to the control processor. All protocols designed so far work that way.
> The control protocol always uses a separate MAC address than data frames.
>>
>> What does "nbr" stand for? If you want to do away with encapsulation
>>>
>>> For ESADI, TRILL encapsulation like with ordinary data packets, but
>>> having as the destination
>>> address in the inner Ethernet header a different multicast address
>>> "all-ESADI-TRILL"
>>>
>>
>> ? Since ESADI frames need encapsulation and work fine in the current
>> protocol document, why change them at all? Like all TRILL IS-IS frames
>> currently, they have an Inner.MacDA of All-IS-IS-Rbridges.
>>
>
> Again because it is additional logic for hardware to distinguish between
> control frames that they care about and control frames that they don't care
> about depending on the TRILL header contents. Using a separate MAC DA makes
> it simple. In some ways, ESADI is a different protocol.
>>
>>
>>>
>>> The advantage of this is that for core TRILL IS-IS, we'd save header
>>> room and probably work for
>>> RBridges to parse IS-IS packets.
>>>
>>
>> Right, you save a little space but
>>       You vastly increase the probability of confusing anything TRILL
>> ignorant, such as network diagnostic equipment. With encapsulation,
>> all TRILL frame specific content is shielded by the TRILL Ethertype.
>> Devices that do not know that Ethertype know that can't parse the
>> following frame content.
>>
>
> Not even remotely true. The All-Rbridges-core-ISIS and
> All-Rbridges-ESADI-ISIS multicast addresses are unique. Today for L3 ISIS,
> there is no addition of an IP header for example to address your issue above
> and no one has asked for it. This is the first instance where we're
> attempting to add a protocol header to IS-IS.
>>
>>       Such a change calls into question the optional optimization of
>> sending TRILL IS-IS frames (other than TRILL Hellos) unicast when
>> there is only one destination RBridge of interest out a port. At the
>> least, it would mean that TRILL would be the only protocol ever able
>> to use this optimization since, without the multicast destination
>> address or TRILL Ethertype, you could no longer tell unicast TRILL
>> IS-IS frames from any other protocol's attempt to use unencapsulated
>> IS-IS frames.
>>
>
> I don't care for this optimization and I doubt if many of those who're
> building switches do. IEEE has set the standard of identifying control
> frames using the MAC DA and that's what we're suggesting. Why are we adding
> stuff that no other protocol so far has done or cared about. This is the
> kind of minor details that make a very nice protocol a pain to implement.
> There is a precedence, let's follow it. I don't want control and data frames
> to have the same MAC DA and I don't want them to do complicated parsing to
> achieve the same result with little or no benefit.
>>
>>       You eliminate the possibility of using any TRILL options on
>> such frames. I can think of options I might want to use.
>>
>
> What options ? Stick them as additional TLVs. By that logic, L3 IS-IS not
> having an IP header is a big limitation. I've not heard anybody making this
> argument.
>>
>>       You eliminate the possibility of using TRILL versions or header
>> reserved bits to affect such frames or their processing.
>>
>
> I disagree. The control protocol has the versions supported. Any future
> version of TRILL MUST be able to understand the basic IS-IS TLVs.
>>
>> In all previous discussions of this sort of things, the working group
>> has clearly leaned in the direction of uniformity of processing, even
>> at the expense of a few more bytes, for reasons like those above and
>> to leave more freedom for possible future use of currently unused
>> fields should an unexpected need arise.
>>
>
> I disagree. This is a major pain for implementation and sets a new
> precedence with zero to insignificant benefits. Let's follow what has been
> accepted so far and has been working well.
>
> Dinesh
>
> --
> We make our world significant by the courage of our questions and by the
> depth of our answers.                               - Carl Sagan
>
>



-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 d3e3e3 at gmail.com