Re: [Gen-art] Genart LC (and likely telechat) review : draft-ietf-trill-tree-selection-04

Robert Sparks <> Fri, 01 July 2016 14:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8ED4C12D663; Fri, 1 Jul 2016 07:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id elxViAgFt_13; Fri, 1 Jul 2016 07:50:09 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 516E712D60B; Fri, 1 Jul 2016 07:50:09 -0700 (PDT)
Received: from unnumerable.local ([]) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id u61Eo4BY008685 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Fri, 1 Jul 2016 09:50:05 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be unnumerable.local
To: Donald Eastlake <>
References: <> <> <>
From: Robert Sparks <>
Message-ID: <>
Date: Fri, 1 Jul 2016 09:50:04 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc: General Area Review Team <>,, "" <>, "" <>
Subject: Re: [Gen-art] Genart LC (and likely telechat) review : draft-ietf-trill-tree-selection-04
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Jul 2016 14:50:11 -0000

Thanks Donald,

That version does address my comments.


On 7/1/16 9:43 AM, Donald Eastlake wrote:
> Hi Robert,
> A version -05 has been uploaded with the intent that it resolve your comments.
> Thanks,
> Donald
> ===============================
>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>   155 Beaver Street, Milford, MA 01757 USA
> On Wed, Jun 29, 2016 at 4:09 PM, Donald Eastlake <> wrote:
>> Hi Robert,
>> Thanks for your thorough comments. See below.
>> On Tue, Jun 28, 2016 at 3:33 PM, Robert Sparks <>
>> wrote:
>>> I am the assigned Gen-ART reviewer for this draft. The General Area
>>> Review Team (Gen-ART) reviews all IETF documents being processed
>>> by the IESG for the IETF Chair.  Please treat these comments just
>>> like any other last call comments.
>>> For more information, please see the FAQ at
>>> <>.
>>> Document: draft-ietf-trill-tree-selection-04
>>> Reviewer: Robert Sparks
>>> Review Date: 28 Jun 2016
>>> IETF LC End Date: 1 Jul 2016
>>> IESG Telechat date: 7 Jul 2016
>>> Summary: Ready (with nits) for publication as Proposed Standard
>>> This document is easy to read, even for someone not deeply steeped
>>> in trill.
>>> I have a few questions and suggestions to consider
>>> 1) The essence of the idea this document provides support for is that an
>>> operator will create and install a configuration that meets the one tree per
>>> identifiable thing (such as VLAN) constraint.
>> Well, it helps as long as multi-destination traffic identified by VLAN
>> or whatever is carried by fewer than all trees. It need not be one.
>>> The protocol proposed here
>>> does not try to enforce that the operator supplies a configuration meeting
>>> that constraint. Should the things that generate messages with the TLVs
>>> defined in this document be restricted from sending messages that would map
>>> the same VLAN to two trees? I understand things will still work
>>> (suboptimally, as pointed out in the backwards-compatibility section), but
>>> it seems this configuration error should be mitigated. Section 3.3 also
>>> pulls the punch a little with it's discussion at the end of the second
>>> paragraph. If you're going to leave it up to the unspecified way the
>>> operator installs this configuration, you might at least point out that this
>>> is something to look for and complain about. If you think the optimal
>>> configuration isn't a likely thing to reach, then consider a pass through
>>> the document that sets that expectation consistently.
>> While restricting, for example, VLAN-x to one tree is optimal from the
>> point of view of using up the least amount of fast path FIB
>> (Forwarding Information Base) resources in some hardware
>> implementations, it is not optimal from the point of view of load
>> spreading. To get optimal load spreading, you would want to spread
>> different multi-destination flows onto different distribution trees.
>>> 2) There are a couple of places where you use 2119 where you appear to be
>>> restating requirements from other documents. That's dangerous, from a
>>> document set maintenance point of view. Please consider changing these to
>>> simple prose, leaving the 2119 requirements to the protocol you're defining
>>> in this document. Please look at the SHOULD in the Background Description,
>>> and the SHOULD NOT in the first paragraph of the Overview. (2119 in sections
>>> like backgrounds and overviews is usually a sign that somethings in the
>>> wrong place.)
>> The SHOULD in the Background Description is indeed just echoing the
>> same provision from [RFC6325] and can be changed to not use a 2119 keyword.
>> The SHOULD NOT in the first paragraph of the Overview (Section 3.1) is
>> entirely due to theis draft and not inhereted from any other document.
>>> 3) In the 3rd paragraph of 3.3, why is the requirement SHOULD strength? What
>>> else would the RBridge do, and when would it be reasonable for it to do that
>>> something else?
>> The "SHOULD" requirement is to use a tree that the choosing RBridge
>> has advertised it will use; however, it is not actually required to
>> advertise which tree(s) it will use. Furthermore, even if it has, that
>> tree(s) might just have become unavailable due to one or more
>> failures.  We can probably add some words to clarify that.
>>> Nits/editorial comments:
>>> * You use a lot of domain-specific acronyms in section 1 before saying what
>>> they mean in section 2.
>> Looks to me like the terminology section could be moved up.
>>> * The first sentence in the 8th paragraph of 1.2 is very
>>> complex. (It's the one that starts "In cases where blocks
>>> of"). Please consider simplifying it.
>> I think it can be re-worded.
>>> * Section 2: (I'm no fun) Do you want this alternate expansion of
>>> FGL to stand?
>> Nope... Looks like a global replace run amok or something, that should
>> be fixed :-)
>>> * Figure 2: the left table has a VLAN of 4095, which is inconsistent
>>> with the prose.
>> Shold be fixed. 4095 (0xFFF) is not a valid VLAN ID.
>>> * In section 3.4 you use 2119 RECOMMENDED (which is equivalent to
>>> SHOULD) when describing how the operator configures things. This
>>> isn't a constraint on the protocol defined in this document. Please
>>> consider rewriting the sentence without the 2119 keyword.
>> Humm. I think those are good operational recommendations. We can try
>> changing "RECOMMEND" to "suggest" and see if we get push back to
>> change it back :-)
>>> * Micronits: there's spurious space at the beginning of the 3rd line
>>> on page 6. There's an occurrence of BRridge that probably should
>>> have been RBridge in section 3.4, and "assigne" appears in the IANA
>>> Considerations.
>> OK.
>> Thanks,
>> Donald
>> ===============================
>>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>   155 Beaver Street, Milford, MA 01757 USA