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

John Scudder <jgs@juniper.net> Wed, 21 April 2021 20:02 UTC

Return-Path: <jgs@juniper.net>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3DE03A34A7; Wed, 21 Apr 2021 13:02:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=e9W94kaV; dkim=pass (1024-bit key) header.d=juniper.net header.b=JlqLkXi3
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8BOjcVsVMab; Wed, 21 Apr 2021 13:02:00 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 254C63A12B7; Wed, 21 Apr 2021 13:01:59 -0700 (PDT)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 13LJoHmp030965; Wed, 21 Apr 2021 13:01:58 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=E/JoAKCD7+jIqOEqN6mETMoocRjQve82mJB8B4ow5tU=; b=e9W94kaV2w8QV/H1hkb3HNul4naxjN/pbRWL1lheCLgtZTZWaGOHvbWM9Fr3JbuPV2RV p2C0p8G1gQnRXc9A/8/OJktR6vDdTqfCFAMCYSVqlyQGY8/zqs/dX5N0nAouM9jvT9EO 5XQLSv8/DC5/rMhW/sduqi9T57KI/tKjJUFnrmnOV0PzPuTUNBfIpVBjIAh9qEJvvMUJ G/UWyVXOtQeO8Pe33i/+9ILundoIQ1SfztW68o41skesfLTCre89Ic5qzuJkJlyQZL95 QaLFDU+PaM+c0wMUy+Cw+VOd7Lqt6r33JXjatFXkDndOdgjtXuLrmEJ5lYqayQzYLFcy Ew==
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2173.outbound.protection.outlook.com [104.47.59.173]) by mx0a-00273201.pphosted.com with ESMTP id 382ac4hvad-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Apr 2021 13:01:58 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R45scHM2qQuL0Rg36sgEK5DKEgTmD5S92yg0DtNBMZkDk3kUOT5/5AIoip4NHQCwudQX3JfyoUuFf0lT4fzIKMf3/HMNop0ILZxan3dzxpWlm1zkKzPZeph31FesEVvLTDGrsGuLW8Qkk0f7zGTCksxIWIYomOG09A5GM5O1hKYkPbDEAzjVcSZnJ3heOjzyvJ8YSLY8C0ezDGL0L2Itxj07FGGyGFQ6E0/JKnFF9FqWp9SnVqMXmNtdxTfScoQrfySf9cuuGaruLWznxE6RVdHf6CHWP6oOKQt5ZMYEkk/fumeM7Al/wP1OFz3R67uND7WnBUb+Ymj0beLLb/spXg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E/JoAKCD7+jIqOEqN6mETMoocRjQve82mJB8B4ow5tU=; b=lIziR2w1MJBt+wuNqMfQghpj9Nh2w/hlWPEBA0JmSsFCqSdiwNwIEMcxYUPZJsG9ZiNiPWmiex6PbtfrgoJwy6WO5rBJ8vyfVm44qxKdfRVuj4JpwTOVoTyXgj1n4sDXNoocO2XNU6FdEVFkk6QnIOvuLgrBxl++c7mC3RLalT1AmqERQ+IxDZJ6qpQQcTJDzzNLLDW0dxMDUr681fMrSclbZkWAJk8KzL4iI14+JTRKzvL4T+taeRm0O4AWcNTKO6mHwBfi190i6CobrxNz845shDIID0FQ/qxUdKIWCl34QRPt8NvI+LgZB+m9r8KJqX2MSsyRgg8j/iaplHeI5w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=E/JoAKCD7+jIqOEqN6mETMoocRjQve82mJB8B4ow5tU=; b=JlqLkXi3iqnEUko5ZKJOOb6uC+smYgtClyNPlHvO1EiG38AzAEIuYbYxh++IRYWvrzBmI6MPBy8nfZcPZ1yU3wVF7luLf8pOlmfVFlDZyNkqGidriuZfipHiWlMpEc+Ck1T265nT8PYJ4Lh8BLCadEt2qoXwjMjbIV0jjxGXVWo=
Received: from BN8PR05MB6098.namprd05.prod.outlook.com (2603:10b6:408:45::29) by BN6PR05MB2995.namprd05.prod.outlook.com (2603:10b6:404:2a::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4065.6; Wed, 21 Apr 2021 20:01:54 +0000
Received: from BN8PR05MB6098.namprd05.prod.outlook.com ([fe80::4d47:2d3c:d3c5:2e14]) by BN8PR05MB6098.namprd05.prod.outlook.com ([fe80::4d47:2d3c:d3c5:2e14%3]) with mapi id 15.20.4065.021; Wed, 21 Apr 2021 20:01:54 +0000
From: John Scudder <jgs@juniper.net>
To: Alvaro Retana <aretana.ietf@gmail.com>
CC: "draft-ietf-roll-aodv-rpl@ietf.org" <draft-ietf-roll-aodv-rpl@ietf.org>, "roll@ietf.org" <roll@ietf.org>, "roll-chairs@ietf.org" <roll-chairs@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, The IESG <iesg@ietf.org>
Thread-Topic: John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)
Thread-Index: AQHXNVsZVxHxg8VYVkSdat85+ymoxKq9f5YAgAHoDIA=
Date: Wed, 21 Apr 2021 20:01:53 +0000
Message-ID: <6279B4EF-BDA3-4A5D-9974-E850D5E836A5@juniper.net>
References: <161886431878.23690.10633892549620498188@ietfa.amsl.com> <CAMMESsxBW_-jLybbeH7uUKSDchjE6mxgPmN4sXb6cj67fFzRBw@mail.gmail.com>
In-Reply-To: <CAMMESsxBW_-jLybbeH7uUKSDchjE6mxgPmN4sXb6cj67fFzRBw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.4)
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [162.225.191.192]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d5df4b66-3be8-4a7f-4565-08d905004f84
x-ms-traffictypediagnostic: BN6PR05MB2995:
x-microsoft-antispam-prvs: <BN6PR05MB29952F93E2D5E7C50350EF24AA479@BN6PR05MB2995.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: gmMbffHSHrGjuEXwqj4hqWcioWGCI9fUmHE6TWh4c7l+DLTz2AJPS0W+aF527B1sRlafwS5siq8PFrFO2UuJzmwItMV4AULS/W0JfGhoLuqwR8G+AybVQWYwP9+SLUnT3xpWFhtztF73a14Lfgrfl4IlIS8dGzxTttHk8FDgnqCBRIaywnYIvQILmwlz2yjltx2tZsqQ8Bi/QN7RE6lgBggSFaR+HRGXpw488nvP+U7k7ob0nHN4j+I1F4xIsZVj1X4Ah+uJ5MwO4FH/RtrEGlhmPxi++YdpPXZa+yolNrP5YCnJCVpkenkSS99G2rVdqVFUmysTDkJbr2RB6OFT24ovX/xx2DqihnQNV4xV/MtzNH1A8OMEZVBYfrdfO5Ffstt5fapgd7nL/HVnOj+sKh7sh5bXqZDX1KcgvxAd74paw7GD2iAp5DbRHCoDv69LO/7cqBeYXV/q5q/yr+qWUFzYmFLQ0bXR9nDGXutBY7M3GHrZXJsWZXABNDMFRwZJo7GEDPu7vWYTCLbx28jogXZndnu6/EBd07uvpG137Wvn1GNO++AZXAxflAwyg4mdVTHYXUsmJB5565ZKyJfizQ75+mgRMaQF9Bbr0naS5nV5yyBqAFxj7qgLCxli+zb56Xfjri0OjAPZzDAMyQIxTSomfuaQbrusZd/Qq9Whpzw=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR05MB6098.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(366004)(376002)(346002)(396003)(8676002)(83380400001)(2616005)(38100700002)(122000001)(71200400001)(91956017)(4326008)(66946007)(66476007)(6512007)(66446008)(66556008)(36756003)(76116006)(64756008)(478600001)(5660300002)(66574015)(33656002)(8936002)(86362001)(186003)(6506007)(53546011)(26005)(6486002)(54906003)(6916009)(316002)(2906002)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?SVBZcXRhNUtqbHc0WERkTTI5S3NMQjRiVWZ3WWxVYjMrZDBaU1BRU3FkTk1T?= =?utf-8?B?djhWeDVtQjNjYWlneTRvQnVoblUwNEMwYlFPU3lDTC96alZwaWkyYTMrNlFl?= =?utf-8?B?V1dScnd3Zjh1SGdXdE5BWGdTSTJuRGpEb0lnVjVxeEFxVXF1Y3RwTi9EODRU?= =?utf-8?B?MCtOQWZlMnNBZTdtTXVZaDQ1ajJWNzlKUnRqV0R1Smt0VHAyaW1EczZZUnVF?= =?utf-8?B?cTQwcWIyc3Y2STE3alhRM09MSFNINXpuc05xeDVWUnZCcTlOZksyUjI2bFdo?= =?utf-8?B?V2Y5SjFOTEpwYk42U3JHUU1ab0MzUU44eUhvSm5ySG1UZVJUNjZWQVY4VWhF?= =?utf-8?B?TXBDSnIwbVJ4eTEzWGFJdmlUNlZEQzI0Ni9EaEhJaG9OUHJJWmFjYnNGQ3ln?= =?utf-8?B?ekk2c0Y0VUw1YnhUYlkrREthNEFnR0FFblk4NDR1enZJU1R4SHY4djBNcEZC?= =?utf-8?B?bDhMRmI2SVZHV245MmpUSVJXdEhYbDVsemRueGxSKzc5aVdSQjFIS3dXNmtP?= =?utf-8?B?ZnJOQ2dWeTAyMHpvZlZJSHQ0YU9FLzhlMEJDOTRBS05ZUWFsMkI5M0RUbFU3?= =?utf-8?B?NEt3UlhEaXBEbXBKZ3loVU1LcEJaV0psVm0vbitrVi9Pc0s2ZENneFNDQS9P?= =?utf-8?B?eS9KMmdacS96YUtCK3dlSkdWN25GV2J0dW00OW0wY05kSVNWdDdaVjNVdUNq?= =?utf-8?B?bFVHQndVemM3WXBzeHllbnZad2dkQ05nWDlVRWtnZmVPS0ZWMm5qWnJkM3lP?= =?utf-8?B?dGlZWVRtOUZtdmMwSXhZL1orUk9zT0FUQWEydDdKU1MySDN5ZXkvdzZaRS9p?= =?utf-8?B?TktYS0JKc0RnaStZM0VkaEFwTWJOaXlzcXE2MUpnbWZtS3IyOEdlN2tWdGNp?= =?utf-8?B?UkluYlhsWDk0Uk8xVFhkYWk5ZlQ5alROdXdnQURLRmhtQWh4a2F0dkVXMko1?= =?utf-8?B?OFI0MS9FeEhBUFdVTGY4TU0xaFkwWm5JZk5XK2VOWFJJZ2RtbzZOY1Y4MWZw?= =?utf-8?B?VVdPR3hmVEp4UkNKZXBJMjR0bWtBcmxjYk5oaFRGRWxFSFRtZ2NJQTdzdDhI?= =?utf-8?B?azZ6WnE4aHRMQVY1aFpqRlNlTkJlQndFTGtLcUthcHlLb1dFVUkwMUhPb2d0?= =?utf-8?B?aThnWkk5LzcvVkxTVG1Pd2IrNXdqaElYdVloYUZ1SGZyWUxFZHZBSVhQdCt5?= =?utf-8?B?aFAyMTJhd2l3T1dYdW10ZDZQaXFGb2ZKc0tRQytEcjVyU05GVXh6aVZ6bm1S?= =?utf-8?B?VUxONk8xRkttYWYwczhwdUxTZjNQbWFmb2huUTFHU0RkK3JSeGpuNE9CNVVz?= =?utf-8?B?bUZXYk96K3N2YWhxd1R2OERHRS9TbktWZ1REaVBGVURJSU9UdmM1aDJPT2tk?= =?utf-8?B?d0c5L2V1Tk9WVXEvamxRbUdOaHJOa1VJSmJCVjdzcDh5Z2R6VTBZbXFrNDBn?= =?utf-8?B?UFZRaGxlSUtiRFo3bXpsUndnWHN5R0w1WFJNQnppR29EYk5QelVNRks4NnRP?= =?utf-8?B?dXMwQlIxUVhFMDBsNk5oMW41aXNvbmR1WURmcE5wSXFRUm1YcSs2eGl1Y05H?= =?utf-8?B?V3N6d1pEelg5YitaOFJKU21ZK3ltUHFGeUxiWFhuK0lvVHppWlJzeERIRW01?= =?utf-8?B?V3kvcjRzUWpKcnlWVDhaa2I0QTdnTXBTNnJGazY4SnVya2ZTZFM2eHBSR25r?= =?utf-8?B?L3FYR1Qwb2NNQ0t0Zk1ZUlBzWklpNklmT24zZFNSbG1vU20rbHk0Y1AxL1Mx?= =?utf-8?B?YnovNjE3NDBxR1dSREFQWXlCcTFXUnhVSFhIYWg4MnRIaTJEV1BoK1k2ZjFT?= =?utf-8?B?K29sZHZCdGo0cjZXZnZZZz09?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <AED8F5C991C0B64398334C2FE9962E95@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN8PR05MB6098.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: d5df4b66-3be8-4a7f-4565-08d905004f84
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2021 20:01:53.9894 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: e/50zTyA2Pcf9WsMfqZOuBfq85KsTSdqDOJFr9YBjEpiEZbxc1XCzrMG/Jro03yV
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB2995
X-Proofpoint-GUID: 4PRJ9DuQn4zi5mMpWN38yq0XJ3-Pu4Dg
X-Proofpoint-ORIG-GUID: 4PRJ9DuQn4zi5mMpWN38yq0XJ3-Pu4Dg
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-21_05:2021-04-21, 2021-04-21 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 suspectscore=0 phishscore=0 mlxlogscore=457 clxscore=1015 adultscore=0 impostorscore=0 spamscore=0 bulkscore=0 lowpriorityscore=0 priorityscore=1501 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104210136
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/_W9hO8U2MHYnYGKbogFg83dEw6o>
Subject: Re: [Roll] John Scudder's Discuss on draft-ietf-roll-aodv-rpl-10: (with DISCUSS and COMMENT)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2021 20:02:05 -0000

