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

Donald Eastlake <d3e3e3@gmail.com> Sat, 04 June 2016 16:05 UTC

Return-Path: <d3e3e3@gmail.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 0BE8C12D13B; Sat, 4 Jun 2016 09:05:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level:
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 qHc_L7oE0NWj; Sat, 4 Jun 2016 09:05:12 -0700 (PDT)
Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 C396512D152; Sat, 4 Jun 2016 09:05:12 -0700 (PDT)
Received: by mail-oi0-x235.google.com with SMTP id w184so169681568oiw.2; Sat, 04 Jun 2016 09:05:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TLv6ldNWe42t1D0kHNYl8LcuAeHCdDxopGGS3gKkHwE=; b=kcrFHG0Oy8CK/TPqJEdUdAPQ5Ge/TmUID07D5zKfBBTQcD8I4JoRezFSzQdRo3cw+0 86fyAYPq+n4AlYJ5YMWLi7BRmXFrjypmXyzLNvcPAdAwT8Fp6VW1AoE+q9XdINf74xRU ozS08Vs51UoJ+qLwz/5FntJ9sUTxH97MrEzSBvG9jFboOwxsWYPXHyoF+C14HKvu9G+H oAEMSHFsP8TxCZ0Cic432om6rowlU5iLhdNfp26NHvz5uHbzNjThkmZOxBFXaiSWck9q 3p17vlr1wvaJ0+16PhgeuSS0+ghJrUqCO1ngTSgMNWyouoNf8uf+tl+DrxtbG3rRH2k1 jhFg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=TLv6ldNWe42t1D0kHNYl8LcuAeHCdDxopGGS3gKkHwE=; b=XWy75uJg5VTKLQWc7/vNjMvQC6v0X4PZFpB+BfVREhjN3YytnRiJbKGjTvEWjbEgbT WW1sNyCMzs9FfwnAAITiZCNWDrtrw5a8y7ucjYAazJFIpsgEHDi4fKOt2k2sdtzIGesh uf1RQ1eESrTP4o2LJ4JCChtfannxKm/3zuBgKNQS0zHFG35373TOkC6yoUn/yeAz8BzV MoTzXH6qmadlbIT92Y9Oylt91JUqpMs2/v1Iqw5G98DZPvYPmXSzQMswic6+S+9Jxbns /XNW28GpaNyafnduS7V+ujVCDMLVg7TQSbNP4dlVkWVMC74DwcvmkG3nxB7nNp9QD3PI wNow==
X-Gm-Message-State: ALyK8tK2Ey2iiTctjezBWlwB9DxYrfh/hQYfAUZvaqVgBANuryenzP3O4pIGDocDmfLSOeEkd+KvYOnkZcrORg==
X-Received: by 10.202.177.134 with SMTP id a128mr4102602oif.37.1465056311956; Sat, 04 Jun 2016 09:05:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.38.66 with HTTP; Sat, 4 Jun 2016 09:04:57 -0700 (PDT)
In-Reply-To: <CAF4+nEFz0eQ+hDyO8ZYaF+NGCCTFYKvR69UsAR+QCJzHN5Kk1g@mail.gmail.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>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Sat, 4 Jun 2016 12:04:57 -0400
Message-ID: <CAF4+nEHeZZWqeZejvnjnSfg16bCe0j0T_+Q0HDsXiN1mDz2P=g@mail.gmail.com>
To: Martin Vigoureux <martin.vigoureux@nokia.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/trill/d4UQbg9aJr2Hud8-0Aqq8H_ZPbE>
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: Sat, 04 Jun 2016 16:05:16 -0000

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