Re: [trill] Genart LC (and likely telechat) review : draft-ietf-trill-tree-selection-04
Robert Sparks <rjsparks@nostrum.com> Fri, 01 July 2016 14:50 UTC
Return-Path: <rjsparks@nostrum.com>
X-Original-To: trill@ietfa.amsl.com
Delivered-To: trill@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED4C12D663; Fri, 1 Jul 2016 07:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.326
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elxViAgFt_13; Fri, 1 Jul 2016 07:50:09 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 516E712D60B; Fri, 1 Jul 2016 07:50:09 -0700 (PDT)
Received: from unnumerable.local ([173.57.161.14]) (authenticated bits=0) by nostrum.com (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 rjsparks@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host [173.57.161.14] claimed to be unnumerable.local
To: Donald Eastlake <d3e3e3@gmail.com>
References: <3e13ce97-7b88-1e07-f423-eb0423db8b5f@nostrum.com> <CAF4+nEFnZy16ioccGNjuT2_fdwdqvWnchiPJxcHpVzZyFvHLCA@mail.gmail.com> <CAF4+nEHopG4jmp103j8d3LWo=pzZFBCu6r+8yvg=z9uYMCmskA@mail.gmail.com>
From: Robert Sparks <rjsparks@nostrum.com>
Message-ID: <27d6597e-efd1-7242-28ca-3f4df1016499@nostrum.com>
Date: Fri, 01 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: <CAF4+nEHopG4jmp103j8d3LWo=pzZFBCu6r+8yvg=z9uYMCmskA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/SyKWEg4XnPKL8tkmz2sEgSbw5G4>
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-trill-tree-selection.all@ietf.org, "ietf@ietf.org" <ietf@ietf.org>, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] Genart LC (and likely telechat) review : draft-ietf-trill-tree-selection-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: Fri, 01 Jul 2016 14:50:11 -0000
Thanks Donald, That version does address my comments. RjS 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 > d3e3e3@gmail.com > > > On Wed, Jun 29, 2016 at 4:09 PM, Donald Eastlake <d3e3e3@gmail.com> wrote: >> Hi Robert, >> >> Thanks for your thorough comments. See below. >> >> On Tue, Jun 28, 2016 at 3:33 PM, Robert Sparks <rjsparks@nostrum.com> >> 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 >>> >>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>> >>> 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 >> d3e3e3@gmail.com
- Re: [trill] Genart LC (and likely telechat) revie… Jari Arkko
- Re: [trill] Genart LC (and likely telechat) revie… Robert Sparks
- Re: [trill] Genart LC (and likely telechat) revie… Donald Eastlake
- Re: [trill] Genart LC (and likely telechat) revie… Donald Eastlake
- [trill] Genart LC (and likely telechat) review : … Robert Sparks