Hi Alvaro,

After our call I feel like we’ve made progress but there are still some things I’d like to finish hashing out.

> On Apr 20, 2021, at 10:55 AM, Alvaro Retana <aretana.ietf@gmail.com> wrote:
> 
> On April 19, 2021 at 4:32:03 PM, John Scudder wrote:
> 
> 
> John:
> 
> Hi!  Thanks for the review!
> 
> I'm just replying to your DISCUSS -- I will let the authors address
> the rest of the comments.
> 
> 
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
> ...
>> My chief difficulty with the document is placing it in context. No hints are
>> given to the reader as to what the expected network environment is. I think
>> it would be almost sufficient to say, for example “the network environment is
>> assumed to be the same as described in RFC 6550, Section 1” for example, but
>> without that hint and without a strong background in ROLL, I found myself
>> struggling.
> 
> AODV-RPL is an extension of RPL -- the same types of networks that RPL
> targets are appropriate for AODV-RPL.  The one differentiator is the
> ability of AODV-RPL to discover p2p routes that may not need to
> traverse the root (more below).  IOW, networks that have significant
> p2p traffic would benefit the most.

As we discussed on our call, I think the “expected network environment” thing was largely a red herring I was led to by imprecision in the use of “multicast”, see for example my comment #15. I think we can consider the “network environment” point put to rest.

