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".

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?

> 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.

> 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...?

> 8.  6P Timeout Value
> 
> 
>    The 6P Timeout is not a constant value.  It is calculated a (C/
>    PDR)*6PTIMEOUT_SEC_FACTOR, where:


I think it'd be better for a variable name to start with a non-numeric 
character even in a document.

That's it!

Best,
Yatch
_______________________________________________
6tisch mailing list
6tisch@ietf.org
https://www.ietf.org/mailman/listinfo/6tisch

Reply via email to