Subject: Re: [Roll] About the flags of metric container in draft-pkm-roll-nsa-extension

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Thu, 11 Jan 2018 17:59:07 +0100 (CET)

Hello Derek,

thank you very much for the nice comments and the pointer. They are very
much appreciated.
I was away on vacations, hence my delayed response. I will answer inline to
your comments.

On Fri, Dec 22, 2017 at 10:35 AM, Houjianqiang (Derek) <houjianqiang@huawei
.com> wrote:

> Dear Remous-Aris and Georgios,
>
>
>
> Thanks for bringing your draft “draft-pkm-roll-nsa-extension” into roll
> WG. It’s a very interesting work and hope it could be adopted in this WG.
>
>
>
> The recent discussion with Chenyang triggers my interest to read this
> draft again. Below are my comments.
>
>
>
> It seems that your NSA metric is locally used. I mean one node includes
> its potential parents into NSA and sends this NSA down to its potential
> children.
>

Yes, you are correct. We should say this explicitly to avoid confusion.

> If this is correct, then it would be good to specify the parameters used
> in the Metric Container (P,C, O, R ,A, Prec fields).
>

You are correct, of course. We intend to do that in a next version.

> (PS: there are two ‘A’ and two ‘O’ bits in Figure 3 of your draft…)
>

Yes, it is unfortunate and we need to clarify that. "Figure 3: DAG Metric
Container data with Node State and Attribute (NSA) object body and a TLV"
has the fields of *both* the DAG MC and the NSA object, an it so happens
that both have fields named "A" and "O". Thanks for pointing this out!

> I suggest this because I find that to meet the NSA function you want, we
> may need to extend the usage of Metric defined in RFC6551. What RFC6551
> bother me are the ‘R’ flag and ‘A’ field in the MC. When NSA is used as a
> metric, R=1 indicates that the NSA is recorded along the path; R=0
> indicates the NSA metric is aggregated (this aggregation could be additive,
> multiplicative, reports a maximum or minimum according to the ‘A’ field). I
> suppose the NSA metric requires to be used locally, not aggregation or
> recorded along the path. I guess the ‘P’ flag may help to solve this issue
> or we may need a new flag in the MC to indicate a locally used metric.
>

I agree with your interpretation of the semantics of the 'R' and 'A' field;
it does not seem to be possible to express a non-aggregated *and*
non-recorded-along-the-path metric. For our purposes, we could just use the
"Parent Node Set" TLV within the NSA where the NSA is used as a
*constraint* instead of as a metric. Aggregation and
recording-along-the-path do not apply for constraints per the spec and thus
there is no need to interpret the "R" and "A" fields.

>
>
> I am involved in draft “Load Balancing Objective Function in RPL” and I
> have similar concern when setting the flags in the metric container for the
> proposed Child Node Count (CNC) metric. We also want the CNC to be used
> locally, and it seems we need to extend the current metric usage in
> RFC6551.
>

I am aware of your work and I agree that if you want to use the CNC as a
metric of we wanted to use the Parent Node Set in the NSA as a metric, then
yes, i think the spec does not cover this usage.

> The same requirement may appear in Chenyang’s draft “Traffic-aware
> Objective Function”.
>

Yes, you are correct, there's the same issue there.

>
>
> And one more thing. I find with your proposed NSA that includes parent
> address(es), we don’t need to insert the parent address into our CNC
> metric. This greatly simplifies our solution. That’s good!
>

I'm happy that there seems to be some overlap in our solutions. It will be
nice to find a way of separating concerns so that effort is not duplicated.

>
>
> Best regards,
>
> Derek Jianqiang Hou
>
>
>
> Related drafts:
>
> https://datatracker.ietf.org/doc/draft-pkm-roll-nsa-extension/
>
> https://datatracker.ietf.org/doc/rfc6551/
>
> https://datatracker.ietf.org/doc/draft-qasem-roll-rpl-load-balancing/
>
> https://datatracker.ietf.org/doc/draft-ji-roll-traffic-
> aware-objective-function/
>

Sincerely,
Remous-Aris Koutsiamanis

---

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Thu, 11 Jan 2018 18:12:58 +0100 (CET)

Hi again,

thanks for another idea. I looked into it and it seems that it allows zero
or one parent address (0 is on storing mode, 1 in non-storing mode). So for
us this wouldn't do.
Also, the "Transit Information" option has so,e specific usage with the
"RPL Target" option preceding it, so it might be too complicated to define
different behaviours based on whether it is in DIO or DAO.
But thanks for the idea anyway. It has gotten me thinking about alternative
ways of accomplishing the same thing easier.

Best,
Remous-Aris

On Sat, Dec 23, 2017 at 2:58 AM, Houjianqiang (Derek) <
[email-masked]> wrote:

> Another idea for your consideration. The “Transit Information” in the DAO
> Option contains parent address(es). What about enabling the use of Transit
> Information in the DIO Option field?
>
>
>
> Derek
>
>
>
> *From:* Houjianqiang (Derek)
> *Sent:* Friday, December 22, 2017 5:35 PM
> *To:* [email-masked]' <[email-masked]>; 'georgios.papadopoulos@imt-
> atlantique.fr' <[email-masked]>
> *Cc:* roll <[email-masked]>
> *Subject:* About the flags of metric container in
> draft-pkm-roll-nsa-extension
>
>
>
> children. If this is correct, then it would be good to specify the
> parameters used in the Metric Container (P,C, O, R ,A, Prec fields). (PS:
> there are two ‘A’ and two ‘O’ bits in Figure 3 of your draft…) I suggest
> this because I find that to meet the NSA function you want, we may need to
> extend the usage of Metric defined in RFC6551. What RFC6551 bother me are
> the ‘R’ flag and ‘A’ field in the MC. When NSA is used as a metric, R=1
> indicates that the NSA is recorded along the path; R=0 indicates the NSA
> metric is aggregated (this aggregation could be additive, multiplicative,
> reports a maximum or minimum according to the ‘A’ field). I suppose the NSA
> metric requires to be used locally, not aggregation or recorded along the
> path. I guess the ‘P’ flag may help to solve this issue or we may need a
> new flag in the MC to indicate a locally used metric.
>
>
>
> RFC6551. The same requirement may appear in Chenyang’s draft “Traffic-aware
> Objective Function”.
>
>
>