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

Peter van der Stok <> Mon, 12 August 2019 21:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A3E68120090; Mon, 12 Aug 2019 14:27:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IfAw8H7TzPaM; Mon, 12 Aug 2019 14:26:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A56E812131B; Mon, 12 Aug 2019 00:08:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EEB4E182CF666; Mon, 12 Aug 2019 07:08:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h= mime-version:content-type:date:from:to:cc:subject:reply-to :in-reply-to:references:message-id; s=key; bh=7xD6Jn4hPrRp5YvSYf o5eX4lTGHEI7H5JJR68ubxoeY=; b=X8HW9GGlmlEMSnmeV4Zvh8WB3I9NBsLoHm Gl3M/nsVDIeknifsKa/h7C2bM9XZnt0DehJqBWQjn4ZmGcjsQC69l3vTjH8ihn6O +Q/s1YP87BoGrH4DpW8rG1X8e16YwDj1Zfr+8N1121L05FApDYrbz1KjY3P5q2Ft igm1/8xj0=
X-Session-Marker: 73746F6B636F6E73406262686D61696C2E6E6C
X-Spam-Summary: 2, 0, 0, , d41d8cd98f00b204,, :::::::::, RULES_HIT:1:41:72:152:355:379:582:599:800:960:962:967:969:973:983:988:989:1152:1189:1208:1212:1221:1260:1313:1314:1345:1431:1436:1437:1516:1517:1518:1544:1575:1588:1589:1592:1594:1605:1711:1730:1776:1792:2068:2069:2194:2198:2199:2200:2525:2528:2553:2559:2567:2570:2682:2685:2693:2703:2859:2895:2902:2911:2933:2937:2939:2942:2945:2947:2951:2954:3022:3421:3622:3865:3866:3867:3868:3870:3871:3872:3873:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4250:4321:4361:4425:5007:6117:6119:6261:7514:7875:7903:7974:8603:9025:9108:9177:10004:11658:12740:13137:13139:13149:13150:13230:13231, 0,, CacheIP:none, Bayesian:0.5, 0.5, 0.5, Netcheck:none, DomainCache:0, MSF:not bulk, SPF:fn, MSBL:0, DNSBL:neutral, Custom_rules:0:0:0, LFtime:25, LUA_SUMMARY:none
X-HE-Tag: bells73_6b5170156d233
X-Filterd-Recvd-Size: 10277
Received: from (imap-ext []) (Authenticated sender: by (Postfix) with ESMTPA; Mon, 12 Aug 2019 07:08:57 +0000 (UTC)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_4397e3caca35bde3f399315a4e72c1f0"
Date: Mon, 12 Aug 2019 09:08:56 +0200
From: Peter van der Stok <>
To: Ines Robles <>
Cc: Alvaro Retana <>,, roll <>, roll-chairs <>
Organization: vanderstok consultancy
In-Reply-To: <>
References: <> <>
Message-ID: <>
User-Agent: Roundcube Webmail/1.2.7
X-Originating-IP: []
Archived-At: <>
Subject: Re: [Roll] AD Review of draft-ietf-roll-aodv-rpl-07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Aug 2019 21:27:02 -0000

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
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?



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]
> On Thu, Aug 1, 2019 at 5:54 PM Alvaro Retana <> 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