Subject: [6tisch] Comments/questions about 6P draft

From: Remy Leone <[email-masked]>
Date: Thu, 02 Feb 2017 13:09:20 +0000

Hello,

I got a bunch of remarks about the 6P draft
https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03

*4.1.1. 2-step 6top Transaction*
*4.1.2. 3-step 6top Transaction*

Maybe it would be nice to add at the end of the workflow that if the
transaction was successful, the schedule generation is incremented to allow
inconsistencies detection.

*4.2.4. 6P Command Identifiers*

CMD_CLEAR: Maybe it would be a good idea to specify whether it soft, hard
or both cells that are concerned.

*4.2.6. 6P CellOptions*

In Figure 11, is there is mix-up between line 2 & 3
TX=1, *RX=0*, S=0 | select the cells scheduled with A and marked as *RX*
*TX=0*, RX=1, S=0 | select the cells scheduled with A and marked as *TX*

and the line 6 & 7?

*TX=1*, RX=0, S=1 | select the cells scheduled with A and marked as *RX*
and SHARED
TX=0, *RX=1*, S=1 | select the cells scheduled with A and marked as *TX*
and SHARED

TX and RX don't seem to match.

Also, I think it would be useful to define what SHARED means, I fail to
find the definition in this draft.

*4.3.6. Clearing the Schedule*

I think it would be a good idea to specify whether it's hard cells or soft
cells (or both) that are concerned by this.

*6. Implementation Status*

Support for 6P in Wireshark was merged upstream
https://github.com/wireshark/wireshark/commit/8b0e66f22c059533643195ba7571cafe9f006f58
Therefore there is a need to update the text concerning the Wireshark
dissector.

Best regards

Rémy

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 2 Feb 2017 16:38:51 +0100

Hi Rémy,

 From my understanding, CMD_CLEAR won't have any impact on hard cells since hard
cells are read-only for 6top.

https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-3.1
draft> 3.1.  Hard/Soft Cells
draft>
draft>    6top qualifies each cell in the schedule as either "hard" or "soft":
draft>
draft>    o  a soft cell can be read, added, deleted or updated by 6top.
draft>    o  a hard cell is read-only for 6top.
draft>    In the context of this specification, all the cells used by 6top are
draft>    soft cells.

> In Figure 11, is there is mix-up between line 2 & 3 ...
> and the line 6 & 7?

Oh, I didn't notice that!!

https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03#section-4.2.6
(row-2 in Figure 11)
draft>        +-------------+-----------------------------------------------+
draft>        |TX=1,RX=0,S=0| select the cells scheduled with A             |
draft>        |^^           | and marked as RX                              |
draft>        |             |               ^^                              |
draft>        +-------------+-----------------------------------------------+

> Also, I think it would be useful to define what SHARED means, I fail to find
> the definition in this draft.

I agree; we'd need some text explaining the meaning of each bit listed in
Figure 10. Actually, the idea come from Link Options defined in Section 7.4.4.3
in IEEE Std 802.15.4(-2015).

Best,
Yatch

On 2017/02/02 14:09, Remy Leone wrote:
> _4.1.1. 2-step 6top Transaction_
> _4.1.2. 3-step 6top Transaction_
>
> Maybe it would be nice to add at the end of the workflow that if the transaction was successful, the schedule generation is incremented to allow inconsistencies detection.
>
> _4.2.4. 6P Command Identifiers_
>
> CMD_CLEAR: Maybe it would be a good idea to specify whether it soft, hard or both cells that are concerned.
>
> _4.2.6. 6P CellOptions_
>
> *TX=1*, RX=0, S=1 | select the cells scheduled with A and marked as *RX* and SHARED
> TX=0, *RX=1*, S=1 | select the cells scheduled with A and marked as *TX* and SHARED
>
> Also, I think it would be useful to define what SHARED means, I fail to find the definition in this draft.
>
> _4.3.6. Clearing the Schedule_
>
> I think it would be a good idea to specify whether it's hard cells or soft cells (or both) that are concerned by this.
>
> _6. Implementation Status_
>
> Therefore there is a need to update the text concerning the Wireshark dissector.
>
>
> Best regards
>
> Rémy
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

