Re: [trill] [RTG-DIR] RD Review of draft-ietf-trill-address-flush-00

[Donald Eastlake <[e-mail]>]

Hi Henning,

Sorry for the delay but the draft has been revised to be more in line
with your recommendations. See
https://tools.ietf.org/html/draft-ietf-trill-address-flush-01

In particular, the extended version uses a TLV encoding. Can you take
a look when convenient?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]


On Wed, Sep 7, 2016 at 2:19 AM, Henning Rogge
<[e-mail]> wrote:
> On 03.09.2016 22:15, Donald Eastlake wrote:
>>>
>>> - the difference between the "VLAN Block Case" (2.1) and "Extensible
>>> Case" (2.2) feels artificial. Why not add a "VLAN block TLV", which
>>> contains the list of VLAN start/end fields?
>>
>>
>> As I recall this was in order to make the VLAN Block case closer to,
>> for convenience, an existing implemented address flush RBridge channel
>> message (using one of the "Private Use" RBridge Channel message
>> protocol numbers) that only applies to VLAN blocks.
>
>
> Okay, I didn't check for similarity with older messages.
>
>  > I'll see what people think about merging the cases.
>
> One more question, is case 2.2 optional to implement or is it mandatory?
>
>>> - maybe the Nicknames could also be moved into a TLV, allowing to
>>> process the whole message with a single TLV based parser.
>>
>>
>> I can see making a common TLV format for all the non-nickname lists
>> but I'm not sure there is much advantage to doing so for nicknames.
>
>
> Unified parser codepath... maybe even with checking the TLVs against some
> kind of "schema" before processing them.
>
> Henning Rogge
> --
> Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
> Kommunikation, Informationsverarbeitung und Ergonomie FKIE
> Kommunikationssysteme (KOM)
> Zanderstrasse 5, 53177 Bonn, Germany
> Telefon [phone]
> mailto:[e-mail] http://www.fkie.fraunhofer.de