[RTG-DIR] RtgDir review: draft-ietf-trill-cmt-06

Stig Venaas <stig@venaas.com> Tue, 11 August 2015 23:16 UTC

Return-Path: <stig@venaas.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1EB4E1B2AAA for <rtg-dir@ietfa.amsl.com>; Tue, 11 Aug 2015 16:16:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id avVmScMjS23J for <rtg-dir@ietfa.amsl.com>; Tue, 11 Aug 2015 16:16:29 -0700 (PDT)
Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com []) (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 83A801B2A8E for <rtg-dir@ietf.org>; Tue, 11 Aug 2015 16:16:29 -0700 (PDT)
Received: by pawu10 with SMTP id u10so425596paw.1 for <rtg-dir@ietf.org>; Tue, 11 Aug 2015 16:16:29 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=vUgsOtsZ4SEVbJg5ZRivH1mgYOSleBHyXnD+jwkbo1g=; b=ahkFP2W1lc8f2QiCu+qppMcK+Pp6eGQlzTUyf7mpwazr6TpKAgbasST8fJQjfstl2F ebD9irN553B1wKGjS3y3SV+oup4lzZhz+4+o9DcifBZQU15L87Ju/6UpG2+7NY2kTbxo fiu+ir6Tfmzyjt84AIM4kIHEJ15/3/l9YcrQnK2E6trnYWZZ7K2uhulx2E5srVRexCjQ UpAhAa2ZKDSCJK7gfan0PD2miACYlsx/3xctRlO132aFCQzztRiGK4PuKV+QzDD38uH4 tOGJ2DyGTJvfJH2ZlIj3kRmEErRaljQMtRH3UMvC5vfus95hxvf/X3QrIw5GHN88zTrN O7sQ==
X-Gm-Message-State: ALoCoQk1hxx6COPyGDoZmUPTaAFTnK7hUQkH2gbUiCe60dUAbcRR7ddBWrKKPgKfaGA+VIeIj3aa
X-Received: by with SMTP id vv6mr60085351pab.150.1439334989006; Tue, 11 Aug 2015 16:16:29 -0700 (PDT)
Received: from ?IPv6:2001:420:c0c8:1004::5b8? ([2001:420:c0c8:1004::5b8]) by smtp.googlemail.com with ESMTPSA id e2sm3981815pdk.61.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Aug 2015 16:16:27 -0700 (PDT)
Message-ID: <55CA8242.9060202@venaas.com>
Date: Tue, 11 Aug 2015 16:16:18 -0700
From: Stig Venaas <stig@venaas.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: rtg-ads@tools.ietf.org, "rtg-dir@ietf.org" <rtg-dir@ietf.org>, draft-ietf-trill-cmt@tools.ietf.org, jon.hudson@gmail.com, Jonathan Hardwick <Jonathan.Hardwick@metaswitch.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtg-dir/sdJci3nJ47BjpK4cm9LVWX36WZM>
Subject: [RTG-DIR] RtgDir review: draft-ietf-trill-cmt-06
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Aug 2015 23:16:31 -0000


I have been selected as the Routing Directorate reviewer for this
draft. The Routing Directorate seeks to review all routing or routing
related drafts as they pass through IETF last call and IESG review, and
sometimes on special request. The purpose of the review is to provide
assistance to the Routing ADs. For more information about the Routing
Directorate, please see

Although these comments are primarily for the use of the Routing ADs,
it would be helpful if you could consider them along with any other
IETF Last Call comments that you receive, and strive to resolve them
through discussion or by updating the draft.

Document: draft-ietf-trill-cmt-06
Reviewer: Stig Venaas
Review Date: August 11, 2015
IETF LC End Date:
Intended Status: Standards Track

I have a couple of potentially major concerns and a few minor ones
that I think should be resolved.


The document is generally pretty good, but the sentences are a bit hard
to read at times, and there may be a couple of technical issues.

Major Issues:

1. The document talks about virtual RBridges. I cannot find any
definition of what this means. Also the abstract talks about how
virtual RBridges pose serious challenges for RPF checking, but it
isn't explained later in the document. My knowledge of TRILL is
somewhat limited.

2. The recovery algorithm discussed in 5.6 is just a guideline. What
happens if different implementations choose different algorithms? They
may not interoperate. Cannot this cause problems? Shouldn't it be more
than just a guideline?

Minor Issues:

1. I believe the abstract should not contain references.

2. In 1.1 it says:
    Specific methods in this document for making
    use of the Affinity sub-TLV are applicable where a virtual RBridge
    is used to represent multiple RBridges are connected to an edge CE
    through an LAALP such as multi-chassis link aggregation or some
    similar arrangement where the RBridges cannot see each other's

I have trouble parsing this. What are you trying to say?

3. Also in 1.1 it says:
    This document DOES NOT provide other required operational elements

I don't think DOES NOT should be capitalized. Not in 2119.

4. In 4.1
    sub-TLV which are resolved as specified in Section 5.3.   In the
    absence of such an Affinity sub-TLV, or if there are any RBridges in
    the campus that are do not support Affinity sub-TLV, distribution

I think delete "are".

5. Also in 4.1
    trees are calculated as specified in the section 4.5.1 of [RFC6325]
    as updated by [RFC7180]. Section 4.3. below specifies how to

I guess delete the period.

    identify RBridges that support Affinity sub-TLV capability.

6.  In 4.2 we have

    Each edge RBridge RB1 to RBk advertises in its LSP virtual RBridge
    nickname RBv using the Nickname sub-TLV (6), [RFC7176], along with
    their regular nickname or nicknames.

Wording/punctuation makes this hard to parse.

7. Also in 4.2
    It will be possible for any RBridge to determine that RBv is a
    virtual RBridge because each RBridge (RB1 to RBk) this appears to be
    advertising that it is holding RBv is also advertising an Affinity
    sub-TLV asking that RBv be its child in one or more trees.

Add some punctuation here?

8. In 5.4.1 fall back options, there are multiple lower case "should"
that perhaps should be SHOULD?