Thanks Abdussalam for the comments, I updated the text as following: The node SHOULD send some form of keep-alive messages to all its neighbors it has negotiated cell with. The node sends a keep-
alive message to the neighbor if no frames is received from that neighbor within a period, which is defined as KA_PERIOD. This mechanism is used to poll its children to ensure the child is still reachable. 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. Does this read good to you? Tengfei On Fri, Oct 11, 2019 at 5:06 PM Abdussalam Baryun < [email protected]> wrote: > Hi Tengfei, > > I am interested like Christian to see the poll mechanism into this draft. > I don't think it is right to refer to RFC7554 (problem statement) which is > an informational RFC, while this draft is a proposed standard, I think it > is better to state the mechanism into the use case of minimum scheduling. > Furthermore, the RFC7554 does not mention once Keep-Alive message, but > mentions signalling messages, which may confuse users. > > Best regards > AB > > On Fri, Oct 11, 2019 at 3:41 PM Tengfei Chang <[email protected]> > wrote: > >> 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 >> > -- —————————————————————————————————————— Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tcahng.org ——————————————————————————————————————
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