>> Figures 4 and 5 in particular lead me to believe the expected environment
>> looks similar to a classic ISP network — a collection of nodes connected by
>> point-to-point links. If this isn’t correct (and I bet it’s not) that may
>> have led me into incorrect assumptions, which may be reflected in my other
>> comments below.
> 
> Now that I look at the figures again, I can see how they might look
> like a segment of a traditional access-distribution-core network. :-)
> 
> RPL forms a Destination-Oriented Directed Acyclic Graph (DODAG), which
> results in a tree-like structure with a Border Router (BR) at the top.
> In general, instead of access-distribution-core, the whole RPL
> instance is made up of leaves-transit routers-border router.  In some
> cases the leaves are RPL-aware, but not always.

A key observation is that the figure depicts a control plane topology, not a physical topology, right?

>> 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 present
>> 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.

The use of the term “base RPL”, or “native RPL” as the introduction calls it, is problematic, if I’ve understood you right. It’s a case of “the exception that proves the rule”, i.e. by referencing “native RPL” that implies the AODV-RPL is *not* RPL, which is a contradiction to what you’ve written above and explained to me.

So I think some work on that language is in order.

> Most of what I wrote above, which I hope helps clarify, is in the
> Introduction (pasted below).  I think that the text could have been a
> little more explicit in tying p2p traffic to AODV-RPL -- everything
> else seems to be there.  Yes, there is a strong assumption that the
> reader knows RPL.
> 
> Do you have specific suggestion on what can be added to the Introduction?

