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

[Simon Duquennoy <[e-mail]>]

On Fri, Aug 24, 2018 at 1:52 PM Yasuyuki Tanaka <[e-mail]>
wrote:

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

I fully agree this needs further discussion. In the worst case we might
have to move back the join traffic to the minimal cell, yes.


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

The draft currently says the slotframes SHOULD (not MUST) have the same
value.
The rationale for allowing different value is to have more flexible
dimensioning, and better adjust to more broadcast-intensive or
unicast-intensive networks.


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

Thanks for pointing out, will fix in next version.


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

Got it, thanks.


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

MSF assumes the presence of the minimal cell, but might be able to run
without the full RFC8180.
Happy to hear what others think


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

Agree, I think we should simply send all broadcast to the minimal cell.


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

I'll let other co-authors answer on that one


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

Good catch, will fix in next version


>
> * minor comment 6
>
> What is Section 10, "Rule for Ordering Cells", for...? Why do we need this
> section?
>

I'll let other co-authors answer


>
> That's all!
>

Thanks a lot Yatch!
Simon


>
> Best,
> Yatch
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>