Return-Path: 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 ; 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 ; 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 ; Sat, 21 Mar 2020 14:59:14 -0700 (PDT) Received: by mail-vs1-xe2a.google.com with SMTP id e138so6305121vsc.11 for ; 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: In-Reply-To: From: Ines Robles Date: Sat, 21 Mar 2020 23:58:36 +0200 Message-ID: To: Remous-Aris Koutsiamanis Cc: roll , dominique barthel , "Georgios Z. Papadopoulos" , "Pascal Thubert (pthubert)" , Rahul Jadhav Content-Type: multipart/alternative; boundary="000000000000290ce305a164834f" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Mar 2020 21:59:16 -0000 --000000000000290ce305a164834f Content-Type: text/plain; charset="UTF-8" Hi Aris, On Tue, Mar 10, 2020 at 6:24 PM Remous-Aris Koutsiamanis 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 > : > "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" > > : > "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 > > > --000000000000290ce305a164834f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Aris,

On Tue, Mar 10, 2020 at 6:24 PM R= emous-Aris Koutsiamanis <aris@arisko= u.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 compr= ession on all RPL control traffic packets (following Pascal's and Domin= ique's advice).
Question: is there any chance this has cha= nged and we might want to perform compression on the PS field specifically = after all?

I think the comp= ression can take place in a separate=C2=A0draft.=C2=A0=C2=A0

b) Change of the context of the PS NSA object from a constraint to a met= ric.
Following=C2=A0 Dominique's suggestion we changed it fro= m a constraint to a recorded (R=3D1), partial (P=3D1) metric (C=3D0).
=
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 N= SA 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.=
"= ;Selected metric: =C2=A0The metric chosen for path selection by the network= operator.=C2=A0 MRHOF supports using a single metric for path selection.&q= uot;
=C2=A0
Maybe you could add this= to the section 4 and explain how the extending MRHOF address this point.= =C2=A0

"It is important that the PS does n= ot affect the calculation of the rank through candidate neighbors.=C2=A0 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.=C2=A0

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.

<= /div>
Kind regards,
Aris & Georgios


--000000000000290ce305a164834f--