See below.

> Thanks!
> 
> Alvaro.
> 
> 
> 
> 
> 1.  Introduction
> 
>   RPL (Routing Protocol for Low-Power and Lossy Networks) [RFC6550] is
>   an IPv6 distance vector routing protocol designed to support multiple
>   traffic flows through a root-based Destination-Oriented Directed
>   Acyclic Graph (DODAG).  Typically, a router does not have routing
>   information for most other routers.  Consequently, for traffic
>   between routers within the DODAG (i.e., Point-to-Point (P2P) traffic)
>   data packets either have to traverse the root in non-storing mode, or
>   traverse a common ancestor in storing mode.  Such P2P traffic is
>   thereby likely to traverse longer routes and may suffer severe
>   congestion near the root (for more information see [RFC6997],
>   [RFC6998]).
> 
>   The route discovery process in AODV-RPL is modeled on the analogous
>   procedure specified in AODV [RFC3561].  The on-demand nature of AODV
>   route discovery is natural for the needs of peer-to-peer routing in
>   RPL-based LLNs.  AODV terminology has been adapted for use with AODV-
>   RPL messages, namely RREQ for Route Request, and RREP for Route
>   Reply.  AODV-RPL currently omits some features compared to AODV -- in
>   particular, flagging Route Errors, blacklisting unidirectional links,
>   multihoming, and handling unnumbered interfaces.
> 
>   AODV-RPL reuses and provides a natural extension to the core RPL
>   functionality to support routes with birectional asymmetric links.
>   It retains RPL's DODAG formation, RPL Instance and the associated
>   Objective Function (defined in [RFC6551]), trickle timers, and
>   support for storing and non-storing modes.  AODV adds basic messages
>   RREQ and RREP as part of RPL DIO (DODAG Information Object) control
>   messages, and does not utilize the Destination Advertisement Object
>   (DAO) message of RPL.  AODV-RPL specifies a new MOP (Mode of
>   Operation) running in a separate instance dedicated to discover P2P
>   routes, which may differ from the point-to-multipoint routes
>   discoverable by native RPL.  AODV-RPL can be operated whether or not
>   native RPL is running otherwise.

The final paragraph is the one that led me astray. Is this rewrite on target?

AODV-RPL is a new RPL Mode of Operation (MOP) that extends RFC 6550 to support routes with bidirectional asymmetric links. It makes use of RFC 6550’s DODAG formation, RPL Instance, and the associated Objective Function (defined in [rfc6551]), trickle timers, and support for storing and non-storing modes. AODV-RPL adds basic messages RREQ and RREP as part of the RPL DIO (DODAG Information Object) control messages, and does not utilize the Destination Advertisement Object (DAO). The AODV-RPL MOP runs in a separate instance dedicated to discovering P2P [*] routes, which may differ from the point-to-multipoint routes discoverable by RPL’s other modes of operation. AODV-RPL can be operated whether or not other RPL modes of operation are running otherwise.

[*] Although, I do agree with Éric’s DISCUSS about use of this terminology. I understand from Alvaro that it’s water under the bridge, but some kind of warning to the unwary traveler is in order: ‘hey, be aware we use “p2p" in a way you may find unusual!’

Thanks,

—John