Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)

Alvaro Retana <> Tue, 20 April 2021 15:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7CA893A27EA; Tue, 20 Apr 2021 08:23:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ew9m4XYi0Wff; Tue, 20 Apr 2021 08:23:28 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 52D123A27E7; Tue, 20 Apr 2021 08:23:28 -0700 (PDT)
Received: by with SMTP id bx20so44442239edb.12; Tue, 20 Apr 2021 08:23:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=EDbkQevjGbJzAaqgNuAqpXrhPH4MemCy03ZoM9/5+ZQ=; b=kEF9slFyUeGQv24IS34I81YuvX9GO97Ka4omy/Y4GoR+T59ChDQvsOTj07D1QV8Fex BVaW81nmxYDr6TfC4UdH96lNTDyE+Ke79l0fXIfPCsz3PDDvTY/IFK3IUuwtVdim/fcY DklB0SCAAWJeciKfbztd1nRvFGhKwVbfu0xZoTgvQCPyi20AXAg8JiLQrsDRxLzf0tRG U59b0DYrUQwl9DxUGPuGN0uxGMr4lz0xPSCo34IDtHZ03oY752WtmbPdgEl0Gy92UoLg ta14DgdYpElKoFjzFVTAYhF5WMOjhcXE3ttfFrKY/sBIU1GFdfR9LGv5b9c+vBdHBfHu k4nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=EDbkQevjGbJzAaqgNuAqpXrhPH4MemCy03ZoM9/5+ZQ=; b=VEDhx5DJNTZ0C4hkIPKrnLQ+6Aba1Fzg5Ad/YhTSuv0EI7JEHZ74XAfnFEy2K+eVsS 9vOXzhNTZ3tU9iTQ7VsaaI+HFvOxRCSPAvcywF0z8Xwj/R2na7ff7ewnapWsIOhbPwWN TSZn0NKNJq6ZV6U97knGWnBkbDl8gt70TjELP5nrTRFryXDZyJyOjpasc4m86faOzqKR VS9bUdnlLGAkUUA/24Vb6VDhCozr32AnvBs0qnpnb5uyO14pFwP01gWSEHTPXjJOEKsL UC3IGYYN3G5ZdUcf3f4JNdJLzbgBAH1lstZcd7DlwOUcfDRMOllyDNj+lAJ72vqOoCTO 6JDA==
X-Gm-Message-State: AOAM533t3oXf6kaim45eBRPdaJEdvu5UsAevHfwKuPLTsBS31ov0g2Ag 5TyMYuutXftvDw1ghjyaUm+IwRWOzLpg/+vAdfWdLjnpqVl5bA==
X-Google-Smtp-Source: ABdhPJwmwFHaDoVhfG8tWQ06oP6pprxT627QCjwctTLhhZ3D/VKHdRSoIwOzhf0MxrZRWFj4fwIn/zSN81Zr2lpRZak=
X-Received: by 2002:aa7:c1c9:: with SMTP id d9mr32686027edp.155.1618932205958; Tue, 20 Apr 2021 08:23:25 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Tue, 20 Apr 2021 08:23:25 -0700
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Date: Tue, 20 Apr 2021 08:23:25 -0700
Message-ID: <>
To: John Scudder <>
Cc: "" <>, "" <>, "" <>, The IESG <>, Ines Robles <>
Content-Type: multipart/alternative; boundary="0000000000000d396d05c0690729"
Archived-At: <>
Subject: Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)
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: Tue, 20 Apr 2021 15:23:34 -0000

ACK. (For the record)

On April 20, 2021 at 11:09:05 AM, John Scudder ( wrote:

Hi Alvaro,

I have one partial reply below, but I think we might benefit from a short
phone call. I’ll unicast you some times that would work for me.

On Apr 20, 2021, at 10:55 AM, Alvaro Retana <> wrote:


Further, it’s not stated anywhere whether AODV-RPL is intended to stand
alone as its own routing protocol, or to be viewed as an extension of RPL.
In the former case, it seems the document is lacking details that are
in RFC 6550. I’m assuming the latter is the case, but a clear statement to
that effect seems indicated.

AODV-RPL uses a new Mode of Operation (MOP) dedicated to the discovery
of p2p routes.  This means that it runs in a separate instance from
the "base RPL".  Also, it can be used whether or not a "base RPL"
instance is used.  IOW, it is RPL using MOP 5.

This doesn’t really clear up my concern, which I can rephrase this way: I’m
pretty sure AODV-RPL, standing alone, isn’t an implementable specification.
If it assumes that all the protocol machinery of RFC 6550 is present, then
I’m willing to accept on faith that the gaps are filled that way, but this
needs to be said. If it * doesn’t* assume that all of RFC 6550 is present,
then I think it should call out by reference what the required parts are.

I haven’t tried to go through the document and say “this isn’t
implementable because you left out this, and that, and so on” because so
far my guess is it’s assumed that the entire base of RFC 6550 is available,
so it wouldn’t be a good use of anyone’s time to produce that kind of