Hi Christian, Thanks for pointing this issue out! The neighbor polling section is removed at 03 version. Can't remember why we removed it.
I re-edited this sections to fit the current content of MSF draft. I paste it below. It will the be last step of boot behavior after it starts sending EB and DIO. The node SHOULD send some form of keep-alive messages to all its neighbors it has negotiated cell with. The Keep-Alive (KA) mechanism is detailed in [RFC7554 <https://tools.ietf.org/html/rfc7554>]. It uses the keep-alive messages to its preferred parent to stay synchronized. It MAY use the keep- alive messages to other neighbors to have statistics on link quality. It MAY use the keep-alive messages to its children to ensure the child is still reachable. The RECOMMENDED period for sending keep- alive messages is KA_PERIOD. If the keep-alive message to a child fails at the link layer (i.e. the maximum number of link-layer retries is reached), the node SHOULD declare the child as unreachable. This can happen for example when the child node is switched off. When a neighbor is declared unreachable, the node MUST remove all negotiated cells with that neighbor from its own schedule. In addition, it MAY issue a 6P CLEAR to that neighbor (which can fail at the link-layer). The node MAY be removed from the neighbor table. If this is good for you, I will update the MSF to 07 with this change and propose WGLC right after. Thanks! Tengfei On Fri, Oct 11, 2019 at 1:09 PM Christian Hopfner < [email protected]> wrote: > Hi authors, > > I may raise a clarification question before issuing WGLC for this draft. > > In the past there was a section in the draft dealing with neighbor polling > which seems to me beeing an important topic in terms of schedule > consistency. > > In the latest version I don't see a mechanism which explains how a parent > keeps its schedule clean after some children silently disappeared (e.g.. > batteries are gone). As per my understanding in such a case the negotiated > RX cell towards the child remains in the schedule forever right? > > Previously this was handled by neighbor polling. Which required the parent > to send KA packets in a periodic manner to its childset. (This could be > identified by evaluation of the neighbor set where a negotiated RX cell was > scheduled to) > > What is the idea now how to deal with that issue? > > > Mit freundlichen Grüßen I Best regards > > Christian Hopfner > ------------------------------ > Developer | TPI F&E Plattform Informatik > Endress+Hauser SE+Co. KG | Hauptstrasse 1 | 79689 Maulburg | Germany > Phone: +49 7622 28 1883 > [email protected] | www.pcm.endress.com > > ------------------------------ > > Endress+Hauser SE+Co. KG > Registergericht: Amtsgericht Freiburg i.Br. HRA 670225 > Sitz der Gesellschaft: Maulburg > Persönlich haftender Gesellschafter: Endress+Hauser Administration SE > Sitz des persönlich haftenden Gesellschafters: Maulburg > Registergericht: Amtsgericht Freiburg i.Br. HRB 717326 > Vorstand: Dr. Peter Selders > Aufsichtsratsvorsitzender: Matthias Altendorf > ------------------------------ > > Gemäss der Datenschutzgrundverordnung (EU-DSGVO) sind wir verpflichtet, > Sie zu informieren, > wenn wir personenbezogene Daten von Ihnen erheben. > > Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis > <https://www.de.endress.com/de/cookies-endress+hauser-website> nach. > ------------------------------ > > Endress+Hauser SE+Co. KG > Register Court: Local Court of Freiburg i.Br. HRA 670225 > Registered Office: Maulburg > General Partner: Endress+Hauser Administration SE > Registered Office of General Partner: Maulburg > Register Court: Local Court of Freiburg i.Br. HRB 717326 > Chief Executive Officer: Dr. Peter Selders > Chairman of the Board: Matthias Altendorf > ------------------------------ > > According to the General Data Protection Regulation, > we are obliged to inform you when collecting your personal data. > We comply with this information duty with the following Data Protection > Statement > <https://www.de.endress.com/en/endress-hauser-website-cookies/en-data-protection-notice-de> > ------------------------------ > > > > Disclaimer: > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential, proprietary, and/or > privileged > material. Any review, retransmission, dissemination or other use of, or > taking of any action in reliance upon, this information by persons or > entities > other than the intended recipient is prohibited. If you receive this in > error, please contact the sender and delete the material from any computer. > This e-mail does not constitute a contract offer, a contract amendment, or > an acceptance of a contract offer unless explicitly and conspicuously > designated or stated as such. > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > -- —————————————————————————————————————— Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tcahng.org ——————————————————————————————————————
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
