[6tisch] Comments on draft-ietf-6tisch-msf-00

[Yasuyuki Tanaka <[e-mail]>]

Hi authors,

Congratulations on this great work!

  https://tools.ietf.org/html/draft-ietf-6tisch-msf-00

I'm sharing my comments on the draft; major comments are followed by minor
comments.

* discussion: when to schedule autonomous TX cells to neighbors

According to Section 4, a join proxy (JP) needs to schedule an autonomous TX
cell to a node (pledge) who wants to join the network. Thanks to this, a join
process can be done with the autonomous cells of the JP and pledge. These
autonomous cells make the network formation faster.

However, from the view point of security, it'd be better to avoid installing any
state for an unauthenticated/unauthorized node. In this particular case, the
join proxy shouldn't schedule the autonomous cell to the pledge.

We would need some discussion in "Security Considerations" section if we allow
JPs to install autonomous TX cells to their pledges.

* question: why do we need a separate slotframe for MSF?

MSF avoids using slot offset 0 for its autonomous cells and its dedicated cells
anyway. The length of Slotframe 1 for MSF is the same as Slotframe 0

draft> (Section 3)
draft> As detailed in Section 2.2 of [I-D.ietf-6tisch-6top-protocol], MSF MUST
draft> schedule cells from Slotframe 1, while Slotframe 0 is used for traffic
draft> defined in the Minimal 6TiSCH Configuration.
draft> (...)
draft> The first time offset is skipped to avoid colliding with the minimal cell
draft> in Slotframe 0.

draft> 8.  Rules for CellList
draft> 
draft> (snip)
draft>    o  The slotOffset value of any cell in the CellList MUST NOT be the
draft>       same as the slotOffset of the minimal cell (slotOffset=0).

* question: parameters for SAX

What values are used for L and R in SAX? It'd be nice to have an example or a
test vector in the draft in order to validate a SAX implementation used for
MSF. This is critical for interoperability.

* minor comment 1

draft> (Section 1)
draft> The end state of the join process is that the node is synchronized to the
draft> network, has mutually authenticated to the network, has identified a
draft> preferred routing parent, has scheduled one default unicast cell to/from
draft> each of its neighbors.

The latter part of this sentence seems not to be accurate.

After the join process, the node (pledge) has the following cells:

- the minimal cell defined by RFC 8180
- one autonomous RX cell
- autonomous TX cells to its JP

This doesn't fit "one default unicast cell to/from each of its neighbors."

* minor comment 2

draft> (Section 2)
draft> A node implementing MSF MUST implement the Minimal 6TiSCH Configuration
draft> [RFC8180], which defines the "minimal cell", a single shared cell
draft> providing minimal connectivity between the nodes in the network.

'MUST' here sounds too strong... Some may want to use MSF with a base schedule
other than one defined RFC 8180 with full understands on implications by not
following RFC 8180. Then, I'd propose 'SHOULD'.

By the way, I'm not sure whether we can specify 'MUST implement' to a BCP
document or not.

* minor comment 3

draft> (Section 2)
draft> 2.  DODAG Information Objects (DIOs), defined by [RFC6550].  These are
draft> broadcast frames.

A DIO can be sent in a unicast frame.

rfc6550> 8.3.  DIO Transmission
rfc6550> (...)
rfc6550> When a node receives a unicast DIS message with a Solicited Information
rfc6550> option and matches the predicates of that Solicited Information option,
rfc6550> it MUST unicast a DIO to the sender in response.

So, that sentence could be...

       2.  DODAG Information Objects (DIOs), defined by [RFC6550].  Broadcasted
       DIOs are sent over the minimal cell.

Or, it would be fine to say just "broadcast frames are (always) sent in the
minimal cell", although there is text which doesn't agree with this proposal:

draft> 5.1.  Adapting to Traffic
draft> (...)
draft> Autonomous cells are used indistinguishably together with dedicated
draft> cells, for broadcast or unicast traffic with the target neighbor.

* minor comment 4

The following part seems to me an implementation-specific optimization. And it
is beyond of the scope of this draft. Basically, this idea is about how to use
the minimal cell efficiently; it's not directly related to how to use cells
scheduled by MSF.

draft> (Section 2)
draft> Because the minimal cell is SHARED, the back-off algorithm defined in
draft> [IEEE802154-2015] is used to resolve collisions.  To ensure there is
draft> enough bandwidth available on the minimal cell, a node implementing MSF
draft> SHOULD enforce the following rules for broadcast frames:
draft> ...

* minor comment 5

The phrase of "After joining" in the explanation of step 3 should be "After
deciding a JP to use"? At this step 3, "joining" is not done.

draft> (Section 4)
draft> 4.4.  Step 3 - Setting up Autonomous Unicast Cells
draft> 
draft>    After joining, nodes MUST set up their autonomous unicast cells, as
draft>    described in Section 3.  This enables unicast communication in
draft>    Slotframe 1, until more cells are added with 6P as defined in
draft>    Section 5.
draft> 
draft> 4.5.  Step 4 - Join Request/Response

* minor comment 6

What is Section 10, "Rule for Ordering Cells", for...? Why do we need this
section?

That's all!

Best,
Yatch