Re: [Roll] NSA extn review

Remous-Aris Koutsiamanis <> Wed, 30 October 2019 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14FF9120C44 for <>; Wed, 30 Oct 2019 07:31:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=KyUfehQa; dkim=pass (2048-bit key) header.b=JMS8w0ir
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Itrs9ZxyOlWQ for <>; Wed, 30 Oct 2019 07:31:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 543BE120B9F for <>; Wed, 30 Oct 2019 07:31:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B63B760 for <>; Wed, 30 Oct 2019 15:31:01 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20160819-nLV10XS2; t=1572445861; bh=cHeuMoH5uDGcmllwj45MV+HJOOFB3rS0HBVjg/3gAcU=; h=References:In-Reply-To:From:Date:Subject:To:From; b=KyUfehQaqaM7qjOTK1xp11IXh5hX0Swhv7kZkNs7LG5cmrZ/3gnaYXhNZJOrV/9nH f96YU+MbmuOM0viNFdVI7MVt1PpVMcUEtH3okdoEfkXZT9Ag29DUgUeOtTH2sl5aHN b9i69c72sNG1QzFqKdXcrSDkxsohCgwLLIYbAJ5aFJrZ7Di9wz8P5VNs2yzk4/2D1W EXIbCmjsXFWef2Iqx9SHNvW06Q1SU0x/Gdw2vlpkn/7MB5i7XtYJ0wzlRwD9i21Y3d qRcoj/vsruLw26sgZE8Sd4cOGPv5jda/m38ngv9DYlkBYn5+IT2CLPoC4dtRycmVOM jGAuT4Fna5rxw==
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1572445861; s=20191001-wvim;;; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Content-Type; l=12248; bh=cHeuMoH5uDGcmllwj45MV+HJOOFB3rS0HBVjg/3gAcU=; b=JMS8w0ir8IYVpxu/AbpifrxGsZZXJjzIGmP1+fvKRcYrU3wD579/GjGe2MsIbdmQ 6NdjPnweyHHbEPlwbWPZng+fZJCZpymfAnc/ois5HJpVBcgmeNpT2fJ+IUAnInFI0ko 7w9GkII8YtStQ4wJk8b0xeYh7Gd6sUqpBTRGV3lO2viPRxbhyz0ueC7Jn522qKKw+F3 pq/ZpWIZDSgmjQ5AGexeRrNkHmFJNOuNvHAr9H9YLuzzGKjB2Cm3OAZ01Zvk+ZtctH2 JFkcdiunqMYqE8jL/WOtEF5RxKtGWbe2+OZv934q2u+0f0i5NcNrKkLIEyp5YEQ82SX k5mX56/gHQ==
Received: by with ESMTPA for <> ; Wed, 30 Oct 2019 15:30:57 +0100 (CET)
Received: by with SMTP id z10so2294770ilo.8 for <>; Wed, 30 Oct 2019 07:30:57 -0700 (PDT)
X-Gm-Message-State: APjAAAV4IBVS56zEI6guTRJKpIwQAV8Q6cfp4S09m6KOfAvJkI3P+SHL GNH8PPhNeQS2FlmEwZCglaaht9kexeNNjr2gY6I=
X-Google-Smtp-Source: APXvYqyNpL9HpewQkAEqIlJAWbCpkTKaXntB+8PpSllBvOChbaUpdIL6uGfhKRv9La9jbc1ZcMMOeIRDjsXGE8vIcW0=
X-Received: by 2002:a92:4555:: with SMTP id s82mr363458ila.228.1572445856085; Wed, 30 Oct 2019 07:30:56 -0700 (PDT)
MIME-Version: 1.0
References: <BM1PR01MB26128F018BFC1088353F7541A9810@BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM>
In-Reply-To: <BM1PR01MB26128F018BFC1088353F7541A9810@BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM>
From: Remous-Aris Koutsiamanis <>
Date: Wed, 30 Oct 2019 15:31:00 +0100
X-Gmail-Original-Message-ID: <>
Message-ID: <>
To: Routing Over Low power and Lossy networks <>
Content-Type: multipart/alternative; boundary="000000000000ae46460596219484"
X-ContactOffice-Account: com:113819248
Archived-At: <>
Subject: Re: [Roll] NSA extn review
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: Wed, 30 Oct 2019 14:31:11 -0000

