Re: [Roll] Remaining issues on draft-ietf-roll-nsa-extension

Ines Robles <mariainesrobles@googlemail.com> Sat, 21 March 2020 21:59 UTC

Return-Path: <mariainesrobles@googlemail.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 CCC273A09EF for <roll@ietfa.amsl.com>; Sat, 21 Mar 2020 14:59:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 G-vFk8kFQyVS for <roll@ietfa.amsl.com>; Sat, 21 Mar 2020 14:59:14 -0700 (PDT)
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 07A333A09E8 for <roll@ietf.org>; Sat, 21 Mar 2020 14:59:14 -0700 (PDT)
Received: by mail-vs1-xe2a.google.com with SMTP id e138so6305121vsc.11 for <roll@ietf.org>; Sat, 21 Mar 2020 14:59:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=B+t2JHphomXZIMRRduZLkQt+IFCBZ/EY22jQqDNYFJs=; b=j+5JdPP9oCKowB0NI7vaOgTIuMhLoGQczEaVx5GnKtqaoAcr71jHycyUG6sNgCZwdv BBnviZ/UFE9blZIF+x5Mb0yWIOl8ucwXPGXQw1tQLSGj1rJccqrbK88/J8vNa5vrZ7V4 +ClMMqaMMhVRXeMgMvdDEjCj8Q5xuBLo0WDig8IiTyCXOEOsamjfHbrm4veIsthMcBFU Sw5ITWE1JJB7NjRq2GPnaYcLs15Y2Tm8t3RENszoSzXYPBBvuXjDd4MwbxcOgk4feWA0 uJ919onAq7ZoEgyP+1+Pm44ZZRYzqjHXUCS3/LdJWkQZZIE6lGoUjWHBR9cwkkd0uNa5 OAig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=B+t2JHphomXZIMRRduZLkQt+IFCBZ/EY22jQqDNYFJs=; b=T28WIJD/qCO9+WV1O9IvyyjzfmN6Vmz6VIFVtWRkM3lQWm5Ngbyjke3F4SWVSfWWe9 6/HJEj47hA/+OCFKzwJ+IQLmgVjoAX3Miyt5gSG5YgwoQCN0GwgnR/KcLszyWTbKBBVh OTO9+sHRVoCITSeN6dCX+ZEJnQXL2j1UNn6xrOjYy51boWzfO7TQ1N5qACfUBUv4poSY vEOQMU1kiqGX9eHXmGw1WBB3xMir6WaY8K5DDuH0RvLBbPFDtYevZQbe0OtG0awTh+EM Ee5n3tt5e38pZ3HFsCbCXwJoXdeGqxszm8fLHrPC6OLBR0EfA9MEJ6TmP/Zrq6c4WkXf VQVQ==
X-Gm-Message-State: ANhLgQ2sELS4gFKeGoyNYRRUU6POlOVREqFhlE2IrYHOYsqbmNfbgSuM 6sWEcxoXpqyvHYvcmOiCTI4VbJqmhxsl630TOt4=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsigdNz1OXEy2Bx89KpaUg8sqBXsSt0dVD67DqY?= =?utf-8?q?kjdWzrE22T1HglgO/o7t87pdV4dFYgAMhdUfuXbEhXLyXWw=3D?=
X-Received: by 2002:a05:6102:40b:: with SMTP id d11mr1469775vsq.113.1584827952859; Sat, 21 Mar 2020 14:59:12 -0700 (PDT)
MIME-Version: 1.0
References: <CAK76PrmKVKXhPpcH6eq=f5O_rE0k0z-8dZouDeZddBbznftZPQ@mail.gmail.com>
In-Reply-To: <CAK76PrmKVKXhPpcH6eq=f5O_rE0k0z-8dZouDeZddBbznftZPQ@mail.gmail.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Sat, 21 Mar 2020 23:58:36 +0200
Message-ID: <CAP+sJUcRGak+yqyEyL36EhLLfqYWwWVuPjDFTwGz5jv_55y9jw@mail.gmail.com>
To: Remous-Aris Koutsiamanis <aris@ariskou.com>
Cc: roll <roll@ietf.org>, dominique barthel <dominique.barthel@orange.com>, "Georgios Z. Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr>, "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Rahul Jadhav <rahul.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000290ce305a164834f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/BTbmGgG66Y-C5CuVmz3VVLpH1I8>
Subject: Re: [Roll] Remaining issues on draft-ietf-roll-nsa-extension
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: Sat, 21 Mar 2020 21:59:16 -0000

Hi Aris,

On Tue, Mar 10, 2020 at 6:24 PM Remous-Aris Koutsiamanis <aris@ariskou.com>
wrote:

> Two small issues remain:
>
> a) Compression of the PS IPv6 addresses.
> Rahul brought this up in his review, we mentioned that this was proposed
> before, implemented and then re-removed because of the plan to have a draft
> that performs compression on all RPL control traffic packets (following
> Pascal's and Dominique's advice).
> *Question: is there any chance this has changed and we might want to
> perform compression on the PS field specifically after all?*
>

I think the compression can take place in a separate draft.

>
> b) Change of the context of the PS NSA object from a constraint to a
> metric.
> Following  Dominique's suggestion we changed it from a constraint to a
> recorded (R=1), partial (P=1) metric (C=0).
> The issue is that we are extending MRHOF and MRHOF supports the use of a
> single metric for computing the rank.
> It is true that the PS NSA object is not used for rank calculation, and we
> have clarified this.
> However, there might be still a conflict or a point to be clarified.
> See in MRHOF Section 2 Terminology
> <https://www.rfc-editor.org/rfc/rfc6719.html#section-2>:
> "Selected metric:  The metric chosen for path selection by the network
> operator.  MRHOF supports using a single metric for path selection."
>

Maybe you could add this to the section 4 and explain how the extending
MRHOF address this point.

>
> VS our draft Section 5.1 "Usage"
> <https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-07#section-5.1>
> :
> "It is important that the PS does not affect the calculation of the rank
> through candidate neighbors.  It is only used with the CA OF to remove
> nodes which do not fulfill the CA OF criteria from the candidate neighbor
> list."
> *Question: Is this sufficient in terms of explanation?*
>

Section 5 is clear to me.

Thank you,

Ines.

>
>
> We would really appreciate answers on these, if possible of course, before
> the ROLL meeting so that we can update/finalize the drafts.
>
> Kind regards,
> Aris & Georgios
>
>
>