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

Donald Eastlake <d3e3e3@gmail.com> Fri, 03 June 2016 22:14 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 4AA1812D759; Fri, 3 Jun 2016 15:14:33 -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=unavailable 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 mU7jqqGEBoEH; Fri, 3 Jun 2016 15:14:31 -0700 (PDT)
Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 7FBD412D8A2; Fri, 3 Jun 2016 15:08:09 -0700 (PDT)
Received: by mail-oi0-x22a.google.com with SMTP id j1so147596523oih.3; Fri, 03 Jun 2016 15:08:09 -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=VKymWbD6HEj7gFyiZwp3a7DModdku5pNMaFIqo2KFdI=; b=JjSlJz6+Qec+DTTx20M/bLNUzLfjPlJsw7fZyrik8wnNAsF8Gd/BYvF8QEX6owMxhw iG7XxXrAY1bT7kEtGBih3OYtGxiIcCcTLdRAx9H9pnFtd2vlsbcIIf4YjY91Imc7ne8e 1SsMmiVcBpB2QyvxXEaWXsaasQGAmTM1MukRl/9KnZGCmwdXBDiNU+K+zrgbYJQwuqzu r2yTlZsgR/lLRDhlE75gaE7Tylw6RUt7HkEtupR5yyxEXWaF0J7sHI4NSoPV0Hwjm/8H 1PLgAmyBpBcqvAHcMTMazXeBNDpOViYqJQx1Nms0hzYsm81kBeqEzDlgmWDnpg4SMYIw 8ceg==
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=VKymWbD6HEj7gFyiZwp3a7DModdku5pNMaFIqo2KFdI=; b=YVpO5lmnMDFG+YJmq9F9AyW29cHHGFh5cNi7aRqvUnOly+j2N9G9GQO1Xuf7dMbzvj 9j3myYkx7wHsUI/EuhDlLk2TtXDjYMexcCBmRf1qLTpvkeh33RE70MXPSGWVLexCrTFH zUluNmi7EHu22ovcCmMBD/kHTv0v+JntNJXJ+uHmRrG8Y3hzrR6iGuIrEtDZCHPYh3Xq lXT74iX2c/pLr+KDxy2yIqichKEgNKhKZLSN9Oza07hHpkTAYuAiw42NBRqLJfHqWBHe LXNz5Vfto5np56sAe4NA3+F7VMJrKk3quoLHXSXStPIWSLJQWPe6AqM4uCUWNiQMBUsn Dv5A==
X-Gm-Message-State: ALyK8tJzHjHOPO6o63quFKByWHb4C5kQlQI2rMTo1KStK40cYdrMvVAiNCV3ql4XBhg1IvRVFmTHqdWqmyl5dg==
X-Received: by 10.157.39.79 with SMTP id r73mr3035826ota.110.1464991688801; Fri, 03 Jun 2016 15:08:08 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.38.66 with HTTP; Fri, 3 Jun 2016 15:07:54 -0700 (PDT)
In-Reply-To: <575158A9.8040607@alcatel-lucent.com>
References: <574C1C04.4020300@alcatel-lucent.com> <CAF4+nEHP_reXHo2xPCbUs3A_Hdsb3HSNSZXF4whf3F7Ka-BSCQ@mail.gmail.com> <575158A9.8040607@alcatel-lucent.com>
From: Donald Eastlake <d3e3e3@gmail.com>
Date: Fri, 3 Jun 2016 18:07:54 -0400
Message-ID: <CAF4+nEFz0eQ+hDyO8ZYaF+NGCCTFYKvR69UsAR+QCJzHN5Kk1g@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/LRtQtyF3TXpGlF1dgy_Xy9qBL9k>
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 22:14:33 -0000

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