Re: [trill] QA review of draft-ietf-trill-multi-topology-01

Martin Vigoureux <martin.vigoureux@nokia.com> Fri, 03 June 2016 10:15 UTC

Return-Path: <martin.vigoureux@nokia.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 3F17D12D0F8; Fri, 3 Jun 2016 03:15:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.902
X-Spam-Level:
X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] 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 Gxm1bMsOCj7Z; Fri, 3 Jun 2016 03:15:10 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B7EC12B02D; Fri, 3 Jun 2016 03:15:09 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 6C54B3C22B819; Fri, 3 Jun 2016 10:15:05 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u53AF6iX012744 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 3 Jun 2016 10:15:07 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u53AF0jL007544 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jun 2016 12:15:06 +0200
Received: from [135.224.204.130] (135.239.27.41) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 3 Jun 2016 12:15:05 +0200
Message-ID: <575158A9.8040607@alcatel-lucent.com>
Date: Fri, 3 Jun 2016 12:15:05 +0200
From: Martin Vigoureux <martin.vigoureux@nokia.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: Donald Eastlake <d3e3e3@gmail.com>, Martin Vigoureux <martin.vigoureux@nokia.com>
References: <574C1C04.4020300@alcatel-lucent.com> <CAF4+nEHP_reXHo2xPCbUs3A_Hdsb3HSNSZXF4whf3F7Ka-BSCQ@mail.gmail.com>
In-Reply-To: <CAF4+nEHP_reXHo2xPCbUs3A_Hdsb3HSNSZXF4whf3F7Ka-BSCQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [135.239.27.41]
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/k6fRMOyrzJLy9AzlOzHPK8LrF4U>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, Alia Atlas <akatlas@juniper.net>, draft-ietf-trill-multi-topology.all@ietf.org, "trill@ietf.org" <trill@ietf.org>
Subject: Re: [trill] QA review of draft-ietf-trill-multi-topology-01
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, 03 Jun 2016 10:15:12 -0000

Hi Donald,

thank you.
please see in-line for the pending points.

-m

Le 31/05/2016 20:11, Donald Eastlake a écrit :
> Hi Martin,
>
> Thanks for your review. See response below.
>
> On Mon, May 30, 2016 at 6:55 AM, Martin Vigoureux
> <martin.vigoureux@nokia.com> wrote:
>> Hi,
>>
>> I have been selected as the Routing Directorate QA reviewer for this draft.
>>
>> Document: draft-ietf-trill-multi-topology-01
>> Reviewer: Martin Vigoureux
>> Review Date: May 20, 2016
>> Intended Status: Proposed Standard
>>
>> The draft is both quite well written and well structured such that I did not
>> have to go back and forth in the doc.
>> As a result also, I have only very few editorial comments and questions.
>
> Thanks.
>
>> Section 1
>>     If routers in the network do not agree on the topology
>>     classification of packets or links, persistent routing loops can
>>     occur.
>> It is not clear if that could happen in mt-trill or if mt-trill solves that.
>
> Multi-topology TRILL doesn't specify what kind of traffic should be
> classified as being in what topology. Indeed, the traffic classified
> as being in topology T can be arbitrarily different in different parts
> of the TRILL campus if there are disjoint instances of a topology T.
> This classification needs to be decided and configuration by network
> management. This is consistent with how IS-IS multi-topology is used
> in other applications. So, yes, routing loops can be caused by
> misconfiguring IS-IS mutli-topology is TRILL or IP.
Maybe it is worth clarifying that point then.

>
>> Section 1.1 goes beyond defining acronyms but specifies some pieces of
>> technology:
>>     By implication, an "FGL TRILL switch" does not support MT.
>>     An MT TRILL switch MUST support FGL in the sense that it MUST be FGL
>>     safe [RFC7172].
>> Is this the right place to do this? By the way, this requirement is stated
>> further down in the doc.
>
> There is a similar sentence at the end of the entry for "VL". The idea
> is that the capabilities of an "MT TRILL switch" are a superset of the
> capabilities of an "FGL TRILL switch" which are in turn a superset of
> the capabilities of a "VL TRILL switch". This is intended to simplify
> things by having, at least to some extent, a linear sequence of added
> capabilities rather than the cross product of the presence/absence of
> each added capability. Sort of MT > FLG > VL. I don't see anything
> wrong with having these statements here as well as further down in the
> document.
I did not say it was wrong. I find surprising to specify technology 
elements in a section the objective of which is to define acronyms.
But I can live with it.

>
>> Section 2.2
>> s/and received/and receive/
>
> OK.
>
>> Section 2.4
>>     Commonly, the topology of a TRILL Data packet is commonly
>> One superfluous occurrence of "commonly"
>
> OK. I think deleting the initial "Commonly, " would be a good
> solution. So the sentence would start "The topology of a TRILL Data
> packet is commonly ..."
>
>> Section 2.4.1
>> It would be better to write "2/3" as "2 and 3"
>
> OK.
>
>>     A TRILL switch advertising in a Hello on Port P support for topology
>>     T but not advertising in those Hellos that it requires explicit
>>     topology labeling is assumed to have the ability and configuration to
>>     correctly classify TRILL Data packets into topology T by examination
>>     of those TRILL Data packets and/or by using the fact that they are
>>     arriving at port P.
>> Does this mean that Value 1 is default behaviour?
>
> The first paragraph of Section 2.4.1 makes it clear that the default
> value of the two bit field in the Port Capabilities sub-TLV is zero
> and this is also the value assumed if that sub-TLV is not present. I
> can clarify the statement you quote above but it means exactly what it
> says. "not advertising in those Hellos that it requires explicit
> topology labeling" means it is not advertising a value of 2 or 3 in
> the Explicit Topology capability field.
>
> The sentence you quote is already effectively included in the entry
> text for Explicit Topology capability field value 1. Probably the
> sentence you quote should be deleted and the applicable portion of
> should also merged into the text for Explicit Topology capability
> field value 0. That seems like the best way to reduce confusion.
yes, I think this is where the misunderstanding came from.

>
>> Section 3.4.1
>> s/are determine/are determined/
>
> OK.
>
>> Section 7
>> s/some links was more/some links were more/
>
> OK.
>
> Thanks,
> Donald
> ===============================
>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>   155 Beaver Street, Milford, MA 01757 USA
>   d3e3e3@gmail.com
>
>