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

[Xavier Vilajosana <[e-mail]>]

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]>om>:

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