[trill] RD Review of draft-ietf-trill-address-flush-00

Henning Rogge <hrogge@gmail.com> Thu, 01 September 2016 14:06 UTC

Return-Path: <hrogge@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BF82312DA26; Thu, 1 Sep 2016 07:06:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ssrmT03es2Lp; Thu, 1 Sep 2016 07:06:15 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 F2D9012DAD8; Thu, 1 Sep 2016 06:53:39 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id 93so42150721qtg.2; Thu, 01 Sep 2016 06:53:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=sIUa6mLLznHv23oZubKe00JUyd4Wb9Lu0K4+6TtyPr0=; b=HUlgMTYVG7ScEYoZ/CnL9mSYODfbnb8clRSjp36gQIFjIzZkpFH4BNbjZmoAlnhLyn 6xIZniRWqwEAeJ8CT3HtbA3Au5HgU7X2f+Xva8wSPoXkJSckWbagBrYZpJa/fMTkJx4e 9aro8frnSK2nHjt4guc8leywPkrkZET9Q9N8GL4FsBWLvPPRE7vR3N8cpdSg5bKYiBn+ e3QyzNXSPXy70WDiiQIg4kCWWI5UAsSUn9kYjBlm9Vl7kM3HcZkcNETSHmZg2ix/ltCr QwlM30BuR0OOYn8iVqoX96Ow37wFC7/8HdoeyNv8t+2zx37w6nxo62hattito1V4AzX+ LjMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=sIUa6mLLznHv23oZubKe00JUyd4Wb9Lu0K4+6TtyPr0=; b=Gt6QKxY09YjIBoWRYeqR4DfEscgYs9RXc/dAQX6QiT6lfbU2NGhSpknVmqQ8DIyh4Y 899OwAtLbDd3plg0p2TNdN7EQtGus+a0p7n9IRHOft85oVoozfOnp5bp4La/0Tr0HeIu w/KoP6sefE4rSQLEzxpp+9wFWdmRSSUE0PCUlsDeCtP4PzGYOu7UlI7Lxit/8AT1nJXF DNv7LVLzVKsxytt6Tp3Z+QTaOQbOFPxuTUiYwj3eZbEBF0EBVQrzlAeeTmYJg40y/iZh uTmJhxMGf+x1eOL6mmVLEeRvyS64PkE3AmdN5PEkwloTVIcLPXkTn+cuLzJbqo4PAtjD Z1CA==
X-Gm-Message-State: AE9vXwMBD6kTogBudQX1+YMSTS3WKHddckvv5ulsRNaNACGcS9HvXFtk6n3HgYt0Utb/VKhh37U0NEpprMZzJw==
X-Received: by with SMTP id j6mr17755615qtd.113.1472738019086; Thu, 01 Sep 2016 06:53:39 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 1 Sep 2016 06:53:08 -0700 (PDT)
From: Henning Rogge <hrogge@gmail.com>
Date: Thu, 1 Sep 2016 15:53:08 +0200
Message-ID: <CAGnRvuqH9f5XvnafvjNXYK9923ausr1r9xcOX+hXbOTiD4XJiw@mail.gmail.com>
To: Susan Hares <shares@ndzh.com>, Jon Hudson <jon.hudson@gmail.com>, haoweiguo@huawei.com, Donald Eastlake <d3e3e3@gmail.com>, liyizhou@huawei.com
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/EnG96ybmgHOINqBhmwPbfC1Y0gY>
Cc: rtg-dir@ietf.org, trill@ietf.org
Subject: [trill] 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: Thu, 01 Sep 2016 14:06:20 -0000


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

- 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

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