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

"Susan Hares" <shares@ndzh.com> Fri, 02 September 2016 09:32 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7289512D7EB; Fri, 2 Sep 2016 02:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.945
X-Spam-Level:
X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AasydIxp-hj3; Fri, 2 Sep 2016 02:32:26 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFEDC12D7E4; Fri, 2 Sep 2016 02:32:25 -0700 (PDT)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.191.218;
From: "Susan Hares" <shares@ndzh.com>
To: "'Henning Rogge'" <hrogge@gmail.com>, "'Jon Hudson'" <jon.hudson@gmail.com>, <haoweiguo@huawei.com>, "'Donald Eastlake'" <d3e3e3@gmail.com>, <liyizhou@huawei.com>
References: <CAGnRvuqH9f5XvnafvjNXYK9923ausr1r9xcOX+hXbOTiD4XJiw@mail.gmail.com>
In-Reply-To: <CAGnRvuqH9f5XvnafvjNXYK9923ausr1r9xcOX+hXbOTiD4XJiw@mail.gmail.com>
Date: Fri, 2 Sep 2016 05:31:19 -0400
Message-ID: <0b9901d204fc$c30aa490$491fedb0$@ndzh.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQKvIcvkkOn453bl+mp2pk/forV9RJ6rtaBQ
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/b7dru7npbQvIMeTjJ8kQE7E6MyI>
Cc: rtg-dir@ietf.org, trill@ietf.org
Subject: Re: [trill] [RTG-DIR] RD Review of draft-ietf-trill-address-flush-00
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Developing a hybrid router/bridge." <trill.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trill>, <mailto:trill-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trill/>
List-Post: <mailto:trill@ietf.org>
List-Help: <mailto:trill-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trill>, <mailto:trill-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 02 Sep 2016 09:32:29 -0000

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:rtg-dir-bounces@ietf.org] On Behalf Of Henning Rogge
Sent: Thursday, September 1, 2016 9:53 AM
To: Susan Hares; Jon Hudson; haoweiguo@huawei.com; Donald Eastlake; liyizhou@huawei.com
Cc: rtg-dir@ietf.org; trill@ietf.org
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.



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:henning.rogge@fkie.fraunhofer.de http://www.fkie.fraunhofer.de