Subject: [6tisch] Clarification on MSF-06

From: Christian Hopfner <[email-masked]>
Date: Fri, 11 Oct 2019 11:08:37 +0000

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-masked] |  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 <[email-masked]>
Date: Fri, 11 Oct 2019 15:40:41 +0200

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-masked]> wrote:

> 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)
>
> ------------------------------
> ------------------------------
>
> Endress+Hauser SE+Co. KG
> Vorstand: Dr. Peter Selders
> ------------------------------
>
> Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis
> <https://www.de.endress.com/de/cookies-endress+hauser-website> nach.
> ------------------------------
>
> Endress+Hauser SE+Co. KG
> Chief Executive Officer: Dr. Peter Selders
> ------------------------------
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

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

Dr. Tengfei, Chang
Postdoctoral Research Engineer, Inria

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

---

From: Abdussalam Baryun <[email-masked]>
Date: Fri, 11 Oct 2019 17:06:04 +0200

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-masked]>
wrote:

>    mechanism is detailed in [RFC7554 <https://tools.ietf.org/html/rfc7554>].  It uses the keep-alive messages
>> 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.
>>
>> 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)
>>
>> This e-mail does not constitute a contract offer, a contract amendment,
>> or an acceptance of a contract offer unless explicitly and conspicuously

---

From: Tengfei Chang <[email-masked]>
Date: Fri, 11 Oct 2019 18:31:27 +0200

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.

   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.

Does this read good to you?

Tengfei

On Fri, Oct 11, 2019 at 5:06 PM Abdussalam Baryun <
[email-masked]> 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.
>> 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.
>>
>>> 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?
>>>

Dr. Tengfei, Chang

www.tcahng.org

---

From: Christian Hopfner <[email-masked]>
Date: Mon, 14 Oct 2019 05:13:15 +0000

Hi Tengfei,

that sound good to me, we may also add a recommendation for KAPERIOD into the constants table (figure 2)

Christian Hopfner 

Endress+Hauser SE+Co. KG

Endress+Hauser SE+Co. KG

Disclaimer: 

________________________________
From: Tengfei Chang <[email-masked]>
Sent: Friday, October 11, 2019 18:31
To: Abdussalam Baryun <[email-masked]>
Cc: Christian Hopfner <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Subject: Re: [6tisch] Clarification on MSF-06

Tengfei

On Fri, Oct 11, 2019 at 5:06 PM Abdussalam Baryun <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> 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.

   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

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-masked]<mailto:[email-masked]>> wrote:
Hi authors,

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?

Christian Hopfner

________________________________
Developer | TPI F&E Plattform Informatik
Endress+Hauser SE+Co. KG | Hauptstrasse 1 | 79689 Maulburg | Germany
Phone: +49 7622 28 1883
[email-masked]<mailto:[email-masked]> | www.pcm.endress.com<http://www.pcm.endress.com>

________________________________

Endress+Hauser SE+Co. KG

________________________________

Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis<https://www.de.endress.com/de/cookies-endress+hauser-website> nach.

________________________________

Endress+Hauser SE+Co. KG

________________________________

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-masked]<mailto:[email-masked]>
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

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
[email-masked]<mailto:[email-masked]>
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

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>
——————————————————————————————————————