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

Martin Vigoureux <martin.vigoureux@nokia.com> Sun, 05 June 2016 14:30 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 0EC9712D0FF; Sun, 5 Jun 2016 07:30:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level:
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[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 dxH8PIlThaKj; Sun, 5 Jun 2016 07:30:35 -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 4AE3D128E18; Sun, 5 Jun 2016 07:21:17 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id EC29238BEEF33; Sun, 5 Jun 2016 14:21:12 +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 u55ELEMq013460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 5 Jun 2016 14:21:15 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u55ELELY004667 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 5 Jun 2016 16:21:14 +0200
Received: from [135.224.206.141] (135.239.27.39) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sun, 5 Jun 2016 16:21:14 +0200
Message-ID: <57543558.7060403@alcatel-lucent.com>
Date: Sun, 5 Jun 2016 16:21:12 +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> <575158A9.8040607@alcatel-lucent.com> <CAF4+nEFz0eQ+hDyO8ZYaF+NGCCTFYKvR69UsAR+QCJzHN5Kk1g@mail.gmail.com> <CAF4+nEHeZZWqeZejvnjnSfg16bCe0j0T_+Q0HDsXiN1mDz2P=g@mail.gmail.com>
In-Reply-To: <CAF4+nEHeZZWqeZejvnjnSfg16bCe0j0T_+Q0HDsXiN1mDz2P=g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Originating-IP: [135.239.27.39]
Archived-At: <https://mailarchive.ietf.org/arch/msg/trill/uggdHjs7BCiS1oMyuauX1-OSWeg>
Cc: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, 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: Sun, 05 Jun 2016 14:30:44 -0000

Thank you Donald

Le 04/06/2016 18:04, Donald Eastlake a écrit :
> Hi Martin,
>
> draft-ietf-trill-multi-topology-02, just posted, incorprates the
> resolutions of your comments and has a few other editorial
> improvements.
>
> Thanks,
> Donald
> ===============================
>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>   155 Beaver Street, Milford, MA 01757 USA
>   d3e3e3@gmail.com
>
>
> On Fri, Jun 3, 2016 at 6:07 PM, Donald Eastlake <d3e3e3@gmail.com> wrote:
>> Hi Martin,
>>
>> On Fri, Jun 3, 2016 at 6:15 AM, Martin Vigoureux
>> <martin.vigoureux@nokia.com> wrote:
>>> 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.
>>
>> OK.
>>
>>>>> 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.
>>
>> OK.
>>
>>>>> 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.
>>
>> OK, I delete that sentence and move the relevant part of it to the
>> entry to field value 0.
>>
>> Thanks,
>> Donald
>> ===============================
>>   Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
>>   155 Beaver Street, Milford, MA 01757 USA
>>   d3e3e3@gmail.com
>>
>>>>> 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
>