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 <
abdussalambaryun@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.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
>>
>

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

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

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