Yatch,
About :
*Why does the node have to issue a 6P CLEAR to a neighbor which is
determined to be unreachable...? It just wastes time and energy of the
initiator since this transaction will fail as the draft mentioned. I think
it'd be fine to remove all the dedicated cells to the unreachable neighbor
without 6P CLEAR. By the way, the term "cells" should be used instead of
"links".*
I would recommend to use a MAY in this case. That is, a node MUST remove
cells, and MAY send a CLEAR.
Thomas
On Wed, Feb 14, 2018 at 5:28 AM, Xavi Vilajosana Guillen <
xvilajos...@uoc.edu> wrote:
> Dear Yatch,
>
> thanks for your comments! see inline my answers.
>
> 2018-02-13 18:13 GMT+01:00 Yasuyuki Tanaka <yasuyuki.tan...@inria.fr>:
>
>> Hi all,
>>
>> I'd like to share my comments on draft-chang-6tisch-msf-00:
>>
>>https://tools.ietf.org/html/draft-chang-6tisch-msf-00
>>
>> The first one is about 6P CLEAR after detecting unreachability to a
>> neighbor.
>>
>> > 3.8. Step 7 - Neighbor Polling
>> >
>> > (snip)
>> >
>> >When a neighbor is declared unreachable, the node MUST issue a 6P
>> >CLEAR to that neighbor (which can fail at the link-layer), and MUST
>> >remove all dedicated links with that neighbor from its own schedule.
>>
>>
>> Why does the node have to issue a 6P CLEAR to a neighbor which is
>> determined to be unreachable...? It just wastes time and energy of the
>> initiator since this transaction will fail as the draft mentioned. I think
>> it'd be fine to remove all the dedicated cells to the unreachable neighbor
>> without 6P CLEAR. By the way, the term "cells" should be used instead of
>> "links".
>>
>>
> XV> I agree. A node can directly reset its schedule. We will change that
> sentence.
>
>
>> Other comments are trivial.
>>
>> > 1. Introduction
>> >
>> > (snip)
>> >
>> >MSF is designed to operate in a wide range of application domains.
>> >It is optimized for applications with regular upstream traffic (from
>> >the nodes to the Internet).
>>
>> "The internet" sounds too specific. "From the nodes toward the root"
>> would be better?
>>
>
> XV>> Agree.
>
>>
>> > 2. Interface to the Minimal 6TiSCH Configuration
>> >
>> > (snip)
>> >
>> >MSF uses the minimal cell to exchange the following packets:
>> >
>> > ...
>> >
>> >4. The first 6P packet a node issues to a neighbor it doesn't have
>> >dedicated cells to, as defined by
>> >[I-D.ietf-6tisch-6top-protocol]. These are unicast frames.
>>
>> The minimal cell is used for not only the first 6P packet but also
>> subsequent packets associated with a 6P transaction initiated by the first
>> packet. In this sense, I'd like to propose to replace it with:
>>
>>6P packets to schedule the first dedicated cell with a neighbor. There
>> are unicast frames.
>>
>
> XV>> Agree.
>
>>
>> > 7. Rules for CellList
>> >
>> >
>> >MSF uses 2-step 6P Transactions exclusively. 6P Transactions are
>> >only initiated by a node towards it preferred parent. As a result,
>> >the cells to put in the CellList of a 6P ADD command, and in the
>> >candidate CellList of a RELOCATE command, are chosen by the node. In
>> >both cases, the same rules apply:
>> >
>> > the CellList SHOULD contain 5 or more cells.
>> > Each cell in the CellList MUST have a different slotOffset value.
>> > For each cell in the CellList, the node MUST NOT have any
>> > scheduled cell on the same slotOffset.
>> > The slotOffset value of any cell in the CellList MUST NOT be the
>> > same as the slotOffset of the minimal cell (slotOffset=0).
>> > The slotOffset of a cell in the CellList SHOULD be randomly and
>> > uniformly chosen among all the slotOffset values that satisfy the
>> > restriction above.
>> > The channelOffset of a cell in the CellList SHOULD be randomly and
>> > uniformly in [0..numFrequencies] where numFrequencies represents
>> > the number of frequencies a node can communicate on.
>>
>>
>> Is this a format error...?
>>
>
> XV>> No, I think this is a bullet list with "invisible" bullets :) . We
> add the bullets.
>
>>
>> > 8. 6P Tim
