Hi Yatch, thanks so much for the review. I jump in complementing Simon´s answer.
Missatge de Simon Duquennoy <simon.duquen...@ri.se> del dia dv., 31 d’ag. 2018 a les 10:27: > On Fri, Aug 24, 2018 at 1:52 PM Yasuyuki Tanaka <yasuyuki.tan...@inria.fr> > wrote: > >> Hi authors, >> >> Congratulations on this great work! >> >> https://tools.ietf.org/html/draft-ietf-6tisch-msf-00 >> >> I'm sharing my comments on the draft; major comments are followed by minor >> comments. >> >> * discussion: when to schedule autonomous TX cells to neighbors >> >> According to Section 4, a join proxy (JP) needs to schedule an autonomous >> TX >> cell to a node (pledge) who wants to join the network. Thanks to this, a >> join >> process can be done with the autonomous cells of the JP and pledge. These >> autonomous cells make the network formation faster. >> >> However, from the view point of security, it'd be better to avoid >> installing any >> state for an unauthenticated/unauthorized node. In this particular case, >> the >> join proxy shouldn't schedule the autonomous cell to the pledge. >> >> We would need some discussion in "Security Considerations" section if we >> allow >> JPs to install autonomous TX cells to their pledges. >> > > I fully agree this needs further discussion. In the worst case we might > have to move back the join traffic to the minimal cell, yes. > > >> >> * question: why do we need a separate slotframe for MSF? >> >> MSF avoids using slot offset 0 for its autonomous cells and its dedicated >> cells >> anyway. The length of Slotframe 1 for MSF is the same as Slotframe 0 >> >> draft> (Section 3) >> draft> As detailed in Section 2.2 of [I-D.ietf-6tisch-6top-protocol], MSF >> MUST >> draft> schedule cells from Slotframe 1, while Slotframe 0 is used for >> traffic >> draft> defined in the Minimal 6TiSCH Configuration. >> draft> (...) >> draft> The first time offset is skipped to avoid colliding with the >> minimal cell >> draft> in Slotframe 0. >> >> draft> 8. Rules for CellList >> draft> >> draft> (snip) >> draft> o The slotOffset value of any cell in the CellList MUST NOT be >> the >> draft> same as the slotOffset of the minimal cell (slotOffset=0).. >> > > The draft currently says the slotframes SHOULD (not MUST) have the same > value. > The rationale for allowing different value is to have more flexible > dimensioning, and better adjust to more broadcast-intensive or > unicast-intensive networks. > > >> >> * question: parameters for SAX >> >> What values are used for L and R in SAX? It'd be nice to have an example >> or a >> test vector in the draft in order to validate a SAX implementation used >> for >> MSF. This is critical for interoperability. >> > > Thanks for pointing out, will fix in next version. > > >> >> * minor comment 1 >> >> draft> (Section 1) >> draft> The end state of the join process is that the node is synchronized >> to the >> draft> network, has mutually authenticated to the network, has identified >> a >> draft> preferred routing parent, has scheduled one default unicast cell >> to/from >> draft> each of its neighbors. >> >> The latter part of this sentence seems not to be accurate. >> >> After the join process, the node (pledge) has the following cells: >> >> - the minimal cell defined by RFC 8180 >> - one autonomous RX cell >> - autonomous TX cells to its JP >> >> This doesn't fit "one default unicast cell to/from each of its neighbors.." >> > > Got it, thanks. > > >> >> * minor comment 2 >> >> draft> (Section 2) >> draft> A node implementing MSF MUST implement the Minimal 6TiSCH >> Configuration >> draft> [RFC8180], which defines the "minimal cell", a single shared cell >> draft> providing minimal connectivity between the nodes in the network. >> >> 'MUST' here sounds too strong... Some may want to use MSF with a base >> schedule >> other than one defined RFC 8180 with full understands on implications by >> not >> following RFC 8180. Then, I'd propose 'SHOULD'. >> >> By the way, I'm not sure whether we can specify 'MUST implement' to a BCP >> document or not. >> > > MSF assumes the presence of the minimal cell, but might be able to run > without the full RFC8180. > Happy to hear what others think > XV>> MSF needs at least one pre-existing cell in the schedule so a node can receive/send EBs and form/join into the network. To ensure this we enforce RFC8180. I think that if someone else implements any other policy there won't be conflict with the existence of a minimal cell as RFC8180 only recommends default values which can be overriden. > > >> >> * minor comment 3 >> >> draft> (Section 2) >> draft> 2. DODAG Information Objects (DIOs), defined by [RFC6550]. These >> are >> draft> broadcast frames. >> >> A DIO can be sent in a unicast frame. >> >> rfc6550> 8.3. DIO Transmission >> rfc6550> (...) >> rfc6550> When a node receives a unicast DIS message with a Solicited >> Information >> rfc6550> option and matches the predicates of that Solicited Information >> option, >> rfc6550> it MUST unicast a DIO to the sender in response. >> >> So, that sentence could be... >> >> 2. DODAG Information Objects (DIOs), defined by [RFC6550]. >> Broadcasted >> DIOs are sent over the minimal cell. >> >> Or, it would be fine to say just "broadcast frames are (always) sent in >> the >> minimal cell", although there is text which doesn't agree with this >> proposal: >> >> draft> 5.1. Adapting to Traffic >> draft> (...) >> draft> Autonomous cells are used indistinguishably together with dedicated >> draft> cells, for broadcast or unicast traffic with the target neighbor. >> > > Agree, I think we should simply send all broadcast to the minimal cell. > > >> >> * minor comment 4 >> >> The following part seems to me an implementation-specific optimization. >> And it >> is beyond of the scope of this draft. Basically, this idea is about how >> to use >> the minimal cell efficiently; it's not directly related to how to use >> cells >> scheduled by MSF. >> >> draft> (Section 2) >> draft> Because the minimal cell is SHARED, the back-off algorithm defined >> in >> draft> [IEEE802154-2015] is used to resolve collisions. To ensure there >> is >> draft> enough bandwidth available on the minimal cell, a node >> implementing MSF >> draft> SHOULD enforce the following rules for broadcast frames: >> draft> ... >> > > I'll let other co-authors answer on that one > XV> here we place a SHOULD and not a MUST. We want to make sure the network works as if there is over-use of the minimal cell collapses. We think this should be said here so an adopter is aware of the limitations and implements a working measure. > > >> >> * minor comment 5 >> >> The phrase of "After joining" in the explanation of step 3 should be >> "After >> deciding a JP to use"? At this step 3, "joining" is not done.. >> >> draft> (Section 4) >> draft> 4.4. Step 3 - Setting up Autonomous Unicast Cells >> draft> >> draft> After joining, nodes MUST set up their autonomous unicast >> cells, as >> draft> described in Section 3. This enables unicast communication in >> draft> Slotframe 1, until more cells are added with 6P as defined in >> draft> Section 5. >> draft> >> draft> 4.5. Step 4 - Join Request/Response >> > > Good catch, will fix in next version > > >> >> * minor comment 6 >> >> What is Section 10, "Rule for Ordering Cells", for...? Why do we need this >> section? >> > > I'll let other co-authors answer > XV> I think this was though to handle pagination when the LIST command is received. This is, define what are the cells to return when a list command is requesting cells from a particular offset. > > >> >> That's all! >> > > Thanks a lot Yatch! > Simon > > >> >> Best, >> Yatch >> >> _______________________________________________ >> 6tisch mailing list >> 6tisch@ietf.org >> https://www.ietf.org/mailman/listinfo/6tisch >> > _______________________________________________ > 6tisch mailing list > 6tisch@ietf.org > https://www.ietf.org/mailman/listinfo/6tisch > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 xvilajos...@uoc.edu <usu...@uoc.edu> http://xvilajosana.org http://wine.rdi.uoc.edu Parc Mediterrani de la Tecnologia Av Carl Friedrich Gauss 5, B3 Building 08860 Castelldefels (Barcelona). Catalonia. Spain [image: Universitat Oberta de Catalunya]
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
