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

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Fri, 6 Mar 2020 16:58:57 +0100 (CET)

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 <[email-masked]>
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

---

From: <[email-masked]>
Date: Fri, 6 Mar 2020 16:37:29 +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 <[email-masked]<mailto:[email-masked]>>
Date : Friday 6 March 2020 16:58
À : Dominique Barthel <[email-masked]<mailto:[email-masked]>>
Cc : "Georgios Z. Papadopoulos" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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 <[email-masked]<mailto:[email-masked]>> wrote:

[DP] Alternate proposal:

[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.

---

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Fri, 6 Mar 2020 18:38:56 +0100 (CET)

Fantastic,

Thanks, I'll update the draft then.

Best,
Aris

On Fri, Mar 6, 2020 at 5:37 PM <[email-masked]> wrote:

> 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.
> De : Remous-Aris Koutsiamanis <[email-masked]>
> À : Dominique Barthel <[email-masked]>
> Cc : "Georgios Z. Papadopoulos" <[email-masked]>,
> "[email-masked]" <[email-masked]>
> On Sat, Feb 29, 2020 at 12:51 AM Remous-Aris Koutsiamanis <
> [email-masked]> wrote:
>
>>
>> [DP] Alternate proposal: