Re: [6tisch] MSF Shepherd review

Tengfei Chang <tengfei.chang@gmail.com> Wed, 27 November 2019 20:44 UTC

Return-Path: <tengfei.chang@gmail.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C23E120988; Wed, 27 Nov 2019 12:44:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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 cP9hlPSz92Ap; Wed, 27 Nov 2019 12:44:30 -0800 (PST)
Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) (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 A362712007C; Wed, 27 Nov 2019 12:44:27 -0800 (PST)
Received: by mail-pf1-x42e.google.com with SMTP id h14so1538407pfe.10; Wed, 27 Nov 2019 12:44:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+RKAlmfWaJrKyoCwSdadnJOCzUlFfjTv8wO0fhyoUyA=; b=kBGsyNue9AuDxnYKntpN9MYFGG7vLxPtljn4WlcQYpnsw4aBz2CKF9DZC3shhhrzy0 Y/qAYJoxeczLeIWPlHxtGXfluwz6Sn/sSyWuwfZoQ4T/4l/2E3Z0Iuue/dLo25rL8R3/ lvHAIxvHH+gg8IRmOwFXdj7UW9XsJmQqIAR1JvqjSoe3QYOycdsTuLEVXTdDgjMDgCe2 Xo0PKBBrVZlyluyUJ3pEm9q6hWP8M5WHDKdolc7/MQxxjImEB7rhc2k4yk/tLGJ6NZOe /8+70u916qRzZ8DmheQuQcJ2PCP/O3M0t+x/iRBvNeUDzBZcKqkE22sY15XUMwYek2gG WbJg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+RKAlmfWaJrKyoCwSdadnJOCzUlFfjTv8wO0fhyoUyA=; b=Bu1oOJfnEmvNoPywPA4I+w4TKmJD3hNEdArdpOYKZYq8/m3oRrHYAu3YPJ61l0Lx9+ HRde6dmJqD57m1KPyjt0CcEkMr8IvmjYNr00G3DVWRzqJG4ZUKSVF8jAKW+5TIbEIjrk RrHkqpIDFEDc6olS9WIixTF3DWPd3JJbLoCOrk91zceBNuBfbWwOxs6ZaK9KfeoZTpKW kgkv/eDMdrcYu9b+4mVGq0fikCFENx5eddxRT3x1+x489JJIBf63tSl+GRstFJdhbsnn xdOnJrGx0i4a0swg5bqoV6d4+MVFx7TsBP+knYo0o1usv3/dMY1c0uECdAGBUxuIe38p O6+A==
X-Gm-Message-State: APjAAAWCX0rW5tJsQl6uMYZRsjnWrNx/Ue08ZwL52NleR4N7FTnzDmwK xPYEYyY7gG1n1cVrX4o++411EuugO5Eewl11j3o=
X-Google-Smtp-Source: APXvYqxYqqgvNQnzFpxW52uQcG+uiAW6sGV8shGHMGpPKFju/Nvau7ju2ea314lAo+1oFSJqN3WJ0RbyMHkirOH1zWA=
X-Received: by 2002:aa7:96e2:: with SMTP id i2mr48756116pfq.256.1574887466968; Wed, 27 Nov 2019 12:44:26 -0800 (PST)
MIME-Version: 1.0
References: <MN2PR11MB3565642A73EC6629FA68137DD84A0@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB3565642A73EC6629FA68137DD84A0@MN2PR11MB3565.namprd11.prod.outlook.com>
From: Tengfei Chang <tengfei.chang@gmail.com>
Date: Wed, 27 Nov 2019 21:44:13 +0100
Message-ID: <CAAdgstRhP2aOfekS5swmXPbD1rwnR-bAAm9ToBQnwmv77KCSEw@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: "draft-ietf-6tisch-msf@ietf.org" <draft-ietf-6tisch-msf@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000007ab9105985a107f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/g9jlIP4fVnF5nlSj0RBM10-ckSE>
Subject: Re: [6tisch] MSF Shepherd review
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Nov 2019 20:44:34 -0000

Thanks a lot for the reviewing, I responded inline:

On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert) <
pthubert@cisco.com> wrote:

> Dear all
>
>
>
> Please find some comments below:
>
>
>
>
>
>
>
>
>
> Please migrate to XML2RFC v3. This will save time in the future.
>

TC: got it! Will used in version 9.

>
>
>
>
>
>
>    However, an implementor MAY implement MSF without implementing
>
>    Minimal 6TiSCH Configuration.
>
>
>
>
>
> This is not helpful without explanations. What is the tradeoff? How does
> the  network operates in that case?
>

TC: Yes, the sentence is misleading. What we try to say is MSF can work
with other specifications protocols, rather then minimal 6TiSCH
configuration, as long as the protocols gives a way to communicate the EB
and DIO among the network.


