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

[Remous-Aris Koutsiamanis <[e-mail]>]

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) <
[e-mail]> 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:* '[e-mail]' <[e-mail]>; 'georgios.papadopoulos@imt-
> atlantique.fr' <[e-mail]>
> *Cc:* roll <[e-mail]>
> *Subject:* About the flags of metric container in
> draft-pkm-roll-nsa-extension
>
>
>
> 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. 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.
>
>
>
> 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. The same requirement may appear in Chenyang’s draft “Traffic-aware
> Objective Function”.
>
>
>
> 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!
>
>
>
> 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/
>
>
>