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

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

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