Le 29 nov. 2019 à 16:19, Tengfei Chang <tengfei.ch...@gmail.com> a écrit :
Hi Pascal,
For the preferred parent issue:
When running MSF, the node is deal with one parent at a time out of
the parent set, which we called preferred parent.
It doesn't mean there is only one parent for each nodes.
The node may change its preferred parent to other parent, which
responded in the switching_parent section in MSF.
For the sentence:
It is recommended to set MAX_NUMCELLS value at least 4x of the
maximum link traffic load of the network with unit of packets per
slotframe.
The following example helps to understand the meaning:
For example, a 2 packets/slotframe traffic load results an average
4 cells scheduled, using the value of double number of scheduled
cells (which is 8) as MAX_NUM_CELLS gives a good resolution on
cell usage calculation.
Any recommendation on the rephrasing?
Tengfei
On Wed, Nov 27, 2019 at 10:07 PM Pascal Thubert (pthubert)
<pthub...@cisco.com <mailto:pthub...@cisco.com>> wrote:
Hello Tengfei
Please see below
Le 27 nov. 2019 à 21:44, Tengfei Chang <tengfei.ch...@gmail.com
<mailto:tengfei.ch...@gmail.com>> a écrit :
Thanks a lot for the reviewing, I responded inline:
On Mon, Nov 25, 2019 at 6:42 PM Pascal Thubert (pthubert)
<pthub...@cisco.com <mailto:pthub...@cisco.com>> wrote:
Dear all____
__ __
Please find some comments below: ____
__ __
__ __
__ __
__ __
Please migrate to XML2RFC v3. This will save time in the future.
TC: got it! Will used in version 9.
:)
____
__ __
__ __
__ __
____
However, an implementor MAY implement MSF without
implementing____
Minimal 6TiSCH Configuration. ____
__ __
__ __
This is not helpful without explanations. What is the
tradeoff? How does the network operates in that case?
TC: Yes, the sentence is misleading. What we try to say is MSF
can work with other specifications protocols, rather then minimal
6TiSCH configuration, as long as the protocols gives a way to
communicate the EB and DIO among the network.
Those words in the draft will make me a happy shepherd...
____
__ __
__ __
__ __
__ __
For example, a Trickle Timer defined in____
[RFC6550 <https://tools.ietf.org/html/rfc6550>] MAY be applied on
DIOs. However, this behavior is____
implementation-specific which is out of the scope of MSF.____
__ __
__ __
This is not for this spec to define. RPL already mandates
trickle. Suggestion:____
__ __
For example, the Trickle operation defined in [RFC6206]____
is applied on DIO Messages [RFC6550
<https://tools.ietf.org/html/rfc6550>]. This behavior is____
out of the scope of MSF.____
__
TC: agreed!
__
__ __
__ __
__ __
__ __
MSF RECOMMENDS the use of 3 slotframes. ____
__ __
Discussion on slotframes and cells comes without an
introduction to TSCH. ____
I’d suggest you add a few words on RFC 7554 appendix A and
6TiSCH architecture section 4.3.5. to introduce those
concepts.____
They should probably be normative references.
TC: I added the following text at beginning of section 2:
In a TSCH network, time is sliced up into time slots.
The time slots are grouped as one of more slotframes
which repeat over time.
The TSCH schedule instructs a node what to do at each
time slots, such as transmit, receive or sleep <xref
target="RFC7554"/>.
In case of a slot to transmit or receive, a channel
is assigned to the time slot.
The tuple (slot, channel) is indicated as a cell of
TSCH schedule.
MSF is one of the policies defining how to manage the
TSCH schedule.
Excellent
____
__ __
__ __
__ __
__ __
Section 4 has numerous SHOULD. Trouble is, when SHOULD is
used, the author SHOULD explain the alternate, what if the
SHOULD is not followed. ____
Sometimes it’s quite obvious, like when using random in 4.2.
But SHOULD use minimal is less obvious. Please consider
adding text after the SHOULDs.
TC: agreed! I have resolved this SHOULD issues in a new version.
either the unnecessaries are removed or alternative explanation
is added
I’ll review once you published
____
__ __
__ __
__ __
field it contains, the presence and contents of the IE
defined in____
[I-D.richardson-6tisch-join-enhanced-beacon
<https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#ref-I-D.richardson-6tisch-join-enhanced-beacon>],
or the key used to____
authenticate it.____
__ __
The reference is now draft-ietf.. I agree that it should be
normative; no worries the draft is already submitted for
publication.____
More important: Please move the reference to
6tisch-dtsecurity-zerotouch-join to informational. This is a
DOWNREF today and your draft may be stuck in MISSREF in the
future.
TC: I have updated *richardson-6tisch-join-enhanced-beacon* to
* ietf-6tisch-enrollment-enhanced-beacon.*
I didn't get it how "*move the reference to
6tisch-dtsecurity-zerotouch-join to informational*" is done in
the draft?
Sorry I was unclear. The draft is currently listed as a normative
reference. This means that MSF will be held forever in miss ref at
the RFC editor. Please move the link to the reference in the
informational references section.
____
__ __
__ __
__ __
After selected a preferred parent, the joined node MUST
generate a 6P____
__ __
Grammar: “After selecting” or “once it has selected” sound
better. ____
__
TC: the latter sounds better! Thanks!
__
__ __
__ __
Section Section 8
<https://tools.ietf.org/html/draft-ietf-6tisch-msf-08#section-8>____
__ __
The <xref …> already generates the word “section”. If you
write it too, it becomes duplicated as above.
TC: agreed!
____
__ __
__ __
__ __
For a node, this translates into____
monitoring the current usage of the cells it has to its
preferred____
parent:____
__ __
This is disturbing. MSF should not be used only with
preferred parents. The whole game of doing a DODAG is to have
and possibly use multiple parents. ____
A node can for instance send a NSM DAO with multiple transit
options to the root. Also, it could be good to clarify that
the child manages both directions. ____
Proposal:____
__ __
For a node, this translates into____
monitoring the current usage of the cells it has to the
parents it uses____
at this point of time for sending and receiving traffic:____
__ __
Later there a numerous references to “preferred parent” =>
I’d suggest you use just “selected parent” or “active parent”
or something in that vein.
TC: I think "preferred parent" is same with "selected parent".
it indicates one preferred parent out of multiple. Isn't it right?
My problem is that there’s only one preferred parent, but a node
may use several parents for data traffic. This is why we build
dodags in the first place.
I believe that the node may allocate cells with all of those
“selected parents” if it likes. The use of “preferred parent” in
that text would prevent this.
Please make sure your text does not limit to one parent...
____
__ __
__ __
Cell installed at initial____
__ __
Not sure this is correct. Maybe “at init time”
TC: Applied!
____
__ __
__ __
__ __
__ __
It is recommended to set MAX_NUMCELLS value at____
least 4 times than the maximum link traffic load of the
network in____
packets per slotframe.____
__ __
__ __
This does not parse. Can you please rephrase?
TC: it's rephrased as "*It is recommended to set MAX_NUMCELLS
value at least 4x of the maximum link traffic load of the network
with unit of packets per slotframe*."
I still have a hard time
Do you mean “4 times the maximum number of used cells in a slot
frame in recent history” ?
____
__ __
__ __
__ __
__ __
Section 8 does not try to avoid collisions with autocells.
But it’s easy to compute the slot offset of autocells for
self and parent and avoids those. Why not do that?
TC: agreed! Will apply in the next version.
____
__ __
__ __
__ __
Section 16 will require more attention, either now or during
secdir review, probably both. You should start now. Think,
say, what if an attacker claims many cells to all its
neighbors? Can it attack someone’s autocells to block him?
TC: That's a good question! It may have a chance to do so. We
need discuss internally on this section.
Thanks for belling ahead!
Speaking from experience with secdir. Better be prepared they will
be coming for you ; )
Take care
Pascal
____
__ __
__ __
__ __
Voila!____
__ __
Pascal as shepherd.____
__ __
__ __
__ __
__ __
__ __
__ __
_______________________________________________
6tisch mailing list
6tisch@ietf.org <mailto:6tisch@ietf.org>
https://www.ietf.org/mailman/listinfo/6tisch
--
——————————————————————————————————————
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria
www.tchang.org/ <http://www.tchang.org/>
——————————————————————————————————————
--
——————————————————————————————————————
Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria
www.tchang.org/ <http://www.tchang.org/>
——————————————————————————————————————
