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 +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] On Wed, Sep 7, 2016 at 2:19 AM, Henning Rogge <[email protected]> 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 +49 228 50212-469 > mailto:[email protected] http://www.fkie.fraunhofer.de _______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
