Re: [6tisch] Clarification on MSF-06

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.chang@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://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
> ——————————————————————————————————————
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>