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

Donald Eastlake <d3e3e3@gmail.com> Sat, 03 September 2016 20:16 UTC

Return-Path: <d3e3e3@gmail.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 F35BF12B05E; Sat, 3 Sep 2016 13:16:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.15
X-Spam-Level:
X-Spam-Status: No, score=0.15 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 cG7lQ9YkzgG2; Sat, 3 Sep 2016 13:15:59 -0700 (PDT)
Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 58E4112B015; Sat, 3 Sep 2016 13:15:59 -0700 (PDT)
Received: by mail-ua0-x22e.google.com with SMTP id q42so146473352uaq.1; Sat, 03 Sep 2016 13:15:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=BRKVXB2DDaneDqns7WpzFWwFYMEaRUC1JUIuix8ktbk=; b=gWT0tOloVBYYrpZFTR7rkymVWVZIYoIF9SDDVaNHUWdE3EPD6059FjieFSyHwZo0vC QuhqneXdfMcoRs007Qm3y1J1sx70zpZfas9UatIs02gBxVxBoeVGCpx0JNv/ZTzg0OGB KCb5HDfVfbACzMbkoIErrJX4N/sEhtvcJsU21uG8ryg4M6PHqdHAf0HIGwOeR8GFRN4Z OCAVR491qP3DWKRqZI9SNxUnOBVydhyweM/Tjm8ZXOIUfGHmGmRX2gExENpqxnnsCGba 6YtGNpdBmiEe0sNgTYskoByHe9mJx/2MQslPCp35X/Zi2lbuj2ohxP7QEmzwp0sEHV6T ySrQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=BRKVXB2DDaneDqns7WpzFWwFYMEaRUC1JUIuix8ktbk=; b=l6/rlkzlmKdPcGRY3M8Y5UOkWZERirlZp123wI7HM6EjC7VM0wuNMqk7ZhpkFKf/JJ 5icEc5J42pcgSSuDgAPmVkdgMlrFKKSu8xZAFu65bKsI8ou31RRmEw9BFm9BSOBZpNPf aHSUHdIvckXHX/80bzfowCdOiHEDSqdSI3PxLBZzqpFY936l2fjTtyQprStkpMgK53mJ SzhVRVbdJ4OIgBGH96QIX7s5c5G0aqwSfCv5bp8wwDmNh2xHcic5TIda2iY+Za4xPRhA rc9a9Hp26AUwacmrgGOIyY8yGuQzNeVr9dvWCzfe4gd+OwlJOInOhjb7Ki51eKsyTm9J kkqg==
X-Gm-Message-State: AE9vXwNV5D38X6jrUvoItaLIidVcG1mUVUkZ8eVl55Z7ClDmCZQZqidjzEbjY7iGv6Tnnev7tlP3bValHEszmg==
X-Received: by 10.159.39.6 with SMTP id a6mr17824540uaa.33.1472933758317; Sat, 03 Sep 2016 13:15:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.97.67 with HTTP; Sat, 3 Sep 2016 13:15:42 -0700 (PDT)
In-Reply-To: <CAGnRvuqH9f5XvnafvjNXYK9923ausr1r9xcOX+hXbOTiD4XJiw@mail.gmail.com>
References: <CAGnRvuqH9f5XvnafvjNXYK9923ausr1r9xcOX+hXbOTiD4XJiw@mail.gmail.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sat, 3 Sep 2016 16:15:42 -0400
Message-ID: <CAF4+nEGkwgU07e=6+GMAGeLNTsjsnnFBQMY2yoHTy2gcArSv2Q@mail.gmail.com>
To: Henning Rogge <hrogge@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/5G_JIxbuhIDNCwKY283QpiKCOKg>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, Susan Hares <shares@ndzh.com>, "trill@ietf.org" <trill@ietf.org>, Hao Weiguo <haoweiguo@huawei.com>, Li Yizhou <liyizhou@huawei.com>, Jon Hudson <jon.hudson@gmail.com>
Subject: Re: [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: Sat, 03 Sep 2016 20:16:01 -0000

Hi,

On Thu, Sep 1, 2016 at 9:53 AM, Henning Rogge <hrogge@gmail.com> wrote:
>
> 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 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.

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

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

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

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

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

OK.

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

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com

> 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