Re: [Roll] Topics and drafts within Roll charter

Hello ROLL,

Last week we had uploaded an ID "
https://datatracker.ietf.org/doc/draft-rahul-roll-rpl-observations/" inline
to what was promised in IETF100. (Strange the new ID notification was not
sent out to ROLL ML (?),, but the ID is actually uploaded!).
The draft is informational and describes issues related to existing
handling in RPL which either seems incomplete, ambiguous and may need
attention. It is possible that some of the issues already have some
existing solution which we would like to understand.
Please note that all the issues mentioned in the draft are related to
existing 6550 handling. Also many of those issues are pertaining to storing
MOP and we wanted to put out our understanding out there so as to get any
feedback from other implementers.

Thanks,
Rahul

On 8 February 2018 at 19:10, Pascal Thubert (pthubert) <pthubert@cisco.com>
wrote:

> Hello Peter:
>
> I encourage the WG to consider your list carefully and respond.
>
> My personal priorities would be:
>
> 1) Item 4. This deals with actual field problems, and is a preerq for the
> Join Process that 6TiSCH is working on. Michael has a draft and I'm willing
> to contribute together with Charlie from Cisco.
> 2) item 2+5, seem to be the same to me. This is a rather easy work once
> rfc6775-update is passed and I'm willing to start/contribute
>
> Take care,
>
> Pascal
>
> -----Original Message-----
> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of peter van der Stok
> Sent: lundi 9 octobre 2017 09:47
> To: Roll <roll@ietf.org>
> Subject: [Roll] Topics and drafts within Roll charter
>
> 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
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>