Yatch, About :
*Why does the node have to issue a 6P CLEAR to a neighbor which is determined to be unreachable...? It just wastes time and energy of the initiator since this transaction will fail as the draft mentioned. I think it'd be fine to remove all the dedicated cells to the unreachable neighbor without 6P CLEAR. By the way, the term "cells" should be used instead of "links".* I would recommend to use a MAY in this case. That is, a node MUST remove cells, and MAY send a CLEAR. Thomas On Wed, Feb 14, 2018 at 5:28 AM, Xavi Vilajosana Guillen < xvilajos...@uoc.edu> wrote: > Dear Yatch, > > thanks for your comments! see inline my answers. > > 2018-02-13 18:13 GMT+01:00 Yasuyuki Tanaka <yasuyuki.tan...@inria.fr>: > >> Hi all, >> >> I'd like to share my comments on draft-chang-6tisch-msf-00: >> >> https://tools.ietf.org/html/draft-chang-6tisch-msf-00 >> >> The first one is about 6P CLEAR after detecting unreachability to a >> neighbor. >> >> > 3.8. Step 7 - Neighbor Polling >> > >> > (snip) >> > >> > When a neighbor is declared unreachable, the node MUST issue a 6P >> > CLEAR to that neighbor (which can fail at the link-layer), and MUST >> > remove all dedicated links with that neighbor from its own schedule. >> >> >> Why does the node have to issue a 6P CLEAR to a neighbor which is >> determined to be unreachable...? It just wastes time and energy of the >> initiator since this transaction will fail as the draft mentioned. I think >> it'd be fine to remove all the dedicated cells to the unreachable neighbor >> without 6P CLEAR. By the way, the term "cells" should be used instead of >> "links". >> >> > XV> I agree. A node can directly reset its schedule. We will change that > sentence. > > >> Other comments are trivial. >> >> > 1. Introduction >> > >> > (snip) >> > >> > MSF is designed to operate in a wide range of application domains. >> > It is optimized for applications with regular upstream traffic (from >> > the nodes to the Internet). >> >> "The internet" sounds too specific. "From the nodes toward the root" >> would be better? >> > > XV>> Agree. > >> >> > 2. Interface to the Minimal 6TiSCH Configuration >> > >> > (snip) >> > >> > MSF uses the minimal cell to exchange the following packets: >> > >> > ... >> > >> > 4. The first 6P packet a node issues to a neighbor it doesn't have >> > dedicated cells to, as defined by >> > [I-D.ietf-6tisch-6top-protocol]. These are unicast frames. >> >> The minimal cell is used for not only the first 6P packet but also >> subsequent packets associated with a 6P transaction initiated by the first >> packet. In this sense, I'd like to propose to replace it with: >> >> 6P packets to schedule the first dedicated cell with a neighbor. There >> are unicast frames. >> > > XV>> Agree. > >> >> > 7. Rules for CellList >> > >> > >> > MSF uses 2-step 6P Transactions exclusively. 6P Transactions are >> > only initiated by a node towards it preferred parent. As a result, >> > the cells to put in the CellList of a 6P ADD command, and in the >> > candidate CellList of a RELOCATE command, are chosen by the node. In >> > both cases, the same rules apply: >> > >> > the CellList SHOULD contain 5 or more cells. >> > Each cell in the CellList MUST have a different slotOffset value. >> > For each cell in the CellList, the node MUST NOT have any >> > scheduled cell on the same slotOffset. >> > The slotOffset value of any cell in the CellList MUST NOT be the >> > same as the slotOffset of the minimal cell (slotOffset=0). >> > The slotOffset of a cell in the CellList SHOULD be randomly and >> > uniformly chosen among all the slotOffset values that satisfy the >> > restriction above. >> > The channelOffset of a cell in the CellList SHOULD be randomly and >> > uniformly in [0..numFrequencies] where numFrequencies represents >> > the number of frequencies a node can communicate on. >> >> >> Is this a format error...? >> > > XV>> No, I think this is a bullet list with "invisible" bullets :) . We > add the bullets. > >> >> > 8. 6P Timeout Value >> > >> > >> > The 6P Timeout is not a constant value. It is calculated a (C/ >> > PDR)*6PTIMEOUT_SEC_FACTOR, where: >> >> >> I think it'd be better for a variable name to start with a non-numeric >> character even in a document. >> >> > XV>> Agree. > > >> That's it! >> >> Best, >> Yatch >> > > thanks Yatch! > regards > X > >> _______________________________________________ >> 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 <+34%20646%2063%2036%2081> > 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 > > -- ________________________________________ Thomas Watteyne, PhD Research Scientist & Innovator, Inria Sr Networking Design Eng, Analog Devices Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH www.thomaswatteyne.com ________________________________________
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
