Hi Tengfei, that sound good to me, we may also add a recommendation for KAPERIOD into the constants table (figure 2)
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 christian.hopf...@endress.com | 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. Andreas Mayr, 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 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. Andreas Mayr, 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. 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. ________________________________ From: Tengfei Chang <tengfei.ch...@gmail.com> Sent: Friday, October 11, 2019 18:31 To: Abdussalam Baryun <abdussalambar...@gmail.com> Cc: Christian Hopfner <christian.hopf...@endress.com>; draft-ietf-6tisch-...@ietf.org <draft-ietf-6tisch-...@ietf.org>; 6tisch@ietf.org <6tisch@ietf.org> Subject: Re: [6tisch] Clarification on MSF-06 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 <abdussalambar...@gmail..com<mailto:abdussalambar...@gmail.com>> 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 <tengfei.ch...@gmail.com<mailto:tengfei.ch...@gmail.com>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7554&data=02%7C01%7Cchristian.hopfner%40endress.com%7C99cd88789ede4e3997a108d74e687f24%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637064083025962555&sdata=sY6Wt378p5MxJB0ZofsVEUKMjcySPT1OsC5MQ%2BuyCCU%3D&reserved=0>]. 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 <christian.hopf...@endress.com<mailto:christian.hopf...@endress.com>> 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 christian.hopf...@endress.com<mailto:christian.hopf...@endress.com> | www..pcm.endress.com<http://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 6tisch@ietf.org<mailto:6tisch@ietf.org> https://www.ietf.org/mailman/listinfo/6tisch<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6tisch&data=02%7C01%7Cchristian.hopfner%40endress.com%7C99cd88789ede4e3997a108d74e687f24%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637064083025972551&sdata=%2B7KuM8VaehVGHbmij%2FzdKriElWjNEIOytZZ4ooR9mkk%3D&reserved=0> -- —————————————————————————————————————— Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tcahng.org<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tcahng.org&data=02%7C01%7Cchristian.hopfner%40endress.com%7C99cd88789ede4e3997a108d74e687f24%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637064083025982541&sdata=naY6quyZiSyEDa%2B9NGQBus%2Fd%2BH%2BEAKwPnVY9Oa1pZjg%3D&reserved=0> —————————————————————————————————————— _______________________________________________ 6tisch mailing list 6tisch@ietf.org<mailto:6tisch@ietf.org> https://www.ietf.org/mailman/listinfo/6tisch<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2F6tisch&data=02%7C01%7Cchristian.hopfner%40endress.com%7C99cd88789ede4e3997a108d74e687f24%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637064083025982541&sdata=BQedG0%2Bv5YZIQ7sFXBO07GCvaBBMkpIUtrTjt2Y15Zg%3D&reserved=0> -- —————————————————————————————————————— Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tcahng.org<https://eur03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.tcahng.org&data=02%7C01%7Cchristian.hopfner%40endress.com%7C99cd88789ede4e3997a108d74e687f24%7C52daf2a93b734da4ac6a3f81adc92b7e%7C1%7C0%7C637064083025982541&sdata=naY6quyZiSyEDa%2B9NGQBus%2Fd%2BH%2BEAKwPnVY9Oa1pZjg%3D&reserved=0> ——————————————————————————————————————
_______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch
