[trill] AD review of draft-ietf-trill-rbridge-multilevel-04

Alia Atlas <akatlas@gmail.com> Wed, 21 December 2016 00:06 UTC

Return-Path: <akatlas@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 4B5CF129579; Tue, 20 Dec 2016 16:06:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 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, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 elG5ERSQeo7B; Tue, 20 Dec 2016 16:06:45 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 DA00E129513; Tue, 20 Dec 2016 16:06:41 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id g23so134506260wme.1; Tue, 20 Dec 2016 16:06:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=xvRGMzBiCT2TTHEtDCuuXk9M4tSQR/psGSsig0x7ESo=; b=XHH0OyqmWHxXI9RDZ5qmAYwLA2+F3LVlugQJnOFN7AouF/Dd63k2NFnMBS/4vHyMPm NtgQG/uqD3Zu3Ja0OqQwU+IaVO3MNAGPeDPE2RWR3qDKCROEzw0WWP+ShaGNQsrFY+Rg GDEHJ/eeqwvj6u0XdKXdKr/lDl9dy4dGlaiBRqQfTHB9TBxq7H+ysX/BP/+aZ90/oBw4 5YEZBdeR7IvMmL7iIVu5kOhIvmv+2ositO9Lk0o03WhRs2g7KtOpX/o7GH8nruHSa01J 0QQMGeKJoZ1G4nudC0sI52Ec5CuZ+sEvujAaRRZuGKtZaH5FkKrEtF6J3+PuE6IKdNYa wmyA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=xvRGMzBiCT2TTHEtDCuuXk9M4tSQR/psGSsig0x7ESo=; b=PN/WuR2/mR5D2G1dB9GBygNFH0OHbJTCRSfNRMNfbCPLwAQvuf/2zdZUgPo2BrDF7x Jg0RW5pTulgNTF5z5J7UGLv3LQKhM5vn21evHig5R9pPg9kNbDo2rBGSOL1dznjYNrW+ VJNS9GAep3VTgPmVpqD96TfKFYnoVc4RjLURkLTA+3TSiwVyDqQgDQlK1xd06rlFymgM owNhjYGcrY6ebhjAlFuqL8qALMgdR0q2pP4yeM1JO0kes8dxNam4Iexayft9NmQ4u6Oo 78Wg0RL4KhTzOjFy/yJOqLIWXVdGmoi5tWdQlXkUVrWSqYCrJhjBocSfFoVKJBUH3tNK pGbg==
X-Gm-Message-State: AIkVDXIx7FFzCXK7PUZlJIc3npfJCp2IQT5TUfR7w0uxUgG9yPtFPhmevu4X19PocvjXxl4L5HviRM7836QbDQ==
X-Received: by with SMTP id g191mr3973429wme.33.1482278800188; Tue, 20 Dec 2016 16:06:40 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 20 Dec 2016 16:06:39 -0800 (PST)
From: Alia Atlas <akatlas@gmail.com>
Date: Tue, 20 Dec 2016 19:06:39 -0500
Message-ID: <CAG4d1re5PF81bB3ZewtwkFhT6J06quOGedNBx72K-ky9zoqfKQ@mail.gmail.com>
To: trill@ietf.org, draft-ietf-trill-rbridge-multilevel@ietf.org
Content-Type: multipart/alternative; boundary=001a114b41cc57ec5105441fedd5
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/9nH72x2uZMBguHvRThMJ7iK_dTM>
Subject: [trill] AD review of draft-ietf-trill-rbridge-multilevel-04
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: Wed, 21 Dec 2016 00:06:47 -0000

As is customary, I have done my AD review
of draft-ietf-trill-rbridge-multilevel-04.  First, I would
like to thank the authors - Radia, Donald, Mingui, Anoop, and Hongjun - for
their work on this document.

>From my review, I do have a few high level concerns.  In particular, this
document has the job of guiding future WG work and setting out some
high-level decisions for the architecture of multi-level TRILL.
Unfortunately, there are several areas where the draft isn't willing to
commit to specific guidance or pick one alternative.   If there had been
vigorous discussion and debate on this, I might have more confidence that
there are strong reasons that truly justify the multiplication of
complexity represented in this document.   I don't see any of that on the

I will require an updated draft and discussion before progressing this


a) Sec  Unless I'm missing something - this is proposing changing
the format of the basic TRILL header to accommodate multi-level IS-IS,
which would impact all hardware implementations of TRILL deployed
everywhere.   The idea of allowing both options just makes for yet more
complexity, options, and challenges in interoperability & troubleshooting!
  Please don't invent complexity.  I don't see any discussion on the
mailing list around this point and the document doesn't emphasize that this
is an extremely bad option - done to trade-off  complexity & storage at the
border switches.   This is definitely an area where operators and vendors
need to weigh in and silence can not imply consensus.

b) Sec 7:  I would strongly prefer to see a clear trade-off described in
terms of hardware impact as well as how flag-days for software could be
avoided.   I'm not seeing any considerations given to upgrading.  I also am
not excited that the WG isn't willing to pick one approach to go forward
with.  Multiple approaches mean at least twice the pain for implementing,
testing, troubleshooting, learning the technology, and so on.

c) I expect some section of management/operational considerations for how
different choices impact the ability to transition from a single area to a
multi-area solution.


1) Sec 1.1 item 5: Is the concern about the 16-bit nickname limit for trill
switches based on the likelihood of collision from picking nicknames?   I
have a hard time picturing a network with over 65,500 trill switches and
distribution trees that doesn't run into many other issues.   Please clarify
the details of this concern in the document.

2) Sec 6:  The simple option of having topology constraints to avoid having
multiple trill switches in different areas connected to the same link
doesn't seem to have been considered.  Please add and clarify why a
topology constraint is or isn't acceptable operationally.  As you well
know, simplification and ease of interoperability are critical criteria for
evaluating the options.