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

From: Rahul Jadhav <[email-masked]>
Date: Tue, 11 Feb 2020 09:02:29 +0530

Hello Authors of NSA extn and all,

One more question in the context:

The draft adds new routing metrics/constraints (PS set) nested as part
of the NSA parent metric.

My question is with regards to what happens if this routing metric is
used outside of the CAOF. Any metrics/constraints could be used by any
OF and thus PS set metric defined by the draft can be used by other
OF.

RFC 6551 says that if the metric is not understood by the node and if
it is a 6LR then it may not process it but it has to propagate it.
Unlike other metrics, the PS set metric in this case contains
link-local values that cannot be used beyond link-local. As such upon
propagation, any downstream 6LR that understands the PS set metric
would use the information and get impacted adversely.

Should we tie the PS set metric to CAOF specifically in the draft, in
which case this problem won't be there? Or we can specify this issue
as it is for the readers to understand the problem if the PS set is
used outside of the CAOF. Either way works for me.

Best,
Rahul

---

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Tue, 11 Feb 2020 11:25:30 +0100

Dear Rahul and all,

Once again, thank you for spotting this issue. Great catch! 
We are happy with any of the following solutions : 

- We can indeed tie the PS set metric to CAOF specifically in the draft.
Furthermore, the policies in CAOF are extensible (we only specify examples), so potentially another policy could make a different use of PS as part of CAOF.

- We can indeed explain the issue in the draft so that the implementers decide on their own how to handle it.
Additionally, since the whole RPL instance uses the same OF, we would expect that if an OF which understands the TLV is used, then all the nodes will know how to process it.
So, this issue should not be very common.

- Another option would be to add an exception to the "all TLVs need to be propagated” rule from RFC 6551 specifically for the PS TLV.
The exception would specify that the PS TLV would be dropped if not understood.

Best regards,
Georgios and Aris

> On Feb 11, 2020, at 04:32, Rahul Jadhav <[email-masked]> wrote:
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: <[email-masked]>
Date: Wed, 26 Feb 2020 11:02:37 +0000

Hello all,

The discussion below prompts me to question the way the Parent Set (PS)
appears in the Dodag Metric Container (DMC). Sorry if this comes up late
in the process.

The NSA object carrying the PS TLV is currently specified to be Contraint.
This shows up only once in the text (page 11).
There are some issues associated with the PS being part of a constraint:
RFC6551 says
"In the presence of a constraint, a node MUST include a metric of the
same type.  That metric is used to check whether or not the   constraint
is met.  In all cases, a node MUST not change the content   of the
constraint."
The behaviour proposed in this draft would have to create an exception for
all of the above.

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.
I understand that you are trying to create a CA OF that mimicks as much of
the MRHOF as possible, and MRHOF says it doesn't use DMCs. So you would
have to specify that the CA OF is different in that it has to look at the
NSA Metric sub-object inside the DMC object. But in the current situation,
you already have to specify that the CA OF has to look at the NSA
Constraint sub-object inside the DMC object. With a metric, you could use
the Prec. field to highlight the fact that the PS TLV s a secondary
metric, beyond the implied ETX of MRHOF. Or you could send the ETX Metric
sub-object explicitely, at the expense of a few extra bytes, and state
that the CA OF simply uses DMCs.

Thoughts?

Dominique

Le 11/02/20 11:25, « Roll on behalf of Georgios Z. Papadopoulos »
<[email-masked] on behalf of
[email-masked]> a écrit :

>Furthermore, the policies in CAOF are extensible (we only specify
>examples), so potentially another policy could make a different use of PS
>as part of CAOF.
>
>Additionally, since the whole RPL instance uses the same OF, we would
>expect that if an OF which understands the TLV is used, then all the
>nodes will know how to process it.
>- Another option would be to add an exception to the "all TLVs need to be
>propagated” rule from RFC 6551 specifically for the PS TLV.

_________________________________________________________________________________________________________________________

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: Sat, 29 Feb 2020 00:51:56 +0100 (CET)

Hello Dominique,

thank you very very much for this. Comments inline.

> appears in the Dodag Metric Container (DMC). Sorry if this comes up late

Oh, better now than later :)

> The behaviour proposed in this draft would have to create an exception for

You are, of course, absolutely right.

It is interesting that when we started this work
(draft-pkm-roll-nsa-extension-00 / April 2018) we initially specified a
metric instead of a constraint, but in the immediately next version
(draft-koutsiamanis-roll-nsa-extension-01 / July 2018) we switched to the
constraint specification.
I absolutely agree that making an exception to this is undesirable.
>From the very first moment we wanted to avoid changing as few things as
possible to keep things simple and predictable.

> value. C=0, R=1, P=1 comes to mind for this metric.

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?

> the MRHOF as possible, and MRHOF says it doesn't use DMCs.

Actually, MRHOF does use DMCs, but only additive ones:

page 3:
   "Because MRHOF seeks to minimize path costs as described by metrics,
   it can only be used with additive metrics.  MRHOF does not support
   metrics that are not additive."

  "For example, the use of MRHOF with the latency
   metric allows RPL to find stable minimum-latency paths from the nodes
   to a root in the Directed Acyclic Graph (DAG) instance [RFC6550]."

> So you would
> Constraint sub-object inside the DMC object.

No problem here.

> With a metric, you could use
> metric, beyond the implied ETX of MRHOF.

There is only minor issue. The fact is that the information in the parent
set is used a filter to filter out the nodes that do not comply with the
Common Ancestor policy selected.
So, the PS / NSA metric would actually need to have *higher* precedence
(lower prec) than the other metric used (e.g. ETX).
However, this should be simple to explain.

> Or you could send the ETX Metric

This is needed, but just so that we can specify prec >0 for the ETX metric.

> Dominique

Again, thank you so much.
This was something which we definitely should have handled.

Please let me know if this solution is OK, and I will update the draft ASAP
to make the March 9th cut-off date.

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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;