>
>
>
>
>
>
>
>
> For example, a Trickle Timer defined in
>
> [RFC6550 <https://tools.ietf.org/html/rfc6550>] MAY be applied on DIOs. However, this behavior is
>
> implementation-specific which is out of the scope of MSF.
>
>
>
>
>
> This is not for this spec to define. RPL already mandates trickle.
> Suggestion:
>
>
>
> For example, the Trickle operation defined in [RFC6206]
>
> is applied on DIO Messages [RFC6550 <https://tools.ietf.org/html/rfc6550>]. This behavior is
>
> out of the scope of MSF.
>
>
>
> TC: agreed!

>
>
>
>
>
>
>
>
> MSF RECOMMENDS the use of 3 slotframes.
>
>
>
> Discussion on slotframes and cells comes without an introduction to TSCH.
>
> I’d suggest you add a few words on RFC 7554 appendix A and 6TiSCH
> architecture section 4.3.5. to introduce those concepts.
>
> They should probably be normative references.
>

TC: I added the following text at beginning of section 2:
            In a TSCH network, time is sliced up into time slots.
            The time slots are grouped as one of more slotframes which
repeat over time.
            The TSCH schedule instructs a node what to do at each time
slots, such as transmit, receive or sleep <xref target="RFC7554"/>.
            In case of a slot to transmit or receive, a channel is assigned
to the time slot.
            The tuple (slot, channel) is indicated as a cell of TSCH
schedule.
            MSF is one of the policies defining how to manage the TSCH
schedule.

>
>
>
>
>
>
>
>
> Section 4 has numerous SHOULD. Trouble is, when SHOULD is used, the author
> SHOULD explain the alternate, what if the SHOULD is not followed.
>
> Sometimes it’s quite obvious, like when using random in 4.2. But SHOULD
> use minimal is less obvious. Please consider adding text after the SHOULDs.
>

TC: agreed!  I have resolved this SHOULD issues in a new version. either
the unnecessaries are removed or alternative explanation is added

>
>
>
>
>
>
>    field it contains, the presence and contents of the IE defined in
>
>    [I-D.richardson-6tisch-join-enhanced-beacon <https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#ref-I-D.richardson-6tisch-join-enhanced-beacon>], or the key used to
>
>    authenticate it.
>
>
>
> The reference is now draft-ietf.. I agree that it should be normative; no
> worries the draft is already submitted for publication.
>
> More important: Please move the reference to
> 6tisch-dtsecurity-zerotouch-join to informational. This is a DOWNREF today
> and your draft may be stuck in MISSREF in the future.
>

TC: I have updated  *richardson-6tisch-join-enhanced-beacon* to
* ietf-6tisch-enrollment-enhanced-beacon.*
I didn't get it how "*move the reference to
6tisch-dtsecurity-zerotouch-join to informational*" is done in the draft?


>
>
>
>
>
>    After selected a preferred parent, the joined node MUST generate a 6P
>
>
>
> Grammar: “After selecting” or “once it has selected” sound better.
>
>
>
TC: the latter sounds better! Thanks!

>
>
>
>
> Section Section 8 <https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#section-8>
>
>
>
> The <xref …> already generates the word “section”. If you write it too, it
> becomes duplicated as above.
>

TC: agreed!

>
>
>
>
>
>
> For a node, this translates into
>
>    monitoring the current usage of the cells it has to its preferred
>
>    parent:
>
>
>
> This is disturbing. MSF should not be used only with preferred parents.
> The whole game of doing a DODAG is to have and possibly use multiple
> parents.
>
> A node can for instance send a NSM DAO with multiple transit options to
> the root. Also, it could be good to clarify that the child manages both
> directions.
>
> Proposal:
>
>
>
> For a node, this translates into
>
>    monitoring the current usage of the cells it has to the parents it uses
>
>    at this point of time for sending and receiving traffic:
>
>
>
> Later there a numerous references to “preferred parent” => I’d suggest you
> use just “selected parent” or “active parent” or  something in that vein.
>
TC: I think "preferred parent" is same with "selected parent".  it
indicates one preferred parent out of multiple. Isn't it right?

>
>

>
>
>
> Cell installed at initial
>
>
>
> Not sure this is correct. Maybe “at init time”
>

TC: Applied!

>
>
>
>
>
>
>
>
> It is recommended to set MAX_NUMCELLS value at
>
>    least 4 times than the maximum link traffic load of the network in
>
>    packets per slotframe.
>
>
>
>
>
> This does not parse. Can you please rephrase?
>

TC: it's rephrased as "*It is recommended to set MAX_NUMCELLS value at
least 4x of the maximum link traffic load of the network with unit of
packets per slotframe*."

>
>
>
>
>
>
>
>
> Section 8 does not try to avoid collisions with autocells. But it’s easy
> to compute the slot offset of autocells for self and parent and avoids
> those. Why not do that?
>

TC: agreed! Will apply in the next version.

>
>
>
>
>
>
> Section 16 will require more attention, either now or during secdir
> review, probably both. You should start now. Think, say, what if an
> attacker claims many cells to all its neighbors? Can it attack someone’s
> autocells to block him?
>

TC: That's a good question! It may have a chance to do so. We need discuss
internally on this section.
Thanks for belling ahead!

>
>
>
>
>
>
> Voila!
>
>
>
> Pascal as shepherd.
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>


-- 
——————————————————————————————————————

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tchang.org/
——————————————————————————————————————