Re: [6tisch] Clarification on MSF-06

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 <
christian.hopfner@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.hopfner@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. 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
> https://www.ietf.org/mailman/listinfo/6tisch
>

-- 
——————————————————————————————————————

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

www.tcahng.org
——————————————————————————————————————