Re: [Roll] WRT adopting draft-rahul-roll-rpl-observations as WG document

Hello all

I agree with pretty much everything that Michael suggested but the removal of storing node. Please remember that RPL is a routing protocol and that it can be used in various environments.

Storing mode has an ancestor that did well in Manet type of networks. It can be used in home and in smartgrid networking where memory is not necessarily a constraint. It is used between “normal” routers to bootstrap a fabric in ANIMA. Even if it implies states, it is still a lot less than for a classical IGP.

We cannot even consider making it historic. It just has an applicability that does not include large dodags of memory constrained devices.

I agree though with the spirit in Michael’s mail whereby route projection provides an hybridation of a non storing infrastructure with particular storing mode projected routes that make storing applicable to memory constrained nodes, and that we need a new spec to advertise neighborhood (peers and delta Rank) and capabilities (eg amount or storing mode routes that can be held) to the root.

Cheers

Pascal

Le 31 juil. 2018 à 09:02, Peter van der Stok <stokcons@bbhmail.nl<mailto:stokcons@bbhmail.nl>> a écrit :

Hi Michael,

thanks for a drastic point of view concerning 6550bis with removal of storing mode.What will removing SM mean for existing installations?.
Removing SM means at least a 6550bis RFC and no update documents.

Personally I am in favor of RPL 1.2 such that legacy can be managed.

BTW are there volunteers for the writing?

Peter

Michael Richardson schreef op 2018-07-30 21:59:

{been watching the youtube video of the ROLL session}

1) I think that the work in roll-rpl-observations is really important.
   -> that's why we should adopt the document so that it can have priority
      over other non-WG documents in the agenda.
   As our AD pointed out, we don't have to publish it.

2) Starting rfc6550bis or rfc6550updates is very important!!!
   We have some options on how to do this, one of which is to publish a bunch
   of very small updates.  That's probably the lowest latency way, but it
   does cause more IESG and RFC-EDITOR work.
   So I think that we will be forced to publish a ~60-page update document
   that collects all sorts of things.

3) I'd like to move to obsolete (mark as "historical") storing mode in favour
   of dao-projection mode.  I think that this is mostly orthogonal to the updates work, but
   if we agree that we are going in that direction, there might be updates
   that we don't need to do.

4) We need a new node capabilities mechanism.  It could be quite
   controversial as there are a lot of design choices here.  maybe we should
   probably encourage implementations, and then experimental RFCs.

_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org<mailto:Roll@ietf.org>
https://www.ietf.org/mailman/listinfo/roll