Re: [Roll] NSA PS-set metric/constraint

dominique.barthel@orange.com Fri, 06 March 2020 16:37 UTC

Return-Path: <dominique.barthel@orange.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 24BA93A0A76 for <roll@ietfa.amsl.com>; Fri, 6 Mar 2020 08:37:35 -0800 (PST)
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, HTML_MESSAGE=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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.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 cqrrGkkRm8Rs for <roll@ietfa.amsl.com>; Fri, 6 Mar 2020 08:37:33 -0800 (PST)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19B843A0A6A for <roll@ietf.org>; Fri, 6 Mar 2020 08:37:33 -0800 (PST)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 48YtZM33xxz1y8D; Fri, 6 Mar 2020 17:37:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1583512651; bh=G8bNJlA8ljGBN/1ndx912fgwPZH9NoQFsbWk29GBJqg=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=P7AcxH5uqtmlCaN9IDOhzcCDPfxsY0N45tFfTMWX+V4padnCAWjh/ByZQ97J9/wag u4pN5xbZYAhjwtqBI9exG1OUwj6PXpO/3KCflAOCGugtYK7vfAmiO9YMp3FUw1rskS PNEirUvDCJyoFNHEmztwSRVFdIq3HK+3vPlDlii+uispBOovyh9DrE56RChIfau4fE tDVeMxxUZMh+NtN7ML+c/JxMYr5XFBMyeRjWHg3kMhm+BMK9ME54kKIKK2O7khDcJb 58Uv6vcuXv1CxXQg1F20scYOmdqoZwWb84hQ0VDfst49tjrt0uxzMEO2Vt31+tQq3a kbbQbEwAnVJow==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.60]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id 48YtZM24G1zFpWp; Fri, 6 Mar 2020 17:37:31 +0100 (CET)
Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBM5D.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0487.000; Fri, 6 Mar 2020 17:37:31 +0100
From: <dominique.barthel@orange.com>
To: Remous-Aris Koutsiamanis <aris@ariskou.com>
CC: "Georgios Z. Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr>, roll <roll@ietf.org>
Thread-Topic: [Roll] NSA PS-set metric/constraint
Thread-Index: AQHV89AkIRUDm8IJ50Cl66GqNKlk9ag7w24A
Date: Fri, 6 Mar 2020 16:37:29 +0000
Message-ID: =?utf-8?q?=3C21097=5F1583512651=5F5E627C4B=5F21097=5F147=5F1=5FD?= =?utf-8?q?A883A34=2E716FD=25dominique=2Ebarthel=40orange=2Ecom=3E?=
References: <CAO0Djp2W2N-_eACyQNZcapah=AugHRC0fwsg2nhuovZaXa7mUw@mail.gmail.com> <D9CDCE2C-92B4-4B92-AB17-01CC3ECD1047@imt-atlantique.fr> =?utf-8?q?=3C28813?= =?utf-8?q?=5F1582714957=5F5E56504D=5F28813=5F497=5F1=5FDA7C05D5=2E71025=25d?= =?utf-8?q?ominique=2Ebarthel=40orange=2Ecom=3E?= <CAK76PrmcuDnJ3hVBZkgCZ6z2eLNAREtKL244BGRXtA6CsVu3xA@mail.gmail.com> <CAK76Pr=1jVnv-A1zTUGKzDT2=4Ki5t2XHuoFwcf1TjpkhTC8hg@mail.gmail.com>
In-Reply-To: <CAK76Pr=1jVnv-A1zTUGKzDT2=4Ki5t2XHuoFwcf1TjpkhTC8hg@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.3.170325
x-originating-ip: [10.114.13.245]
Content-Type: multipart/alternative; boundary="_000_DA883A34716FDdominiquebarthelorangecom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/MJc5CpkrYJXtyKxbzCZprfQ3mG8>
Subject: Re: [Roll] NSA PS-set metric/constraint
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: Fri, 06 Mar 2020 16:37:35 -0000

Hello Aris,

Thanks for pinging me, this had disappeared under the pile.

> If I understand this correctly, a node reporting it's own parent set in the NSA will set P=1 basically to let the receiving nodes know that they should not expect to find inside all the metric along the whole path, but only a part of it, and in our case from just the sending node.
> Am I getting this right?

Exactly, this is what I had in mind. The recording along the path is partial (P), and it turns out to be exactly the one from the potential parent, which is all we need.
So it's all totally inline with RFC6551: we don't need to create an exception to RFC6551.
Best regards

Dominique

De : Remous-Aris Koutsiamanis <aris@ariskou.com<mailto:aris@ariskou.com>>
Date : Friday 6 March 2020 16:58
À : Dominique Barthel <dominique.barthel@orange.com<mailto:dominique.barthel@orange.com>>
Cc : "Georgios Z. Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr<mailto:georgios.papadopoulos@imt-atlantique.fr>>, "roll@ietf.org<mailto:roll@ietf.org>" <roll@ietf.org<mailto:roll@ietf.org>>
Objet : Re: [Roll] NSA PS-set metric/constraint

Hello Dominique,

sorry to bother you in a probably very busy period.
To finalise our draft before the cutoff, we're waiting for a brief answer from you on this previous question:

On Sat, Feb 29, 2020 at 12:51 AM Remous-Aris Koutsiamanis <aris@ariskou.com<mailto:aris@ariskou.com>> wrote:

[DP] Alternate proposal:
Could the PS be part of an NSA Metric? After all, it is used to help
select which parent(s) are best suited for upward routing, not to prune
downlink propagation of the DIO along a path that exceed some metric
value. C=0, R=1, P=1 comes to mind for this metric.

[ARIS]
So I read a bit more about this. So C=0 means "use as a routing metric", OK.
R=1 means "use as a recorded metric", i.e. not aggregated, because aggregated makes no sense, OK.
Now, P=1 means that one or more of the nodes on the path did not record the metric. So, it's less a "command" and more a report of previous behaviour.

My question is: it seems impossible that *all* the parent sets can be recorded along the path due to size, so each node *replaces* the received parent set with it's own.

We can specify this with text of course, but I have not seen another existing metric that behaves like this.
On the other hand, the NSA metric object is not used a lot, and if it makes sense for any metric to be replaced rather then appended to a list of metrics, that metric would be NSA.

I am not sure about that P=1 part though and how it relates to replacing the existing metrics.
If I understand this correctly, a node reporting it's own parent set in the NSA will set P=1 basically to let the receiving nodes know that they should not expect to find inside all the metric along the whole path, but only a part of it, and in our case from just the sending node.

Am I getting this right?

Best,
Aris

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.