[Roll] Topics and drafts within Roll charter

peter van der Stok <stokcons@xs4all.nl> Mon, 09 October 2017 07:47 UTC

Return-Path: <stokcons@xs4all.nl>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A8B2134BB0 for <roll@ietfa.amsl.com>; Mon, 9 Oct 2017 00:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.079
X-Spam-Level:
X-Spam-Status: No, score=0.079 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 W7nykovMcaIE for <roll@ietfa.amsl.com>; Mon, 9 Oct 2017 00:46:57 -0700 (PDT)
Received: from lb1-smtp-cloud9.xs4all.net (lb1-smtp-cloud9.xs4all.net [194.109.24.22]) (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 59772134B9C for <roll@ietf.org>; Mon, 9 Oct 2017 00:46:57 -0700 (PDT)
Received: from webmail.xs4all.nl ([IPv6:2001:888:0:22:194:109:20:204]) by smtp-cloud9.xs4all.net with ESMTPA id 1Sm6enbhsnIXb1Sm6eaKeO; Mon, 09 Oct 2017 09:46:55 +0200
Received: from AMontpellier-654-1-191-159.w92-145.abo.wanadoo.fr ([92.145.170.159]) by webmail.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 09 Oct 2017 09:46:54 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Mon, 09 Oct 2017 09:46:54 +0200
From: peter van der Stok <stokcons@xs4all.nl>
To: Roll <roll@ietf.org>
Organization: vanderstok consultancy
Reply-To: consultancy@vanderstok.org
Mail-Reply-To: consultancy@vanderstok.org
Message-ID: <76c7ca90006983de7a781bc8abad534c@xs4all.nl>
X-Sender: stokcons@xs4all.nl
User-Agent: XS4ALL Webmail
X-CMAE-Envelope: MS4wfEwxhxkXjJpVhzC3ErQyTgX3ktuYZah95Z2wDbJj5C4sJoQhD91kSBtlwQSU4PQUXEn9fCZHwUX7FV8bamNHXDhSQQiA7g3f/08KWgiRHsgOiivOlpoq JQuSCxYaHDA6+Tp/dmOHX6qe3A/yNvF406PLJ8RShtTMlZK7mP0e5CiG6MWFhyzqfLQ7LMeZZ8nyeA3SR3sYKJ350R8YwQmlbXA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/gWM4PV-rs7yfsl2OsY-8b7QRFGY>
Subject: [Roll] Topics and drafts within Roll charter
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Oct 2017 07:47:00 -0000

Hi Roll,

In a discussion with Rahul and Pascal, it transpires that there are 
still many topics to address that fit within our charter. The 
proliferation of topics worries us a bit. We have only a limited number 
of active authors and some topics also seem to be competing. The result 
of this situation might be that we have an overflowing work agenda. 
Therefore, we need to find additional people to work on those topics; or 
reduce the number of topics.
It is our suggestion that we discuss these topics, find dedicated 
authors, and prioritize them  after some debate on the M-L.
Also we should like to remove the competitive subjects by joining them 
into one draft.

Your comments please.

Ines + Peter

------------------------ List of topics 
------------------------------------------

1 Route invalidation as a standalone topics The topic is mentioned in 
several drafts, but we need to come to one general approach.

2.A draft that allows a ND only device to connect, be
reachable and move in a RPL network.

3. Not all implementers are aware of the design issues of storing mode 
of
RPL vs non-storing. Both of the modes have issues with their design. 
Some
issues are getting sorted out by drafts such as dao-projection and 
no-path
DAO optimization. But still considerable design issues need to be 
handled. To name few:
a. handling parent switching optimally in storing MOP. Currently with
Storing MOP it would lead to DIO/DAO storm in the sub-path from the 
child
node who switches the parent. This is handled well in NS MOP 
(Non-storing
MOP).
b. how to handle node(6ln, 6lr, lbr) reboot scenario? In some cases it 
is
trivial, but in most cases it is not (considering dependence on several
state variables such as DTSN across reboots)! Also for practical point 
of
view, need to consider that writing to flash/NV-memory is not a good 
option in
embedded devices and should be avoided as far as possible.
c. Problems of current DAO-ACK in storing MOP. There was a discussion on
ML long time back, but there is no draft in the space.
d. problem of bulging IPv6 headers in NS MOP. Most part of this will be
taken care of by SRH compression and dao-projection.

4. Confusion between DAG selection (for joining and jumping) vs. parent 
selection (for re-parenting within a DODAG). 6TiSCH has isolated the 
need for a join preference which is different from the Rank used in 
parent selection. The resulting Rank may be used in the join preference, 
but not only. The size of the DODAG, the number of children of that 
parent, etc... may influence. There is basically the need for a new sort 
of objective function, this time in order to select a DODAG to join.

5. Integration with 6LoWPAN. We need to write that draft that 
standardizes the procedures suggested in the 6TiSCH architecture and 
shows a non RPL aware joining a DODAG and moving inside. With the new 
6LoWPAN ND and the NP DAO, we now have all the tools to do it. Unless we 
consider that the reference is the 6TiSCH architecture in which case we 
complete the design there.

6. Exposing (some of) the structure of the Mesh to the root to enable 
the DAO projection for transversal routes and in storing mode in 
general.

7. Using bitmaps for multicast and unicast routing, used in
  7a routing tables, or 7b in header for source routing

8. Guidance to implementers who are relatively new to
RPL are not aware of many design considerations and there should be a 
doc which talks about it. Similar work is started in
https://tools.ietf.org/html/draft-clausen-lln-rpl-experiences-09 ... but
it does not list all the issues imo.

9. What to do with expired YANG model drafts

10. What else do you think that we should consider?



-- 
Peter van der Stok
vanderstok consultancy
mailto: consultancy@vanderstok.org
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248