---

From: Qin Wang <[email-masked]>
Date: Thu, 2 Feb 2017 16:29:30 +0000 (UTC)

Hi Remy,
Regarding to your question on 4.2.6.  6P CellOptions, the first column is the cell's type from node A's point of view, and the second column is the cell's type from node B's point of view. Does it make sense?
ThanksQin 

    On Thursday, February 2, 2017 8:09 AM, Remy Leone <[email-masked]> wrote:

 Hello,
I got a bunch of remarks about the 6P draft https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-03 

4.1.1. 2-step 6top Transaction4.1.2. 3-step 6top Transaction
Maybe it would be nice to add at the end of the workflow that if the transaction was successful, the schedule generation is incremented to allow inconsistencies detection.
4.2.4. 6P Command Identifiers
CMD_CLEAR: Maybe it would be a good idea to specify whether it soft, hard or both cells that are concerned.
4.2.6. 6P CellOptions
In Figure 11, is there is mix-up between line 2 & 3
TX=1, RX=0, S=0 | select the cells scheduled with A and marked as RXTX=0, RX=1, S=0 | select the cells scheduled with A and marked as TX 

and the line 6 & 7? 

TX=1, RX=0, S=1 | select the cells scheduled with A and marked as RX and SHARED TX=0, RX=1, S=1 | select the cells scheduled with A and marked as TX and SHARED 

TX and RX don't seem to match.
Also, I think it would be useful to define what SHARED means, I fail to find the definition in this draft.
4.3.6. Clearing the Schedule
I think it would be a good idea to specify whether it's hard cells or soft cells (or both) that are concerned by this.
6. Implementation Status
Support for 6P in Wireshark was merged upstreamhttps://github.com/wireshark/wireshark/commit/8b0e66f22c059533643195ba7571cafe9f006f58
Therefore there is a need to update the text concerning the Wireshark dissector.

Best regards
Rémy

---

From: Yasuyuki Tanaka <[email-masked]>
Date: Thu, 2 Feb 2017 17:38:50 +0100

Hi Qin,

 > Oh, I didn't notice that!!
Oops, you're right... Thank you! :-)

draft>                 Figure 10: Format of the CellOptions field
draft>
draft>    Note: assuming node A issues the 6P command to node B.
draft>          ^^^^^^^^^^^^^^^^^^^^^^
draft>        +-------------+-----------------------------------------------+
draft>        | CellOptions | B's action when receiving a 6P message from A |
draft>        | Value       | ^^^^^^^^^^                                    |
draft>        +-------------+-----------------------------------------------+
draft>        |TX=0,RX=0,S=0| select all cells scheduled with A             |
draft>        +-------------+-----------------------------------------------+
draft>        |TX=1,RX=0,S=0| select the cells scheduled with A             |
draft>        |             | and marked as RX                              |
draft>        +-------------+-----------------------------------------------+

Best,
Yatch

---

From: Remy Leone <[email-masked]>
Date: Thu, 02 Feb 2017 16:40:48 +0000

Yes it makes sense but I think it would be helpful to put a reminder such
as:

select the cells scheduled with A and marked as *RX *(therefore TX from B
point of view).

There is enough space for it and it won't hurt :-)

Le jeu. 2 févr. 2017 à 17:30, Qin Wang <[email-masked]> a écrit :

> Hi Remy,
>
> Regarding to your question on 4.2.6.  6P CellOptions, the first column is
> the cell's type from node A's point of view, and the second column is the
> cell's type from node B's point of view. Does it make sense?
>
> Thanks
> Qin
>
>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 3 Feb 2017 15:48:16 +0100

Remy,

Some answers inline, which porobably overlap Yatch's and Qin's answers.

> inconsistencies detection.

sure, it's a simple fix.

> or both cells that are concerned.

only the cells scheduled by the SF targetted. By defnition soft cells, but
that's not the main criteria/

> TX and RX don't seem to match.

Not an error, Node A's TX cell is node B's RX cell.

> find the definition in this draft.

It's a 802.15.4 TSCH term,

> cells (or both) that are concerned by this.

see above.

> Therefore there is a need to update the text concerning the Wireshark

yep, good point.

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________