Re: [Roll] AD Review of draft-ietf-roll-aodv-rpl-07

[Peter van der Stok <[e-mail]>]

Hi Alvaro,

concerning replacement of RFC6997:

I don't see anyone deploying both specifications in one installation.
As you remarked RFC6997 was recommended in RFC7733 especially om my
request.
However, things have advanced since, and more options exist to specify
short routes between neighbouring nodes without passing through the
root. Consequently, the need for RFC6997 has diminished.
Moreover, I find it difficult to answer whether aodv-rpl can replace
RFC6997 without any efficiency loss.
An answer to the last question may be given directly by aodv-rpl authors
based on experience?

Cheerio,

Peter

Ines Robles schreef op 2019-08-07 14:09:

> Thank you Alvaro for the review,
> 
> The tickets #194, #195, #196, #197, #198  were created to address the
> issues [1 [1]].
> 
> Related to ticket #195 (Document Status), we are going to discuss it into
> the ML.
> 
> Best regards,
> 
> Ines.
> 
> [1] https://trac.ietf.org/trac/roll/report/2
> 
> On Thu, Aug 1, 2019 at 5:54 PM Alvaro Retana <[e-mail]> wrote:
> 
>> Dear authors:
>> 
>> I just finished reading this document.  I am excited about the new
>> functionality, but I have several significant issues/questions about the
>> document, and a lot of comments (in-line below).
>> 
>> (1) What is AODV-RPL?
>> 
>> Reading the document, my impression of AODV-RPL varies between an
>> enhancement to RPL for Reactive Route Discovery (*maybe* in addition to the
>> usual proactive routing), to ships-in-the-night reactive-only protocol that
>> uses some of the RPL concepts (but not exactly sure which ones).  The
>> different MOP indicates that it is different from "base" RPL (rfc6550), but
>> it is not clear what the assumptions are...and which parts are "inherited"
>> from the "base" and which ones are not used.
>> 
>> Another way to ask the same question is: What is the relationship of
>> AODV-RPL to RPL?  What mechanisms are not applicable with the new MOP?  Is
>> it expected that an instance of RPL will also be running in the network?
>> 
>> Please be clear early in the document.  To quote Charlie: "AODV-RPL is a
>> variation on RPL" [1 [1]].  What remains, what changes, etc..
>> 
>> (2) Document Status (for the Chairs/Shepherd)
>> 
>> I didn't find a specific discussion in the archive about the status of
>> this document.  Did one take place?  At this point I am mostly curious
>> given the similarities with rfc6997 (Experimental) and the fact that
>> "Future Work" is discussed -- not typical in a Standards Track document.
>> IOW, why is this document intended to be a Proposed Standard and not
>> Experimental?
>> 
>> (3) Replacing rfc6997??
>> 
>> This document uses some of the features from rfc6997 (see some comments
>> about that in-line), which is fine.  The Introduction falls just short of
>> saying that this work replaces rfc6997.  Should it be considered a
>> replacement?  I ask mostly in the context of rfc7733 (RPL in Home and
>> Building) which mandates (MUST) the use of rfc6997.  Should rfc7733 be
>> Updated?  [I'm just asking the question for it to be considered...I am not
>> sure of deployments which conform to rfc7733 or rfc6997...or the impact
>> this would have.]
>> 
>> (4) Link checks
>> 
>> The operation of AODV-RPL depend on link checks (§6.2.1/§6.4) to determine
>> symmetry and whether it can "fulfill the requirements".  But these checks
>> are not explained or defined anywhere (are they?) beyond an *example* in
>> the Appendix.  I think defining the checks is a critical part of the
>> specification of the mechanism...specially for a Standards Track protocol
 

Links:
------
[1] https://trac.ietf.org/trac/roll/report/2