Re: [6tisch] Jonathan's review on draft-ietf-6tisch-6top-interface-01

["Pascal Thubert (pthubert)" <[e-mail]>]

Pascal

Le 26 oct. 2014 à 19:07, Thomas Watteyne <[e-mail]<mailto:[e-mail]>> a écrit :

Jonathan,
Thanks for the super detailed review

Xavi,
Congratulatsion on the uber-quick action!

I'd like to further some of these points:

* Are all things in the YANG model required?  For example, must one support reading the READ.timesource for minTimeCorrection? Must all nodes support chunks, and tracks, and softcells, labelSwitching, or is this policy?
This is policy. Here we define all the DATA model.

This is a larger discussion, I'll start a new thread.

* Are all things in the YANG model expected to be encoded and sent over the air?
This is not decided yet. In principle this are configurable elements taht eventually need to be installed in a node. If this is done over the air, some of them are pre-configured is a thing we need to decide.

In my mind, the YANG model is a formal description of all the resources one can access over the air. We are defining two mechanisms which translate the YANG model into actual bits and bytes: draft-ietf-6tisch-coap allows remote control, draft-wang-6tisch-6top-coapie allows neighbor to neighbor control.

Thoughts?

Same here, though we could define a subset that must be configurable over the air whereas the rest may be...

Pascal

Thomas


On Fri, Oct 24, 2014 at 11:31 PM, Xavier Vilajosana <[e-mail]<mailto:[e-mail]>> wrote:
Dear Jonathan,

Thanks for your comments!  See inline my answers and I will move forward to address some of your comments on the current draft.

---------
Finally got around to reviewing this.  Better late than never?

p2 - odd sentence “This document also defines a list commands internal to the 6top sublayer.”

thanks I'll reword it.


p5 - CellType option is mandatory (2.1), but it seems to also be implicit in how the cell is created (2.1.1 & 2.1.2). Does MUST in these sections mean that this option must be set explicitly?

CellType is the way to indicate if the cell to be created is Hard or Soft. This field is mandatory to create a cell and thus we considered it to be explicit. However, as you say, let us consider if CellType might be inferred from context as the procedure to create a Hard Cell and a Soft Cell is different.

p7 - what does unicast (resp.broadcast) mean?
queues may be organized in different manners, here we indicate that there might be queues for packets to be sent to an specific neighbor (unicast) or packets to be broadcasted. Different queues might be used for unicast packets for example when we have different tracks where one ore more queues are mapped to the packets that flow on that track.

p9 - channelOffset should be 16-bit (per 802.15.4e-2012 table 52d)
thanks, we correct that.

p13 & 14 - the metrics listed do not correspond to those defined in 802.15.4e-2012 table 4i.    PDR, ETX, RSSI and LQI are not used in TSCH or macMetrics descriptions.
OK, here we thought top down, i.e what would be good for the upper layer to have. THis information can be computed at 6top or obtained from the LMAC/radio. RPL might be interested on that information.

- 4e defines a counter size, macCounterOctets, that needs to be specified by 6top - could be a fixed value or set via YANG.

We will add this field.

- “Window” measurement period is specified in "Number of the slotframe size” - Does “Number” here mean multiples? what if metrics apply to all slotframes?
This is thought to be a running window with a certain size. The comment is wrong and has a weak meaning. We wanted to indicate number of slots that form the window. Per your comments this should be extended to:

1- number of slotframes that form the window
2- All (all slotframes during mac lifetime)
3- number of slots that form the window (small windows)

so in conclusion windows should be configurable and be of one of these types.


p15 - “Peroid” instead of period.
- CellID - cell ID’s are local to a particular slotframe, so this is meaningless without a slotframe ID
you are right, we will add slotframeId as a primary key.


- If the period is in seconds, and the cell repeat rate is not, how is this supposed to work?

good point. We thought EBs are sent periodically. If not then Period field do not apply. Note however that every entry in the EBList represents a cell where an EB is sent. Do you think that during the lifetime of a TSCH network that cell will not be used more than once to send an EB? If it is used more than once there is a period and an expiration date.
If not we need to think what is the best way to express cells in particular slots within slotframes. Maybe indicating ASN?

p 17 - why is last comms ASN being stored?
we thought it as a timestamp to know when the last communication occurred. this might be used to force Keep Alive or to remove neighbors from the neighbor table. DO you see a better approach?

general questions/comments:

* Are all things in the YANG model required?  For example, must one support reading the READ.timesource for minTimeCorrection? Must all nodes support chunks, and tracks, and softcells, labelSwitching, or is this policy?
This is policy. Here we define all the DATA model.


* Are all things in the YANG model expected to be encoded and sent over the air?
This is not decided yet. In principle this are configurable elements taht eventually need to be installed in a node. If this is done over the air, some of them are pre-configured is a thing we need to decide.

* There is no mechanism to specify additional IEs in an EB - is this outside of YANG?
We need to discuss about that. It is a good point.

* There’s no way to set the PANID.
We will add it. thanks!

* Certain PIBs must be set in a generic 15.4e MAC to get TSCH behavior. I don’t know if these are needed in YANG, but need to be in 6TiSCH:
** some Table 52n on EBs entries need to be set
** Table 60 macFrameCounterMode needs to be 5 octets for ASN to work
** The fields needed to form the IEs contained in the EB are specified, but whether they are sent explicitly or by ID isn’t defined
** macTSCHcapable, and macTSCHEnabled, macMetricsCapable, macMetricsEnabled, aren’t discussed.
** There is no explicit configuration of EBs (e.g. macUseEnhancedBeacon) at the MAC or a discussion of MLME-BEACON.request.

THis are 15.4e specific fields. 6tisch (6top) should provide delegation interface so upper layers can configure these fields. Not sure thought that they need to be part of the YANG Model.


2014-10-25 2:31 GMT+02:00 Jonathan Simon <[e-mail]<mailto:[e-mail]>>:
Finally got around to reviewing this.  Better late than never?

p2 - odd sentence “This document also defines a list commands internal to the 6top sublayer.”

p5 - CellType option is mandatory (2.1), but it seems to also be implicit in how the cell is created (2.1.1 & 2.1.2). Does MUST in these sections mean that this option must be set explicitly?

p7 - what does unicast (resp.broadcast) mean?

p9 - channelOffset should be 16-bit (per 802.15.4e-2012 table 52d)

p13 & 14 - the metrics listed do not correspond to those defined in 802.15.4e-2012 table 4i.    PDR, ETX, RSSI and LQI are not used in TSCH or macMetrics descriptions.
- 4e defines a counter size, macCounterOctets, that needs to be specified by 6top - could be a fixed value or set via YANG.
- “Window” measurement period is specified in "Number of the slotframe size” - Does “Number” here mean multiples? what if metrics apply to all slotframes?

p15 - “Peroid” instead of period.
- CellID - cell ID’s are local to a particular slotframe, so this is meaningless without a slotframe ID
- If the period is in seconds, and the cell repeat rate is not, how is this supposed to work?

p 17 - why is last comms ASN being stored?

general questions/comments:

* Are all things in the YANG model required?  For example, must one support reading the READ.timesource for minTimeCorrection? Must all nodes support chunks, and tracks, and softcells, labelSwitching, or is this policy?
* Are all things in the YANG model expected to be encoded and sent over the air?
* There is no mechanism to specify additional IEs in an EB - is this outside of YANG?
* There’s no way to set the PANID.

* Certain PIBs must be set in a generic 15.4e MAC to get TSCH behavior. I don’t know if these are needed in YANG, but need to be in 6TiSCH:
** some Table 52n on EBs entries need to be set
** Table 60 macFrameCounterMode needs to be 5 octets for ASN to work
** The fields needed to form the IEs contained in the EB are specified, but whether they are sent explicitly or by ID isn’t defined
** macTSCHcapable, and macTSCHEnabled, macMetricsCapable, macMetricsEnabled, aren’t discussed.
** There is no explicit configuration of EBs (e.g. macUseEnhancedBeacon) at the MAC or a discussion of MLME-BEACON.request.
--
Jonathan Simon, Ph. D
Director of Systems Engineering
Linear Technology, Dust Networks product group
32990 Alvarado-Niles Road, Suite 910
Union City, CA 94587
[phone]<tel:%28510%29%20400-2936>
[phone]<tel:%28510%29%20489-3799> FAX
[e-mail]<mailto:[e-mail]>

**LINEAR TECHNOLOGY CORPORATION**
*****Internet Email Confidentiality Notice*****
 This e-mail transmission, and any documents, files or previous e-mail messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient, or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify me by reply e-mail, or by telephone at [phone]<tel:%28510%29%20400-2936>, and destroy the original transmission and its attachments without reading or saving in any manner. Thank you.


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



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


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