Subject: [Roll] AODV-RPL currently is stable: discussion requested about two possible updates

From: Charlie Perkins <[email-masked]>
Date: Mon, 17 Jul 2017 14:37:49 -0700

Hello folks,

The AODV-RPL draft has been pretty stable.  There have not been any 
modifications needed that were important enough to motivate submission 
of a revised draft.

We had a suggestion for supporting non-storing mode in AODV-RPL. Prior 
to our presentation on Tuesday, I would like to discuss whether or not 
there is support for this improvements.

The mechanism for supporting non-storing mode is straightforward -- 
basically it is analogous to what is already specified in RPL. Using 
AODV-RPL in non-storing mode would no longer provide the benefit of 
small control messages, because the source routes would have to be 
stored in RREQ and RREP.  However, for the class of devices that cannot 
store routes, AODV-RPL would still provide a beneficial way to establish 
peer-to-peer routes.  If it is desired to have both storing mode and 
non-storing mode in the same draft, I reckon that the AODV-RPL author 
team could have another draft ready for that purpose in short order.  If 
it is preferable to have another draft to support non-storing mode, then 
that is also a possibility, and likewise the new draft could be done soon.

Comments will be appreciated.

Regards,
Charlie P.

---

From: Abdussalam Baryun <[email-masked]>
Date: Tue, 18 Jul 2017 17:03:48 +0200

Hi Charlie,

On Mon, Jul 17, 2017 at 11:37 PM, Charlie Perkins <
[email-masked]> wrote:

> modifications needed that were important enough to motivate submission of a
> revised draft.
>
> We had a suggestion for supporting non-storing mode in AODV-RPL. Prior to
> our presentation on Tuesday, I would like to discuss whether or not there
> is support for this improvements.
>
Yes, however, I prefer in separate draft. I support this draft is for only
store-mode.

> AODV-RPL in non-storing mode would no longer provide the benefit of small
> control messages, because the source routes would have to be stored in RREQ
> and RREP.

We may have a mix situation which can be usually, and we may have a way to
optimize the message overhead.

However, for the class of devices that cannot store routes, AODV-RPL would
> still provide a beneficial way to establish peer-to-peer routes.

I think this is the worst case for ROLL with all devices not-storing

> If it is desired to have both storing mode and non-storing mode in the
> same draft, I reckon that the AODV-RPL author team could have another draft
> ready for that purpose in short order.  If it is preferable to have another
> draft to support non-storing mode, then that is also a possibility, and
> likewise the new draft could be done soon.
>

I support another draft for the both non-store mode and mix. So one draft
for store-mode and another draft for two modes (on-store and mix).

> Comments will be appreciated.

will try to review, thanks

>
> Regards,
> Charlie P.
>
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>