Re: [Roll] NSA extn review

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

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]> 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