[trill] AD review of draft-ietf-trill-cmt-06

Alia Atlas <akatlas@gmail.com> Fri, 31 July 2015 15:22 UTC

Return-Path: <akatlas@gmail.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 2DECA1ACD4D; Fri, 31 Jul 2015 08:22:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.999
X-Spam-Status: No, score=-101.999 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, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id QW1yQypAk6EH; Fri, 31 Jul 2015 08:22:18 -0700 (PDT)
Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (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 8E6B01AD0C7; Fri, 31 Jul 2015 08:22:14 -0700 (PDT)
Received: by obbop1 with SMTP id op1so56302252obb.2; Fri, 31 Jul 2015 08:22:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3HWbaZNGJXBwJoCaj/hrWOKujbVOU7emqh1adPv7ZLk=; b=rq197hdkhQcrWlaNIFp1G7s9zEzPXTvsMKsNwgPGpV08ntIVHmG/nQ6hhllVr6Jjfy AIhDcPprcoxlRg5Bx2Xxmg9eXtqW7D65v4oeL2wX7gVzbhtYeKTUCtWUUlWe54sBcHBo 68KnGmGI3CYZPvIsyItcYDxIaoP1G3jTOyAOpFyc6Fa0kNuc07w24ZOyPJprtYYQdX7+ /Ss9ST+JbmZQG/bgdXjQ1Mp3BMkCuMDSwdgyHVJYLJkbMex1jjqnObzaCnnNIBfGjNy5 xuFIVHNPAogSCrljn1RVMNf8XwjBRnU+6weVaPYrJoT/mywanVd9rLxMwr0sxfdGMCp6 vVAA==
MIME-Version: 1.0
X-Received: by with SMTP id i4mr3705518obh.57.1438356134066; Fri, 31 Jul 2015 08:22:14 -0700 (PDT)
Received: by with HTTP; Fri, 31 Jul 2015 08:22:14 -0700 (PDT)
Date: Fri, 31 Jul 2015 11:22:14 -0400
Message-ID: <CAG4d1rce6spmBWq3ONVRStQnsJptwCABePjzyrLi3g5siFgKWA@mail.gmail.com>
From: Alia Atlas <akatlas@gmail.com>
To: trill@ietf.org, draft-ietf-trill-cmt@ietf.org
Content-Type: multipart/alternative; boundary=001a11c2993a6e8265051c2d622d
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/XhRLUGsfV-S3_BRkXTHg1nIUz-4>
Subject: [trill] AD review of draft-ietf-trill-cmt-06
X-BeenThere: trill@ietf.org
X-Mailman-Version: 2.1.15
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, 31 Jul 2015 15:22:20 -0000

First, I'd like to thank Tissa, Janardhanan, and Jon, the authors of this
draft, for their hard work and clear writing that makes this very easy to
read and understand.

As is customary, I have done my AD review of draft-ietf-trill-cmt-06 before
requesting IETF Last Call.  I do have a few comments that I hope can be
addressed rapidly.

I would really like to get IETF Last Call started on this draft (and the
other two associated trill drafts that make sense to progress at the same
time), but I do feel like some clarification or discussion is really needed.

Today is the last day I can request IETF Last Call and still have the draft
be on the August 20 telechat.  Otherwise, it will have to wait another two
weeks.  I realize that these drafts have been waiting for a long time (and
apologize for my part in the delay), but I'd like to get them moving
rapidly now.

Major Issues:

1) In Sec 5.3, it says "If an RBridge RB1 advertises an Affinity sub-TLV
with an AFFINITY RECORD that's ask for nickname RBn to be its child in
any tree and RB1 is not adjacent to a real or virtual RBridge RBn,
that AFFINITY RECORD is in conflict with the campus topology and MUST
be ignored."  How does an RBridge determine the connectivity of a
virtual RBridge RBn?  I can see that a Designated RBridge announces
the pseudo-nickname for the vDRB to the other RBridges in the LAALPs
(as described in draft-ietf-trill-pseudonode-nickname) but I don't see
any specific way that the connectivity of a virtual RBridge is
described and known by the other RBridges.  What am I missing?

Minor Issues:

2) In Sec 5.1, it talks about the tree number.  Is how the tree number
derived described elsewhere?  Is this something that each RBridge can
do independently?  Could you add a reference?

3) In Sec 5.1, could you clarify which RBridges are doing the
Distribution Tree provisioning?  I'm sure it's my lack of deep
familiarity, but until I got to Sec 5.2, it wasn't at all clear to me.

4) In Sec 5.6, it says "Timer T_j SHOULD be at least < T_i/2" Do you mean
that timer T_j should be no more than T_i/2 or that timer T_j should be no
less than T_i/2.  The "<" makes this unclear to me because the "at least"
contradicts it; is it T_j < T_i/2 or T_i/2 < T_j.

Thanks again,