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

Alvaro Retana <aretana.ietf@gmail.com> Tue, 20 April 2021 14:55 UTC

Return-Path: <aretana.ietf@gmail.com>
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 5225F3A26F9; Tue, 20 Apr 2021 07:55:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 N92EXeWiu9aq; Tue, 20 Apr 2021 07:55:10 -0700 (PDT)
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27AD13A26F4; Tue, 20 Apr 2021 07:55:10 -0700 (PDT)
Received: by mail-ed1-x529.google.com with SMTP id j12so20403771edy.3; Tue, 20 Apr 2021 07:55:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=tthSrAePOHP9zLO2tQvS1409ythwiBM4Li2nXbXMq/c=; b=cNPFQ81pr/tGjdm2ANxQaF9a5eIYpTTl4wL0AbM6CVtRJpYMWAbNjbLRIY38xRrIPb BeNucZww8LjlskdXdUhTWXxPIAX5D+GmG2LK7bVAS2BTT0jKly/A5uTqsDsXQj0h4yN+ Sh28AODjog71E6lNB3eVYRB6FBPvuA6XpxBQzw77AwzxcwRFxgcqZkjWjGwcjr/uL4AW M6UDe49+IlVDK5deMsV12N7YnGCQ2RPrrjQH489Ww/7GL8/S/9pot4P/xOmQZp48Npg/ bXAGQmFu8POFsG0Jld/JOFWV+QFt+pcFEsBiFsZlDUH0hnA+xA0owotfTfTSaCJwKysV /0pg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=tthSrAePOHP9zLO2tQvS1409ythwiBM4Li2nXbXMq/c=; b=YbQX5jPm2upWc58y10iYcbKgLTIh2NdLnllaT1UUvWX4ZeRQbteJkma4gv7QkWrCIC 2KbARrNOWWAdcKXtY6oMVklRVlgZScj925Ef9C5WH+p8E3HAxEhBKSVQ9SZux6qAjTsc Zx/HjSHB9UyJvYDU0d+rlnyRmZikD7ZTvV9VIDIcTh9fNYAME+etNnMu4CAEhvMIsqxa qyw/GIBlxhePXVccWS3y0XmZdQuR1mWp2cjb7Nu+nRtlEOWmKZuCkK10h4gkWiQ3YEsZ +3rcmqF0OyxVE2Nwai+hleN4SKmCR8kYgjQ6N2vnWh4d8loZPnhiTAzVV57k6+A5KAoD LrZg==
X-Gm-Message-State: AOAM532KBKROIAVvu0Ots66LeNPmCs06FfrdB5wlX2zvaPbdZzrQHfTq 92+hwmiKRzH9u/0bxKMlk+QBKZXE/QKrkHXtxwA=
X-Google-Smtp-Source: ABdhPJyGDXuFrPgzZxWNIMp8EVAK0aO4QduKmnAxZbWKaiXCuWQNupBanApFP6D2K5uun4bAeZoAWhi6+RdKPfUeHt8=
X-Received: by 2002:aa7:c2c8:: with SMTP id m8mr18823283edp.86.1618930507621; Tue, 20 Apr 2021 07:55:07 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 20 Apr 2021 07:55:06 -0700
From: Alvaro Retana <aretana.ietf@gmail.com>
In-Reply-To: <161886431878.23690.10633892549620498188@ietfa.amsl.com>
References: <161886431878.23690.10633892549620498188@ietfa.amsl.com>
MIME-Version: 1.0
Date: Tue, 20 Apr 2021 07:55:06 -0700
Message-ID: <CAMMESsxBW_-jLybbeH7uUKSDchjE6mxgPmN4sXb6cj67fFzRBw@mail.gmail.com>
To: John Scudder <jgs@juniper.net>
Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll@ietf.org, roll-chairs@ietf.org, Ines Robles <mariainesrobles@googlemail.com>, The IESG <iesg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/xJsKa-NxEKWVeB4RUv8ol1ulHbs>
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: Tue, 20 Apr 2021 14:55:16 -0000

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.


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


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


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?

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.