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

From: Henning Rogge <[email-masked]>
Date: Thu, 1 Sep 2016 15:53:08 +0200

Hi,

Jonathan Hardwick asked me to review the initial revision of the TRILL
Address Flush draft.

I can easily see the use case for this functionality with TRILL aware
RBridges that have additional knowledge about leaving (or even
"roaming" end-devices). The speedup for removing the MAC addresses
could be essential for performance in some scenarios.

I have a couple of comments and questions to chapter 2:

- is it a normal use case to have "n" nicknames and "m" VLAN blocks
and want to remove all combinations of all of them or do you expect on
of the list to have size 1 normally?

- I would suggest moving the description of each "TLV" for the Address
Flush Message into a sub-chapter. This allows to break the "wall of
text" for each TLV and makes adding a small ascii-art for each TLV
possible, making the TLVs much easier to read and to reference (see
below).

- 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?

- maybe the Nicknames could also be moved into a TLV, allowing to
process the whole message with a single TLV based parser.

- I would suggest adding a new IANA registry to the draft to contain
the TLV types. This will make it easier to add types in later IETF
documents.

Example for new (sub)chapter for TLVs:

Chapter x.y: Address Flush Message TLVs

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type          | Length        | TLV Data...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type:     1 octet type field
Length:   length of the TLV data in octets without Type and Length field.
TLV Data: TLV specific data

Chapter x.y.1: Nickname TLV

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (TBD)    | Length        | Nickname 1                    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nickname 2                    | Nickname K-nicks              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Nickname TLV contains a list of Nicknames the Address Flush
Message refers to.

The length of the Nickname TLV is always an even number of octets.

Chapter x.y.2: VLAN block TLV

...

Henning Rogge

Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für
Kommunikation, Informationsverarbeitung und Ergonomie FKIE
Kommunikationssysteme (KOM)
Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 2 Sep 2016 05:31:19 -0400

Henning:

Thank you for the review of this draft.  The authors (Weiquo, Donald and Yizhou) will be in touch with you shortly.  Donald has been on travel for 2 weeks - so his response may be early next week. 

Sue 

-----Original Message-----
From: rtg-dir [mailto:[email-masked]] On Behalf Of Henning Rogge
Sent: Thursday, September 1, 2016 9:53 AM
To: Susan Hares; Jon Hudson; [email-masked]; Donald Eastlake; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [RTG-DIR] RD Review of draft-ietf-trill-address-flush-00

Hi,

Jonathan Hardwick asked me to review the initial revision of the TRILL Address Flush draft.

I can easily see the use case for this functionality with TRILL aware RBridges that have additional knowledge about leaving (or even "roaming" end-devices). The speedup for removing the MAC addresses could be essential for performance in some scenarios.

- is it a normal use case to have "n" nicknames and "m" VLAN blocks and want to remove all combinations of all of them or do you expect on of the list to have size 1 normally?

- I would suggest moving the description of each "TLV" for the Address Flush Message into a sub-chapter. This allows to break the "wall of text" for each TLV and makes adding a small ascii-art for each TLV possible, making the TLVs much easier to read and to reference (see below).

- 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?

- maybe the Nicknames could also be moved into a TLV, allowing to process the whole message with a single TLV based parser.

- I would suggest adding a new IANA registry to the draft to contain the TLV types. This will make it easier to add types in later IETF documents.

Type:     1 octet type field

The Nickname TLV contains a list of Nicknames the Address Flush Message refers to.

...

Henning Rogge

Diplom-Informatiker Henning Rogge , Fraunhofer-Institut für Kommunikation, Informationsverarbeitung und Ergonomie FKIE Kommunikationssysteme (KOM) Fraunhofer Straße 20, 53343 Wachtberg, Germany
Telefon +49 228 9435-961,   Fax +49 228 9435 685
mailto:[email-masked] http://www.fkie.fraunhofer.de

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 3 Sep 2016 16:15:42 -0400

Hi,

> of the list to have size 1 normally?

I think the most common case will be where some topology change or
reconfiguration at the edge of a TRILL campus moves a set of VLANs
from one edge RBridge serving the end stations in those VLANs to a
different RBridge. Whether the set of VLANs would be one or a few or
many blocks just depends on how contiguous the VLAN IDs are. Since
this case typically involves one RBridge, one nickname will be common;
however, an RBridge can hold multiple nicknames and a RBridge might
use multiple nicknames as ingress nickname if it is supporting
active-active end station connection as specified RFC 7781 so 2 or
more nicknames is entirely plausible.

> possible, making the TLVs much easier to read and to reference (see

I assume you are refering to the Types in Section 2.2. That seems like
a reasonable suggestion.

> 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. I'll see what
people think about merging the cases.

> 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.

> the TLV types. This will make it easier to add types in later IETF

OK.

> Chapter x.y: Address Flush Message TLVs

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Henning Rogge <[email-masked]>
Date: Wed, 7 Sep 2016 08:19:13 +0200

On 03.09.2016 22:15, Donald Eastlake wrote:
> 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?

> 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-masked] http://www.fkie.fraunhofer.de