Re: [6tisch] Question/Comment on draft-chang-6tisch-6top-msf

Tengfei Chang <tengfei.chang@inria.fr> Wed, 15 November 2017 08:31 UTC

Return-Path: <tengfei.chang@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 B6110129562 for <6tisch@ietfa.amsl.com>; Wed, 15 Nov 2017 00:31:07 -0800 (PST)
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, 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 zR5zIlv-ZvUj for <6tisch@ietfa.amsl.com>; Wed, 15 Nov 2017 00:31:05 -0800 (PST)
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 9707212953F for <6tisch@ietf.org>; Wed, 15 Nov 2017 00:31:04 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.44,398,1505772000"; d="scan'208,217";a="244675602"
Received: from mail-pf0-f181.google.com ([209.85.192.181]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 15 Nov 2017 09:31:01 +0100
Received: by mail-pf0-f181.google.com with SMTP id d28so16519352pfe.2 for <6tisch@ietf.org>; Wed, 15 Nov 2017 00:31:01 -0800 (PST)
X-Gm-Message-State: AJaThX7XGEcFiSpA0KJnE3+RCnCpvnVQPionYKinm/0AAKQJg6d4pRcj /Jyv0wwUfLX7gw5nX5aZdoHUQ68p5KdMqyUGRZo=
X-Google-Smtp-Source: AGs4zMZSiN/QfIkt3d8dN30LnyWoTdF9qTZ73yeABZanJscO23r4UFcXQ2C/nJkSUHvAbquKih0Zil8yqxP+DbNXHcI=
X-Received: by 10.159.214.130 with SMTP id n2mr15373521plp.13.1510734660437; Wed, 15 Nov 2017 00:31:00 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.143.226 with HTTP; Wed, 15 Nov 2017 00:30:59 -0800 (PST)
In-Reply-To: <CY1PR12MB0475F2E8A867263AB926A6C59D280@CY1PR12MB0475.namprd12.prod.outlook.com>
References: <CY1PR12MB0475F2E8A867263AB926A6C59D280@CY1PR12MB0475.namprd12.prod.outlook.com>
From: Tengfei Chang <tengfei.chang@inria.fr>
Date: Wed, 15 Nov 2017 09:30:59 +0100
X-Gmail-Original-Message-ID: <CAAdgstS8zscASk5tnU3bvDRmDeW-+hQB5ADgbVL95eiycJNLbA@mail.gmail.com>
Message-ID: <CAAdgstS8zscASk5tnU3bvDRmDeW-+hQB5ADgbVL95eiycJNLbA@mail.gmail.com>
To: john rubis <john.rubis@hotmail.com>
Cc: "6tisch@ietf.org" <6tisch@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c1e613cc90dc3055e0152b5"
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/TXHCtqVqB_iz97xT4cJ8QmVC37Y>
Subject: Re: [6tisch] Question/Comment on draft-chang-6tisch-6top-msf
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.22
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, 15 Nov 2017 08:31:08 -0000

Hi John,

Before switching parent, the node still can keep synchronized to it's old
parent through the TXRXSHARED cell. That cell is only shared between the
node and its parent.
The keepalive on TXRXSHARED cell should be able to keep the node
synchronized.

Tengfei

On Wed, Nov 15, 2017 at 12:34 AM, john rubis <john.rubis@hotmail.com> wrote:

> I think the MSF draft states/infers this, but I wanted to verify.
>
>
>
> In the case a node has a valid preferred parent and wishes to switch to a
> new one then:
>
>
>
> Dedicated link(s) to its current parent initially remain in place. This
> way, while dedicated link(s) are being setup with the new, I’ll call it the
> ‘Candidate Parent’, the node and its possible children remain connected and
> reachable. During this period, the node also maintains its rank and time
> synchronization to the current parent, not the candidate parent. Once
> dedicated link(s) are established to the new parent, the node updates its
> rank and time syncs to the new parent. All up stream packets now are routed
> through the new parent and link(s) to the old parent are cleared.
>
>
>
> It has been observed in our system,  that the links to the new parent can
> take some time to setup over the single minimal cell. Especially in dense
> networks. This may cause a node to desync or loose connectivity for an
> extended period of time.
>
>
>
> Thank  you,
>
>
>
> John Rubis
>
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>


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