Return-Path: X-Original-To: 6tisch@ietfa.amsl.com Delivered-To: 6tisch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8201200A3; Sun, 13 Oct 2019 22:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=endress.com header.b=Ln063Qmq; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=endress.com header.b=r3OiorxW Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAUscYUp66K4; Sun, 13 Oct 2019 22:13:24 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140085.outbound.protection.outlook.com [40.107.14.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DD01120059; Sun, 13 Oct 2019 22:13:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endress.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VjgZsfe1KzEuPfFqvAu9e8h1FPwWTfMdoxBm68qaZBI=; b=Ln063Qmqe91jkngCb2FNFrD8I+AVUiC0jBPhcRE+nIul/6vAWaaNedJPSzPgYgnbs0Hl4VGwryTYxBTEqlx744kGsAwYMg4n8UrpJpQqD2+2cwtl9LX/2xGbwO0on1Ojdl297ipSezRTD2ceF2kIbvvnIBdC/MYLM8eTPVyRqHU= Received: from HE1PR05CA0192.eurprd05.prod.outlook.com (2603:10a6:3:f9::16) by AM0PR0502MB3796.eurprd05.prod.outlook.com (2603:10a6:208:1e::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Mon, 14 Oct 2019 05:13:18 +0000 Received: from VE1EUR03FT003.eop-EUR03.prod.protection.outlook.com (2a01:111:f400:7e09::201) by HE1PR05CA0192.outlook.office365.com (2603:10a6:3:f9::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2347.16 via Frontend Transport; Mon, 14 Oct 2019 05:13:18 +0000 Authentication-Results: spf=pass (sender IP is 40.113.82.155) smtp.mailfrom=endress.com; ietf.org; dkim=fail (body hash did not verify) header.d=endress.com;ietf.org; dmarc=pass action=none header.from=endress.com; Received-SPF: Pass (protection.outlook.com: domain of endress.com designates 40.113.82.155 as permitted sender) receiver=protection.outlook.com; client-ip=40.113.82.155; helo=iqsuite.endress.com; Received: from iqsuite.endress.com (40.113.82.155) by VE1EUR03FT003.mail.protection.outlook.com (10.152.18.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Mon, 14 Oct 2019 05:13:18 +0000 Received: from mail pickup service by iqsuite.endress.com with Microsoft SMTPSVC; Mon, 14 Oct 2019 07:13:17 +0200 Received: from EUR03-DB5-obe.outbound.protection.outlook.com ([104.47.10.53]) by iqsuite.endress.com over TLS secured channel with Microsoft SMTPSVC(8.5.9600.16384); Mon, 14 Oct 2019 07:13:16 +0200 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GDYN0V+mMbpnddv5SpcnOxwdyc/x5iChtocxjpSz6adU6BcPHaKSOXXZeKi0m3Teclvj+O83+rnPh50x3+WaEf3pb22NxDQeNPRC2TfV05e8h70qfurIiMmDCy3YNbYPY1QRbqEj2vVRhElIxRYGUbVl9fqXNorXYvKdao8Od85dUFCtTLslVM7EyapzQmtyeNibOPelu4KX+F25eWwyMyKsAwvxE+HMl4AVwXcEr1hKNX/3E8VgDUzptANFV4RCEb5XVgft52o+JHNcZ6OBANU/eH5wTBFETMZBraGs2+1mQXWO9DFEj4RX9oLqG5P3H27YO6y7WbQ9S+zjahIDWQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PATBBpIST5IGcK//ANKuBci9mNugvr+j1fsQPTa5ioA=; b=DZa20+IECvUUBGSmaqyLay3lXbSntsZQVW+7l2XCfmqRmaT2XAZmxT6wvuEYa2IhN61ftB+PuAcyIuoAsqg/Z0sfcEh2ggrEBx4Nr+ZhTrkdHdfJT7YLD4ceSTSB8SB2+pn2cU/RXEMs4HINt/IOLnaBs2+qwORsME4b4/o3o8sRIB6maIUcQ6Mf1dV2/b7n7mvM/fyT5IHum1WcIcbpJSfCQqX1g1djkSCgkPehUCG4In8bB56FSsd4RTD/b7WjmVciPCtz/mW54UMpjBcNIp9RzQsH1ALRrNYY5a49Q1A1+V7iqIiojAOSXkXSAWxzjXYrR8VtvF37OUYcLlSIng== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=endress.com; dmarc=pass action=none header.from=endress.com; dkim=pass header.d=endress.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endress.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=PATBBpIST5IGcK//ANKuBci9mNugvr+j1fsQPTa5ioA=; b=r3OiorxW+jrJoD/S5s416cNngsl+uWgWbAz7xi7SMFfLgzAqLB/dWohexqD7AlWbtU5BgpR+CbQLuYafj4M4c1BNRFv7nuocidjfJ08gyJNLPWa96wil8+oQezfRjebsxHuQyoXrtx2mr7QbV1Jmqvcxns18H7cI0AS4lVY1JSE= Received: from AM0PR05MB4643.eurprd05.prod.outlook.com (52.133.58.14) by AM0PR05MB6545.eurprd05.prod.outlook.com (20.179.35.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.21; Mon, 14 Oct 2019 05:13:15 +0000 Received: from AM0PR05MB4643.eurprd05.prod.outlook.com ([fe80::3c5f:ee3:f20e:9112]) by AM0PR05MB4643.eurprd05.prod.outlook.com ([fe80::3c5f:ee3:f20e:9112%5]) with mapi id 15.20.2347.021; Mon, 14 Oct 2019 05:13:15 +0000 From: Christian Hopfner To: Tengfei Chang , Abdussalam Baryun CC: "draft-ietf-6tisch-msf@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch] Clarification on MSF-06 Thread-Index: AQHVgCJg6rB2y0zdwUaGjL2mNkbMnKdVcq2AgAAX2wCAABfbgIAD+PuM Date: Mon, 14 Oct 2019 05:13:15 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Authentication-Results-Original: spf=none (sender IP is ) smtp.mailfrom=christian.hopfner@endress.com; x-originating-ip: [80.149.176.5] x-ms-publictraffictype: Email X-MS-Office365-Filtering-Correlation-Id: 4b7aff7d-6d6c-4cf2-9d2b-08d750653984 X-MS-TrafficTypeDiagnostic: AM0PR05MB6545:|AM0PR0502MB3796: X-MS-Exchange-PUrlCount: 6 X-Microsoft-Antispam-PRVS: x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; x-forefront-prvs: 01901B3451 X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(376002)(396003)(39860400002)(366004)(26234003)(199004)(189003)(606006)(25786009)(6506007)(71190400001)(66574012)(5660300002)(99286004)(8936002)(81166006)(81156014)(8676002)(186003)(76176011)(7696005)(966005)(66066001)(14454004)(52536014)(71200400001)(54906003)(53546011)(102836004)(110136005)(33656002)(26005)(86362001)(316002)(478600001)(44832011)(7736002)(6116002)(3846002)(476003)(74316002)(2906002)(54896002)(446003)(6306002)(14444005)(256004)(105004)(486006)(11346002)(4326008)(236005)(19627405001)(66446008)(64756008)(66556008)(66476007)(66946007)(76116006)(6436002)(6246003)(9686003)(229853002)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR05MB6545; H:AM0PR05MB4643.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: endress.com does not designate permitted sender hosts) X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 2Zea/3ohICI67eE2O5ik6UzFO5hZddjRgad1Jt+ByhN656eKTkUuHIRymlUBCUt4vYBMdFR+8XkwpVOkymD8kMOwp30vGUQA+FSuxiTKI9TxK+BgOkiwdS/ejUcCD0x5nRGSzqqYE8PRl+gCCfqwq+2O1ORRaNdW4R9q6G8Qy7ULxwDCuwHNzc2S4BMXN+qyHiu76MGVs4qPHoCgJMteD++wMcmh6+FBg0N0YmT05VGtcALZsyeqp+hqvJ0gPLQk79n5gSrECEhEZLcptYeq1QIa79xFmR9LdwEZturSKHHmBIHqQNI3eelxLRYXsf6yg/SEjDkL/vUSaSiuhSjiaxfZOSX4gzf/E6yPvxCzWsab0uYk7TO0IRau+v+HySde2O83qAWPgw0YrhbDTZNvJvqqXlDKndAingFWXYOQGf4R5YLakZ7Cj8yjqOcCz5a+e2Rvgo3QXI1OHOTP/o/5XA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM0PR05MB4643EC9EF6EB609C0DA53078FA900AM0PR05MB4643eurp_" MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR05MB6545 X-OriginalArrivalTime: 14 Oct 2019 05:13:16.0663 (UTC) FILETIME=[1611E870:01D5824E] X-Trailer: 1 X-GBS-PROC: aUf7ASgkyidwn7WQGRYc9up11FYAIozshC4bdEyUtwQ= X-GRP-TAN: IQNE01@5D9859AA7AEB45F7B6E9EA0486682A91 X-iqsuite-process: processed X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT003.eop-EUR03.prod.protection.outlook.com X-Forefront-Antispam-Report: CIP:40.113.82.155; IPV:CAL; CTRY:IE; EFV:NLI; SFV:NSPM; SFS:(10009020)(4636009)(346002)(396003)(39860400002)(136003)(376002)(199004)(189003)(26234003)(86362001)(4326008)(66574012)(55016002)(356004)(33656002)(16586007)(7696005)(7736002)(76176011)(110136005)(81156014)(3846002)(81166006)(6116002)(99286004)(8936002)(9686003)(54896002)(6306002)(6246003)(236005)(229853002)(106002)(8676002)(316002)(30864003)(54906003)(74316002)(76130400001)(70586007)(6506007)(966005)(26826003)(70206006)(14454004)(11346002)(446003)(105004)(336012)(14444005)(53546011)(186003)(102836004)(26005)(486006)(476003)(450100002)(606006)(126002)(2906002)(5660300002)(19627405001)(25786009)(45080400002)(15974865002)(71190400001)(52536014)(44832011)(66066001)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM0PR0502MB3796; H:iqsuite.endress.com; FPR:; SPF:Pass; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-Office365-Filtering-Correlation-Id-Prvs: 81db83bc-3107-4771-ce07-08d7506537d9 X-Forefront-PRVS: 01901B3451 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: zVyIbt05Iy3MU4c5B1bd6HzT3JFCR3sMlLgZ1yXW2/ZHzmdmBmQb4Lry1idYL3IrpSYWnJRdrdQrQ9T2WsUAxQL+uD8sWoLZkTWEuOmzKOenUH14FGVBPcvOumEbI8IyEbibAW08J9Jak45nZpFyzocIxx8EQ7zU1LZ9Ppuxt72sqG6VMTBvY89VXU5ziSNC13CcsTpENIoN6qW0KyPmOAOsJmKybGKV/CNNURPDmnRfBAae+/bk0CvFNLpwaKVVf7u6qYH1SyhRFedlsQz3aEVxYlpX7hgiFf6lyxx830JkKi5MWUpBx1dcNcVjaiQ604isXRj7I52v4JMjviQCu6jhNImyE9Ezw4ILb1X3eXZ2kpG0ANsSQWWdPe47s0P5NIjN+X58YLUWDfy9yErob0KNvr6EhlgpvRInZo5NEwLTKVOdaSoLOe51K5q4PbV5WtOvrFmSIP13Bynx9r1XJA== X-OriginatorOrg: endress.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Oct 2019 05:13:18.2155 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 4b7aff7d-6d6c-4cf2-9d2b-08d750653984 X-MS-Exchange-CrossTenant-Id: 52daf2a9-3b73-4da4-ac6a-3f81adc92b7e X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=52daf2a9-3b73-4da4-ac6a-3f81adc92b7e; Ip=[40.113.82.155]; Helo=[iqsuite.endress.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR0502MB3796 Archived-At: Subject: Re: [6tisch] Clarification on MSF-06 X-BeenThere: 6tisch@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 05:13:29 -0000 --_000_AM0PR05MB4643EC9EF6EB609C0DA53078FA900AM0PR05MB4643eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Tengfei, that sound good to me, we may also add a recommendation for KAPERIOD into= the constants table (figure 2) Mit freundlichen Gr=FC=DFen 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=F6nlich haftender Gesellschafter: Endress+Hauser Administration SE Sitz des pers=F6nlich haftenden Gesellschafters: Maulburg Registergericht: Amtsgericht Freiburg i.Br. HRB 717326 Vorstand: Dr. Andreas Mayr, Dr. Peter Selders Aufsichtsratsvorsitzender: Matthias Altendorf Gem=E4ss der Datenschutzgrundverordnung (EU-DSGVO) sind wir verpflichtet,= Sie zu informieren, wenn wir personenbezogene Daten von Ihnen erheben. Dieser Informationspflicht kommen wir mit folgendem Datenschutzhinweis na= ch. 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 in= form you when collecting your personal data. We comply with this information duty with the following Data Protection S= tatement. Disclaimer: The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or p= rivileged material. Any review, retransmission, dissemination or other us= e of, or taking of any action in reliance upon, this information by perso= ns or entities other than the intended recipient is prohibited. If you re= ceive this in error, please contact the sender and delete the material fr= om any computer. This e-mail does not constitute a contract offer, a cont= ract amendment, or an acceptance of a contract offer unless explicitly an= d conspicuously designated or stated as such. ________________________________ From: Tengfei Chang Sent: Friday, October 11, 2019 18:31 To: Abdussalam Baryun Cc: Christian Hopfner ; draft-ietf-6tisch-= msf@ietf.org ; 6tisch@ietf.org <6tisch@ie= tf.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 mechanis= m 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=3F Tengfei On Fri, Oct 11, 2019 at 5:06 PM Abdussalam Baryun > wrote: Hi Tengfei, I am interested like Christian to see the poll mechanism into this draft.= I don=27t think it is right to refer to RFC7554 (problem statement) whic= h is an informational RFC, while this draft is a proposed standard, I thi= nk it is better to state the mechanism into the use case of minimum sched= uling. 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 > wrote: Hi Christian, Thanks for pointing this issue out! The neighbor polling section is removed at 03 version. Can=27t remember w= hy we removed it. I re-edited this sections to fit the current content of MSF draft. I past= e it below. It will the be last step of boot behavior after it starts sen= ding 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]. I= t 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 > 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 pollin= g which seems to me beeing an important topic in terms of schedule consis= tency. In the latest version I don=27t see a mechanism which explains how a pare= nt keeps its schedule clean after some children silently disappeared (e.g= .. batteries are gone). As per my understanding in such a case the negoti= ated RX cell towards the child remains in the schedule forever right=3F Previously this was handled by neighbor polling. Which required the paren= t 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=3F Mit freundlichen Gr=FC=DFen 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=F6nlich haftender Gesellschafter: Endress+Hauser Administration SE Sitz des pers=F6nlich haftenden Gesellschafters: Maulburg Registergericht: Amtsgericht Freiburg i.Br. HRB 717326 Vorstand: Dr. Peter Selders Aufsichtsratsvorsitzender: Matthias Altendorf ________________________________ Gem=E4ss 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. 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 S= tatement ________________________________ Disclaimer: The information transmitted is intended only for the person or entity to = which it is addressed and may contain confidential, proprietary, and/or p= rivileged material. Any review, retransmission, dissemination or other use of, or t= aking of any action in reliance upon, this information by persons or enti= ties other than the intended recipient is prohibited. If you receive this in e= rror, please contact the sender and delete the material from any computer= . This e-mail does not constitute a contract offer, a contract amendment, o= r an acceptance of a contract offer unless explicitly and conspicuously d= esignated or stated as such. _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch -- =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97 Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tcahng.org =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97 _______________________________________________ 6tisch mailing list 6tisch@ietf.org https://www.ietf.org/mailman/listinfo/6tisch -- =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97 Dr. Tengfei, Chang Postdoctoral Research Engineer, Inria www.tcahng.org =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97 --_000_AM0PR05MB4643EC9EF6EB609C0DA53078FA900AM0PR05MB4643eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
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+C= o. KG | Hauptstrasse 1 | 79689 Maulburg | Germany
Phone: +49 7622 28 1= 883
christian.hopfner@endress.com | www.pcm.endress.com

Endress+Hauser SE+Co. KG
Registergericht: Amtsgeri= cht Freiburg i.Br. HRA 670225
Sitz der Gesellschaft: Maulb= urg
Persönlich haftender Gesellschafter: Endress+Haus= er Administration SE
Sitz des persönlich haftenden Ge= sellschafters: Maulburg
Registergericht: Amtsgericht Freib= urg 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 personenbezog= ene Daten von Ihnen erheben.

Dieser Informationspflicht kommen wir mit folgendem Da= tenschutzhinweis nach.

Endress+Hauser SE+Co. KG
Register Court: Local Cou= rt of Freiburg i.Br. HRA 670225
Registered Office: Maulbur= g
General Partner: Endress+Hauser Administration SE=
Registered Office of General Partner: Maulburg
Re= gister 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 <= a rel=3D=22noopener=22 target=3D=22_blank=22 href=3D=22https://www.de.end= ress.com/en/endress-hauser-website-cookies/en-data-protection-notice-de= =22 title=3D=22Data Protection Statement=22>Data Protection Statement=

 

Discla= imer:

The informati= on transmitted is intended only for the person or entity to which it is a= ddressed and may contain confidential, proprietary, and/or privileged
= material. Any review, retransmission, dissemination or other use of, or t= aking of any action in reliance upon, this information by persons or enti= ties
other than the intended recipient is prohibited. If you receive t= his 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 co= nspicuously designated or stated as such.

 

From: Tengfei Chang <tengfei.chang@gmail.com>
Sent: Friday, October 11, 2019 18:31
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
Cc: Christian Hopfner <christian.hopfner@endress.com>; draft= -ietf-6tisch-msf@ietf.org <draft-ietf-6tisch-msf@ietf.org>; 6tisch@= ietf.org <6tisch@ietf.org>
Subject: Re: [6tisch] Clarification on MSF-06
 
Thanks Abdussalam for the comments, I updated t= he text as following:  

   The node S=
HOULD send some form of keep-alive messages to all its
   neighbors it has negotiated cell with. The node sends a keep-
   alive mess=
age to the neighbor if no frames is received from that 
   neighbor w=
ithin 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 kee=
p-alive message to a child fails at the link layer (i.e. 
   the maximu=
m number of link-layer retries is reached), the node 
   SHOULD dec=
lare the child as unreachable. This can happen for example 
   when the c=
hild node is switched off.

   When a nei=
ghbor 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=3F



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 d= raft. I don=27t 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 n= ot 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=27t remem= ber 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 start= s 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 [RFC75=
54].  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 chi=
ld 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.
<=
/pre>



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> wrot= e:
Hi authors,

I may raise a clarification question before issuing WGLC for this draft.<= /div>

In the past there was a section in the draft dealing with neighbor pollin= g which seems to me beeing an important topic in terms of schedule consis= tency.

In the latest version I don=27t see a mechanism which explains how a pare= nt keeps its schedule clean after some children silently disappeared (e.g= .. batteries are gone). As per my understanding in such a case the negoti= ated RX cell towards the child remains in the schedule forever right=3F

Previously this was handled by neighbor polling. Which required the paren= t 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=3F


Mit freundlichen Gr=FC=DFen I Best regards

Christian Hopfner

Developer | TPI F&E Plattform Informatik
Endress+Hauser SE+Co. KG | Hauptstrasse 1 | 79689 Maulburg | Germ= any
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=F6nlich haftender Gesellschafter: Endress+Hauser Administrat= ion SE
Sitz des pers=F6nlich haftenden Gesellschafters: Maulburg
Registergericht: Amtsgericht Freiburg i.Br. HRB 717326
Vorstand: Dr. Peter Selders
Aufsichtsratsvorsitzender: Matthias Altendorf

Gem=E4ss der Datenschutzgrundverordnung (EU-DSGVO) sind wir verpflic= htet, 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. 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 addr= essed and may contain confidential, proprietary, and/or privileged
material. Any review, retransmission, dissemination or other use of, or t= aking of any action in reliance upon, this information by persons or enti= ties
other than the intended recipient is prohibited. If you receive this in e= rror, please contact the sender and delete the material from any computer= .
This e-mail does not constitute a contract offer, a contract amendment, o= r an acceptance of a contract offer unless explicitly and conspicuously d= esignated or stated as such.

 

=0D=0A
_______________________________________________
6tisch mailing list
6tisch@ietf.= org
https://www.ietf.org/mailman/listinfo/6tis= ch


--
=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97

Dr. Tengfei, Chang
Postdoctoral Research Engineer, = Inria

=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97
_______________________________________________
6tisch mailing list
6tisch@ietf.= org
https://www.ietf.org/mailman/listinfo/6tisch


--
=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97

Dr. Tengfei, Chang
Postdoctoral Research Engineer, = Inria

=97=97=97=97=97=97= =97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97=97= =97=97=97=97=97=97=97=97
--_000_AM0PR05MB4643EC9EF6EB609C0DA53078FA900AM0PR05MB4643eurp_--