Re: [6tisch] draft-ietf-6tisch-msf-06 is published

Thomas Watteyne <thomas.watteyne@inria.fr> Wed, 14 August 2019 14:45 UTC

Return-Path: <thomas.watteyne@inria.fr>
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 C405D120848 for <6tisch@ietfa.amsl.com>; Wed, 14 Aug 2019 07:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 3BPjGFl19I79 for <6tisch@ietfa.amsl.com>; Wed, 14 Aug 2019 07:45:15 -0700 (PDT)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC44A120043 for <6tisch@ietf.org>; Wed, 14 Aug 2019 07:45:14 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.64,385,1559512800"; d="scan'208,217";a="316386978"
X-MGA-submission: MDEXhWF88DZeR87gFegpVqV5l+LRFE1p92IM1WdVBYybOOyxIPNLVahi78apqdg9l91M3pScDHfoRDBMXjfZDDCmSd9S9LUgEZNWu8GksQMekdibe36M9SRstqllVyPxRuT/G/gJuyWXCgf3LonPz7RYKp0+xTbLLabUxIJHBXj2yQ==
Received: from zcs-store9.inria.fr ([128.93.142.36]) by mail3-relais-sop.national.inria.fr with ESMTP; 14 Aug 2019 16:45:12 +0200
Date: Wed, 14 Aug 2019 16:45:12 +0200
From: Thomas Watteyne <thomas.watteyne@inria.fr>
To: tengfei chang <tengfei.chang@gmail.com>
Cc: 6tisch <6tisch@ietf.org>
Message-ID: <1317284713.9387735.1565793912823.JavaMail.zimbra@inria.fr>
In-Reply-To: <CAAdgstQSMdKfHo8uWTD7E8DfVdKtzcYUmxzP7kmBUaRJSABMTQ@mail.gmail.com>
References: <CAAdgstQSMdKfHo8uWTD7E8DfVdKtzcYUmxzP7kmBUaRJSABMTQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_0ed9297d-4cdc-48f5-9bee-236f96813a90"
X-Originating-IP: [108.231.76.176]
X-Mailer: Zimbra 8.7.11_GA_3800 (ZimbraWebClient - GC76 (Win)/8.7.11_GA_3800)
Thread-Topic: draft-ietf-6tisch-msf-06 is published
Thread-Index: 09QtSriVmXpbmAkQO2t1Gb8SOUif+g==
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/W7uiFuj68DvAmNO6uMP63DDVb4k>
Subject: Re: [6tisch] draft-ietf-6tisch-msf-06 is published
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: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Aug 2019 14:45:18 -0000

Tengfei, 

Trying to understand you point about " handle Sixtop ADD Response with return code SUCCESS but 0 cells in cellList " 

If the response code is SUCCESS, IMO that means option 1. if option 2 is happening (I assume you mean "there is no memory for allocating more cells"), I would expect another return code, no? 

THomas 

________________________________________ 

Thomas Watteyne, PhD 
Sr Research Scientist & Innovator, Inria 
Sr Networking Design Eng, Analog Devices 
Founder & Advisor, Wattson Elements/Falco 
Founder & co-lead, UC Berkeley OpenWSN 
Co-chair, IETF 6TiSCH 

www.thomaswatteyne.com 
________________________________________ 

> De: "tengfei chang" <tengfei.chang@gmail.com>
> À: "6tisch" <6tisch@ietf.org>
> Envoyé: Lundi 12 Août 2019 08:52:37
> Objet: [6tisch] draft-ietf-6tisch-msf-06 is published

> Dear all,
> The draft-ietf-6tisch-msf-06 is just published, it mainly resolved what we
> discussed during the IETF meeting.

> - add rules for celllist
> - update the downstream cell adaptation strategy

> Right now, there is one issue remained to be resolved and I am not sure what is
> the right solution. So I need suggestions and feedback from you:

> - handle Sixtop ADD Response with return code SUCCESS but 0 cells in cellList

> There are two possible reason for this situation
> 1. the proposed celllist doesn't meet the requirement from neighbor side
> 2. there is schedule memory for adding more cells.

> For the 1st reason, the node may try to send another 6P request later.
> For the 2nd reason, the node may switch to another parent but it's layer
> violated.

> Any solutions for this case?

> Tengfei

> --
> Chang Tengfei,
> Postdoctoral Research Engineer , Inria

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