Re: [Roll] AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont)

Alvaro Retana <> Mon, 09 November 2020 19:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C2603A1273; Mon, 9 Nov 2020 11:13:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, 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 cyDUrBIvUrBI; Mon, 9 Nov 2020 11:13:57 -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 9AAF13A11D4; Mon, 9 Nov 2020 11:13:57 -0800 (PST)
Received: by with SMTP id v4so9982772edi.0; Mon, 09 Nov 2020 11:13:57 -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=lTqoroyooKJIwn2sJbvqZrKeK8/a4NUNkBtSOl4ioAY=; b=oZWdy9gpFJlG5SNDpzZ+TlQOOQL24w0h4Zh824j5PGPgmNpdgnD/4Jn2q9aBYZ5eHQ jed7/DBEfUvNCjaBc/W7qq3iUq8IFBWGVQEC1yspXCPoDc3fl7bvVY3GYP5XqIhije1m wwL1SjhX8ylkhnf10WyePOirbgQ0ogvlnKCTSJwVI8ajtChj8O/aD6EY1cruNpf+zjqs tC6qvXjNCCDVg4mZaapmx/Quh4vertmfICapc2j1rE7iXRXmwHj5JzRaXoD/FvJncaRQ eWH9rpmrqwbpXob0St5INgu5VBtygyHgfFkDsd9RDBTKsjXDRfgQp/Siv3yAI03zCAW4 9Bdw==
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=lTqoroyooKJIwn2sJbvqZrKeK8/a4NUNkBtSOl4ioAY=; b=YElUaKl7IH4KijnlV5ZF5I4Jwn8Ry5dtTUdGwRkkL3zgaNXtS0AWBBdggyD6rzSaU6 I/JY4RT0C8OD6cZHNW2zU+hjzReUJE/qd/hLvXjiFlTvJQw71CxTlJJT05rpzA0SMZQF /+bj8DWTHioSgDUDTjpWuG4i9Xfd3NNtUmVDW6OYQqCsDBdDdwh55M/XZt8OqwkJyhhM U1b8aetBQQy5XiPsFaJJZkQ+ygBVXeo8yVzapMcOaNYPCe4PELRt1peGx/dLLLsqTt+z LIBLDzJ0pAEG6y5/cQEuY0rpg0UcwxilyGonTgJVcm4/M3Bq6yzD9YAl/d1qmWbPWXfa l/nQ==
X-Gm-Message-State: AOAM531+zeVJ326B1MkAfMTm3x4RQGa3PtKH3y4qNHsYhyHEyjICzYzD K9JbD0cxunTPHzIZ8H//YV24QSKngL/yco6c4Wc=
X-Google-Smtp-Source: ABdhPJxi5bUVj2QxdSexDhe6TXN/j9xQ3shzd3ITbkkBfN/oD4oMaXVF3dJohzv5oj+8ST8ZaAdu3jLVnSKnmkY1hkE=
X-Received: by 2002:aa7:ce8d:: with SMTP id y13mr17651950edv.65.1604949236023; Mon, 09 Nov 2020 11:13:56 -0800 (PST)
Received: from 1058052472880 named unknown by with HTTPREST; Mon, 9 Nov 2020 11:13:55 -0800
From: Alvaro Retana <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Date: Mon, 09 Nov 2020 11:13:55 -0800
Message-ID: <>
To: "Pascal Thubert (pthubert)" <>, "" <>
Cc: "" <>, Routing Over Low power and Lossy networks <>, Rahul Jadhav <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Roll] AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont)
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: Mon, 09 Nov 2020 19:13:59 -0000

On November 9, 2020 at 3:58:44 AM, Pascal Thubert wrote:



I'm ok with the document as is...just one comment remaining.  You can
take it as a Last Call comment.

I'll start the IETF LC when I get updated versions of both this and
UseofRPLInfo.  If you're ready to submit before the window opens
again, feel free to ask the Secretariat (
for manual posting -- I'll approve.



> > > Nothing prevents a packet coming in a RPL domain to carry an RPI.
> > Should any of this be also in UseofRPLInfo? Or maybe it should be
> > explained there and referenced form here. UseofRPLInfo talks about
> > always inserting the RPI at the 6LR, no exceptions.
> >
> I'll open a thread; your point on the security section could be reflected
> there, that if the external destination passes a packet with a RPI then the
> RPI should be revisited or encapsulated.

As I was reading UseofRPLInfo-41...  §6 (Use Cases) now says this (one
of the assumptions in the use cases):  "For traffic leaving a RUL, if
the RUL adds an opaque RPI then the description of the RAL applies."

This is what I was looking for (in UseofRPLInfo) in terms of how to
handle an RPI from the RUL.  There is however a difference between
what is now written in unaware-leaves and what UseofRPLInfo says (in
the "RAL to..." cases).  In general, UseofRPLInfo says that the 6LR
modifies the RPI, but provide no details except for mentioning the
rank...  The difference is that unaware-leaves says that if the sender
was a RUL then the 6LR "SHOULD rewrite the RPI".

I think that we could simply add the Normative text from above to the
sentence in §6/UseofRPLInfo to bring them all in sync:

   - For traffic leaving a RUL, if the RUL adds an opaque RPI then the
     description of the RAL applies.  The 6LR as a RPL border router SHOULD
     rewrite the RPI to indicate the selected Instance and set the flags.