Hello Tengfei I think you missed my points
> The text was not expected to become normative as is; obviously the usual > ways apply like time out if some but not all beacons are received and sync to > the best. > Yes, I agree with what you said, I replied with a wrong typing word. What I mean is: I have changed the sentence as you suggested: It's rephrased as: During this step, the pledge SHOULD NOT synchronize until it received enough EB from the network it wishes to join. Ø I meant if you are configured to get 10 beacons but after an hour you get only one, will you wait for 1000 years? Ø During this step, the pledge SHOULD NOT synchronize until it received Ø enough EB from the network it wishes to join or times out trying And here there should be an idea of a value for a number of beacons and a time out value. IESG reviews will ask that anyway so you better have something meaningful already. “ 8<https://tools.ietf.org/html/draft-ietf-6tisch-msf-04#section-8>. Rules for CellList “ Maybe add a rule to listen to the cells for a few slotframes to ensure that they are not used by neighbors. This can be done proactively, like the node monitors the 5 randomly chosen cells all the time, even when there is no excess traffic, so a list of empty cells is ready when needed. I think it's not necessary to listen on the cells because when the 6P transaction starts , those cells should be locked and not be applied for other 6P transactions. * The point is that another pair of devices may have negotiated a cell that shows in the list, which you may discover if you screen the cells you want to use before you start using them. * It really depends if you have a pool of cells that you own (e.g., admin) or just grab them pseudorandomly. In the latter case no checking the cells is impolite, and checking them just before using them may miss a partial usage. Listening to a pool of cell even when you do not allocate them is safer. I think this feature is defined in 6TOP (RFC8480) with the term locked: Nodes A and B MAY support having two transactions going on at the same time, one in each direction. Similarly, a node MAY support concurrent 6P Transactions with different neighbors. In this case, the cells involved in an ongoing 6P Transaction MUST be "locked" until the transaction finishes. ...... If the requested cells are locked, it MUST reply to that request with a 6P Response with return code RC_ERR_LOCKED (as per Figure 38). The node receiving RC_ERR_BUSY or RC_ERR_LOCKED MAY implement a retry mechanism as defined by the SF. * Not the same problem. Think about this, where does the list of free cells come from? How does the parent decided let me propose cells 5, 6, 7 and 10? * One possibility is that the controller has given them away as a chunk of cells that the parent manages, we have text in Archie for that. * The other is that the parent picks them pseudo randomly. Which means that another parent next to him might pick the same. If that is the case they will collide * This is an impolite behavior, the sort why we do CCA / LBT. In TSCH CCA and LBT are useless between synchronized nodes within a cell, but they can be useful before pseudo randomly grabbing a cell to add to the schedule. That cell should be observed using CCA for a while before it is proposed to the child in 6P. IOW there should be a pool of cells that are not used (yet) but observed (CCA) so you know you can allocate them safely later. Thanks a lot again for reviewing the draft and the comments! That’s a great spec : ) Pascal
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
