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

[Thomas Watteyne <[e-mail]>]

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?

Thomas


On Fri, Oct 24, 2014 at 11:31 PM, Xavier Vilajosana <
[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]>:
>
>> 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]
>> [phone] FAX
>> [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 (510)
>> 400-2936, and destroy the original transmission and its
>> attachments without reading or saving in any manner. Thank you.
>>
>>
>> _______________________________________________
>> 6tisch mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/6tisch
>>
>>
>
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>