Hello Rahul,

thank you so much for these comments and sorry for taking so long to answer.

I have some responses inline.

On Fri, Sep 27, 2019 at 3:27 AM Rahul Jadhav <> wrote:

> Hello, Authors of NSA-extension,
> I agreed to review the document in IETF105 and would like to provide my
> comments.
> But before going into details, will it be possible to upload the XML
> version of the draft to the datatracker? Unlike other drafts, I do not see
> the XML form of this draft! Also, it would be much efficient if we sync
> using GitHub repo (where I can send PR for you to review).
I have just created a new repository as part of the ROLL WG github account
called* draft-ietf-roll-nsa-extension
It contains the up-to-date draft XML file. Feel free to post PRs and we
will quickly handle them.

> My primary point of discussion would be the way MRHoF is handled in the
> draft.
> The current text/OF described in the document seems insufficient.
> MRHOF makes sense only for metrics that are additive in nature. The CAOFs
> presented in the document are not additive, and the text simply tries to
> somehow fit MRHOF in the context.
So I think maybe this is probably a misunderstanding.
The draft proposes two things:
1. An extension to the DIO DAGMC NSA object to include a subset of the
sorted parent set (PS) of a node.
2. A set of Objective Functions, modeled around MRHOF, which take into
account the PS in DIO messages to aid in alternative parent selection.
The key here is that the document *requires* the container DIO DAGMC NSA
object to be a *constraint, not a metric.*
The basic idea is this, have an OF that functions identically to MRHOF,
using any additive metric to calculate the rank of parents in the parent
set, *but filter out potential parent in the parent set for use as
alternative parent using the DIO DAGMC NSA PS information.*
So, the only-additive-metrics requirement in MRHOF is not disturbed at all,
since for both preferred parent and alternative parent, the rank
calculation is the same as MRHOF.
The extra constraint is only for filtering out alternative parents.

Does this make sense?
Maybe we could explain it in a clearer way?

In the text we say *"In general, these OFs extend MRHOF by specifying how
an AP is selected. The selection of the PP is kept the same as in MRHOF."*
Maybe we should also note that the rank calculation is not changed for both
PP and AP?

> The draft reserves different OCPs for different Common Ancestor Policies
> (Strict, Medium, Relaxed). I thought that the policies are local in nature
> and different nodes in the same instance could use different policies. If
> we use different OCPs, then this is not possible. It is impractical to
> assume that certain policies (such as CA Strict policy) can be enforced
> using OCP.
You are right, and we thought about this issue. On the one hand different
OCPs mean exactly one one per RPL Instance, while the same means that you
have no idea what version (Strict, Medium, Relaxed) your neighbors are
running, in case you *do* care.
The policies are indeed local in nature, so in this case I assume the
correct thing to do would be to reserve just one OCP, and if nodes want to
include the version of CAOF used that can do it in another DIO field or
using another mechanism (e.g. statically pre-configured).
We will change the draft to only request one OCP.

>   The promiscuous overhearing assumes different security settings. I read
> the refed draft in 6tisch and it explains the assumptions, however, I
> believe it is better we explain the security implication of promiscuous
> overhearing in the security considerations in this draft.
I have no problem with this. Avoiding too much duplication of text was my
general guiding principle, so where possible we pointed to other sources.
This, incidentally, is also why we opted to use MRHOF as a base upon which
to build the CAOFs, instead of creating a full description.

Again, thanks so much Rahul for the comments.

We eagerly look forward to your reply.