Re: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-33.txt

Alvaro Retana <> Thu, 19 December 2019 20:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0F1F4120131; Thu, 19 Dec 2019 12:44:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 W3bFZzlhRCEW; Thu, 19 Dec 2019 12:44:33 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::530]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B247E1200DF; Thu, 19 Dec 2019 12:44:32 -0800 (PST)
Received: by with SMTP id cy15so6202913edb.4; Thu, 19 Dec 2019 12:44:32 -0800 (PST)
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:content-transfer-encoding; bh=vvi6LRq4RqwnTbHD1Xlrb6TrNfjx8TS76DG5iOGNBuk=; b=GveymyC47cJkmS4HM7Xkeh/C9u5yFVDB98oT4f/FUcz72Dm6jQlXmYmMFQp6VIz7is 5/uXKlFOek4/TrUUO3ItRKuNmLrZL5p+6DA81uJNLSP0d81izTgblitzz7Au6ZF/zm6j 3atYanChJ4aUb6LYVhdZ/4GcWC4cpvwRo/rBZkC3t+rtEVbfLqPabZTvgOnFciOr39fO ke/pzUCuEA5AgF/TG+TRJ/LToitN5CH1MOw2Qsvhvpuc2oGqTZRkkfyhtVu4NpdlXIQc NQoaqz62fnvRFQ4FExk6t0kyLxperFYILKWiNiCrlfF3PIYlPkyr3ocThDPz5Rmx8H2z 5B7Q==
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:content-transfer-encoding; bh=vvi6LRq4RqwnTbHD1Xlrb6TrNfjx8TS76DG5iOGNBuk=; b=Yz8uqvfqi4wRkTvCOaK56cjRoFF4/EPPhb2K7M6DIB7UtqDbyVS6Y07uaSgj1x2cY8 Gi/SzU9AUF9AvXfXKGK2p22IQN+kbauA4OoyRWgA1i8tHy62tix8Qnxt7dPVrtzYKwJP A2GQxGkbsd9amYK8cyJqPy9lbptO4l4Y0ziiqCc2Vvk10Y6xVwV7hCpCwsAfbsBF2bff eolFZ4jjE6gnGWC+jyrkR6t/9XrQe+Cotefb7TgcE2g0yvhuToSKVIj8ULmmqae7zU3d zd86DeoWxUL3Oyvrpv6ovmqiFwquhgOIzj47/PJiVRieGGp7njU0cF/A66uFC0QQvvWB WaJQ==
X-Gm-Message-State: APjAAAWIltWLsIDlFQ6knNpXeZYgJX+hPlEoFE6sZvWg4fZ2O6pqKH93 GwZicMQd7s3soKvrj1IeAS6/U//6Ykv4DjboN0V7dA==
X-Google-Smtp-Source: APXvYqy9s13ghXEIZyTgsfQDD723vzFqLZpsNP0HlP8u08gJOJCtky9cMJvZjjHr1BOiuw2Lsv08DfXjyYJy9VNjhS4=
X-Received: by 2002:a17:906:20c5:: with SMTP id c5mr12041948ejc.330.1576788270883; Thu, 19 Dec 2019 12:44:30 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Thu, 19 Dec 2019 15:44:29 -0500
From: Alvaro Retana <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Date: Thu, 19 Dec 2019 15:44:29 -0500
Message-ID: <>
Cc:, "" <>, Peter van der Stok <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-33.txt
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: Thu, 19 Dec 2019 20:44:35 -0000

Dear authors:

I reviewed this latest version, focusing on the changes since -31.  I
have a couple of comments (see in-line below) which I think should be
easy to solve -- hopefully all we need is a clarification.

I did notice that you didn't address the RFC Editor's questions sent
by Lynn on Sep/3.  Let me know if you don't have her message and I can
forward it to you.  As a reminder, the RFC Editor had finished editing
the document then we pulled it from their queue, so it seems fair to
address their questions in the document (and send them a reply when we
hand it back).



[Line numbers from idnits.]

186	2.  Terminology and Requirements Language
197	   RPL Leaf: An IPv6 host that is attached to a RPL router and obtains
198	   connectivity through a RPL Destination Oriented Directed Acyclic
199	   Graph (DODAG).  As an IPv6 node, a RPL Leaf is expected to ignore a
200	   consumed Routing Header and as an IPv6 host, it is expected to ignore
201	   a Hop-by-Hop header.  It results that a RPL Leaf can correctly
202	   receive a packet with RPL artifacts.  On the other hand, a RPL Leaf
203	   is not expected to generate RPL artifacts or to support IP-in-IP
204	   encapsulation.  For simplification, this document uses the standalone
205	   term leaf to mean a RPL leaf.
212	   RPL-aware-node (RAN): A device which implements RPL.  Please note
213	   that the device can be found inside the LLN or outside LLN.

215	   RPL-Aware-Leaf(RAL): A RPL-aware-node that is also a RPL Leaf.

217	   RPL-unaware-node: A device which does not implement RPL, thus the
218	   device is not-RPL-aware.  Please note that the device can be found
219	   inside the LLN.

221	   RPL-Unaware-Leaf(RUL): A RPL-unaware-node that is also a RPL Leaf.

I think there is a conflict in the new/updated definitions: what does
it mean to "implement RPL"?

A "RPL Leaf can correctly receive a packet with RPL artifacts", which
I assume it means that it implements RPL, at least enough to
understand the artifacts even if it doesn't generate them.   OTOH, a
RPL-unaware-node "does not implement RPL".  But then a RUL is "a
RPL-unaware-node that is also a RPL Leaf".  This last definition
sounds contradictory to me because the RPL Lead has to implement
enough of RPL to understand, but being unaware....

303	4.1.  Updates to RFC6550: Advertising External Routes with Non-Storing
304	      Mode Signaling.
347	   A node that is reachable over an external route is not expected to
348	   support [RFC8138].  Whether a decapsulation took place or not and
349	   even when the 6LR is delivering the packet to a RUL, the 6LR that
350	   injected an external route MUST uncompress the packet before
351	   forwarding over that external route.

If the packet is not decapsulated, how can it be uncompressed?

672	6.  Use cases
800	      - In the uses cases, we assume that the RAL supports IP-in-IP
801	      encapsulation.

803	      - In the uses cases, we dont assume that the RUL supports IP-in-IP
804	      encapsulation.

Please reword these two assumptions to avoid the use of "we".

On December 13, 2019 at 11:02:18 AM,
( wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF.
> Title : Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane
> Authors : Maria Ines Robles
> Michael C. Richardson
> Pascal Thubert
> Filename : draft-ietf-roll-useofrplinfo-33.txt
> Pages : 56
> Date : 2019-12-13(http://airmail.calendar/2019-12-13%2012:00:00%20EST)