Re: [Roll] NSA extn review

[Rahul Jadhav <[e-mail]>]

Thanks Remous, Georgios for addressing the comments.

Regarding using a single OCP... looks like you agree we just need a single OCP.
Regarding security considerations .. looks like we agree also.
Regarding extending MRHoF, your argument sounds fine. Can you please post the updated text since the details on how to use parent set as constraints may not be as straightforward? It is better to update the text and make the proposition more clear like you suggested.

Best,
Rahul

________________________________
From: Roll <[e-mail]> on behalf of Remous-Aris Koutsiamanis <[e-mail]>
Sent: Wednesday, October 30, 2019 2:31 PM
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] NSA extn review

Hello Rahul,

thank you so much for these comments and sorry for taking so long to answer.

I have some responses inline.

On Fri, Sep 27, 2019 at 3:27 AM Rahul Jadhav <[e-mail]<mailto:nyrahul@outlook..com>> wrote:
Hello, Authors of NSA-extension,

I agreed to review the document in IETF105 and would like to provide my comments.

But before going into details, will it be possible to upload the XML version of the draft to the datatracker? Unlike other drafts, I do not see the XML form of this draft! Also, it would be much efficient if we sync using GitHub repo (where I can send PR for you to review).
I have just created a new repository as part of the ROLL WG github account called draft-ietf-roll-nsa-extension<https://github.com/roll-wg/draft-ietf-roll-nsa-extension>.
It contains the up-to-date draft XML file. Feel free to post PRs and we will quickly handle them.


My primary point of discussion would be the way MRHoF is handled in the draft.
The current text/OF described in the document seems insufficient.
MRHOF makes sense only for metrics that are additive in nature. The CAOFs presented in the document are not additive, and the text simply tries to somehow fit MRHOF in the context.
So I think maybe this is probably a misunderstanding.
The draft proposes two things:
1. An extension to the DIO DAGMC NSA object to include a subset of the sorted parent set (PS) of a node.
2. A set of Objective Functions, modeled around MRHOF, which take into account the PS in DIO messages to aid in alternative parent selection.
The key here is that the document requires the container DIO DAGMC NSA object to be a constraint, not a metric.
The basic idea is this, have an OF that functions identically to MRHOF, using any additive metric to calculate the rank of parents in the parent set, but filter out potential parent in the parent set for use as alternative parent using the DIO DAGMC NSA PS information.
So, the only-additive-metrics requirement in MRHOF is not disturbed at all, since for both preferred parent and alternative parent, the rank calculation is the same as MRHOF.
The extra constraint is only for filtering out alternative parents.

Does this make sense?
Maybe we could explain it in a clearer way?

In the text we say "In general, these OFs extend MRHOF by specifying how an AP is selected. The selection of the PP is kept the same as in MRHOF."
Maybe we should also note that the rank calculation is not changed for both PP and AP?

The draft reserves different OCPs for different Common Ancestor Policies (Strict, Medium, Relaxed). I thought that the policies are local in nature and different nodes in the same instance could use different policies. If we use different OCPs, then this is not possible. It is impractical to assume that certain policies (such as CA Strict policy) can be enforced using OCP.
You are right, and we thought about this issue. On the one hand different OCPs mean exactly one one per RPL Instance, while the same means that you have no idea what version (Strict, Medium, Relaxed) your neighbors are running, in case you do care.
The policies are indeed local in nature, so in this case I assume the correct thing to do would be to reserve just one OCP, and if nodes want to include the version of CAOF used that can do it in another DIO field or using another mechanism (e.g. statically pre-configured).
We will change the draft to only request one OCP.

  The promiscuous overhearing assumes different security settings. I read the refed draft in 6tisch and it explains the assumptions, however, I believe it is better we explain the security implication of promiscuous overhearing in the security considerations in this draft.
I have no problem with this. Avoiding too much duplication of text was my general guiding principle, so where possible we pointed to other sources.
This, incidentally, is also why we opted to use MRHOF as a base upon which to build the CAOFs, instead of creating a full description.


Again, thanks so much Rahul for the comments.

We eagerly look forward to your reply.

Best,
Aris