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.
- [Roll] John Scudder's Discuss on draft-ietf-roll-… John Scudder via Datatracker
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… Alvaro Retana
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… John Scudder
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… Alvaro Retana
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… John Scudder
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… Charlie Perkins
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… John Scudder
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… Charlie Perkins
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… Ines Robles
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… Ines Robles
- Re: [Roll] John Scudder's Discuss on draft-ietf-r… John Scudder