[trill] Shepherd's review of draft-ietf-trill-centralized-replication-05

Donald Eastlake <d3e3e3@gmail.com> Mon, 20 June 2016 22:15 UTC

Return-Path: <d3e3e3@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 D085F12D83C; Mon, 20 Jun 2016 15:15:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 v0l1b-15L4fP; Mon, 20 Jun 2016 15:15:17 -0700 (PDT)
Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::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 AC0DC12D67D; Mon, 20 Jun 2016 15:15:17 -0700 (PDT)
Received: by mail-ob0-x22e.google.com with SMTP id mu6so1288887obc.3; Mon, 20 Jun 2016 15:15:17 -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; bh=nH/5F8oPstSmcXSgU+l58npTHxH8CO7cZ8Z2cKIAkOk=; b=K65HrTM35qPgaGSVeauEtUkUq1Nq2k81P6ho2FWUpJLXcvljpuQXQNHVCD06D6kIXM RlAX0S49c9qNXjC3AHkIUX/8Hsa1TDudyl3VpnVt5/clWUXIayx/qgXNRZGIp45V0Hb/ WnNam3s96mtC879wTu+o5Y0/iZAZc/1jSapz9FEIyfaVjFlyGIHroDr7e62w0ZlmkWkJ pohpbfyJiqcJehfwov7bAyWgEvLVJTt33O/AuC4+RXLDkl4gKFul/89qVTxajhLte/yR MVF32PZSy5lymmEvHSiPl59grNpSEgxXvhM80XngtdSGMxkS/O4Y0jgAdunIylJWcZA5 1YGA==
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; bh=nH/5F8oPstSmcXSgU+l58npTHxH8CO7cZ8Z2cKIAkOk=; b=jCQduX5k1YIxUOppVl9U440vBOhpEC95Zj6UQVqCwpFQWutSg0tM7CG7A3VlLOGykU bz6h+DpCZircr/yx92LaTj5osWKBEiq7ZBcYJNKASjkd+FnbvhOCb7GNLc5DRLAq1/Ep iQ9u9dY50gvJY7r3ORGFfXnlCNMa26AEdaBSxQ7/H3SwSVA+aUFPwRUQ6Btahpk432+J Y67yJR8xajWN1p+WV8ziBtrnOK6wXd6KMXa2qEBkcCKFft6dNjnf9lkSjL5aqy4zLjpj 8ykFJyWm/JC4v+ZpjUxAbjPH2+3KuRgDAvC1NrA3Yw5JKX7O64kEKc3r9a4R3x3s6LlC 3I9Q==
X-Gm-Message-State: ALyK8tIYIjjHRdnVrFy3HxATBSankUV6rfKz4QN4kKaQLFCQ6t5RdohWJIPX7jHavgiLQopclkIEamllGHkrfw==
X-Received: by with SMTP id o10mr11347876otb.110.1466460917019; Mon, 20 Jun 2016 15:15:17 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Jun 2016 15:15:02 -0700 (PDT)
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Mon, 20 Jun 2016 18:15:02 -0400
Message-ID: <CAF4+nEFpoTGsupLb+OBmRSw7spdMY8p725WER26gT7mnsGdhew@mail.gmail.com>
To: "trill@ietf.org" <trill@ietf.org>
Content-Type: multipart/alternative; boundary=001a113e3a8c093e660535bd0aae
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/c4NAUbDG0ohk8vvzTdftMnRZiIw>
Cc: "trill-chairs@ietf.org" <trill-chairs@ietf.org>
Subject: [trill] Shepherd's review of draft-ietf-trill-centralized-replication-05
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: Mon, 20 Jun 2016 22:15:20 -0000


As the document shepherd I have done a careful review of this document and
have the following comments:

This draft uses "CE" and expands it as "Classic Ethernet"; however, I
believe we have decided to use the expansion "Customer Equipment"
that, for example, is used in RFC 7379.

The draft says that BUM traffic is unicast encapsulated and is sent to
a central node that SHOULD be a tree root. It would be good to say a
few words about why it "SHOULD". Perhaps something like "because
distribution tree roots are normally chosen to be high capacity core
RBridges with many high bandwidth adjacencies".

At the bottom of page 5 there appears to be a small garble where some
text was dropped. Looking back at version -04, it looks like most of
the problem is one line of text being dropped.

In TRILL it is possible for an RBridge to hold multiple nicknames and
be the distribution tree root for multiple trees. The draft should say
something about what to do in that case. Presumably, to avoid
unnecessary re-ordering of BUM traffic each R-nickname should direct
traffic to one distribution tree. Also, a centralized node could hold
multiple nicknames that it advertised as R-nicknames so perhaps the
spreading over centralized nodes in Section 8 should be a spreading
over R-nicknames. This would enable a network manager to direct more
traffic to one centralized node and less to other centralized nodes
which they might want to do if one centralized node was larger and
more capable than others.

In Section 11, it says that the C-nickname is set on each edge
RBridges which could be a bit confusing. It sounds a bit like they are
setting it on their own nickname. Should this say something more like it is
set on the psuedo-nickname for each edge group.

I also have a number of minor editorial suggestions which I am sending to
the authors.

 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA