Re: [Roll] nsa extension comments

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

Hello Rahul,

again, thanks a lot for the comments and sorry about the delay in
addressing these.
We have now gone through the comments and we respond inline.

On Sat, Dec 7, 2019 at 9:06 AM Rahul Jadhav <[e-mail]> wrote:

> Hello authors,
>
> I have pushed my PR[1] to the corresponding roll-wg repo.
>

Thank you so much for the PΡ. We have merged it and have made a few minor
typo corrections on top.

However, there are other
> points which require your attention. Following are my comments:
>
> o Carrying TLVs in NSA
> RFC 6551 explains that an NSA can be used to carry TLVs but it falls short
> of
> specifying the format for these TLVs. This document assumes the format of
> 8-bit
> type and 8-bit length. This format is fine but future specifications will
> have
> to refer to this document if they got to add new TLVs. Thus the generic TLV
> format should be made part of different section and an IANA registry needs
> to
> be created for the NSA TLV type.
>

I'm not sure I fully understood correctly.
In RFC6551, page 24, Section "6.2.  Routing Metric/Constraint TLVs" it says:
"""IANA has created a sub-registry, called "Routing Metric/Constraint
   TLVs", used for all TLVs carried within Routing Metric/Constraint
   objects.  The Type field is an 8-bit field whose value is comprised
   between 0 and 255.  Value 0 is unassigned.  The Length field is an
   8-bit field whose value ranges from 0 to 255.  The Value field has
   value ranges depending on the Type; therefore, they are not defined
   here, since no Type is registered at this time."""

So yes, there is no NSA-specific TLV structure, it is common registry for
all the routing metrics and constraints, including the NSA.
See
https://www.iana.org/assignments/rpl-routing-metric-constraint/rpl-routing-metric-constraint.xhtml#rmc-tlv
As I understand it, RFC6551 contains the reference definition of the TLV
strucure (8bit Type, 8bit Length, variable length Value field)
and in our draft we basically ask for the creation of a new entry in this
sub-registry and specify/define the structure of the Value field only
(since the T & V are fixed already).
Is this maybe not sufficient?


>
> o Preference in PS set
> The document assumes that the parent addresses in the PS set have been
> added in
> the decreasing order of preference, without making it explicit. The PS IPv6
> address(es) field requires an explanation in Section 4.
>

Thank you very much, we have amended that part of the draft accordingly.
Please see if it is clear now (master branch in
https://github.com/roll-wg/draft-ietf-roll-nsa-extension).



> o DIO length
> As per the draft, the DIO needs to carry NSA (Node State and Attributes)
> metric
> with PS (parent set) TLV. As per my understanding without compression, it
> would
> be a challenge to carry even two parent addresses in the PS. There has
> been a
> discussion about compression and as I remember we discussed doing it.
> Regardless, I feel we should do it if we want this to be a practical
> proposition.
>


Thank you for this comment.
We agree that given the size of the IPv6 addresses, it would be prohibitive
to include more than 2 addresses.
When we initially pointed out this constraint ourselved, Michael pointed us
in the direction of 6LoRH.
We implemented a 6LoRH-style compression for this field and it worked well.
However, it was becoming complicated, somewhat out-of-scope and since there
was no good place to point at for our 6LoRH-style compression (a
potentially blocking issue), we discussed the options with the group (see
an email thread with subject "[Roll] I-D Action:
draft-ietf-roll-nsa-extension-02.txt" June 24 2019 - July 2 2019).
With input from Pascal and Dominique we decided to completely drop
compression, in favour of a potential separate and more general compression
draft for all control packets.
We would actually like to contribute to that, but for the time being, a
specific compression method for the PS field has been taken out of this
draft.


>
> o Section 3.4 Usage:
> "For example, using different methods can be used to vary the transmission
> reliability in each hop."
> This statement implies that using different CA policy implementation can
> "control" the transmission reliability. As I understand, the strict policy
> is
> the best policy (in terms of all performance metrics), the nodes will go
> for
> other policy only when the strict policy cannot be used given their parent
> sets.
> The above statement implies that nodes may still go for a relaxed policy
> when
> strict can be used.
>

Thanks for catching this, but in this case this is intentional.
As far as we are concerned a) there is no "best" policy, and b) a new
policy might be introduced in the future.
The important aspect is that the choice of policy is a local (node)
decision and different nodes can select different policies based on
whichever criteria make sense for them.
For example, depending on the required performance in
jitter/delay/reliability that is desired a different policy might be used.
An administrator might also configure nodes in a specific way.
In any case, we do not want to reduce flexibility in this aspect by
defining a spcific hierarchy/preference order on the policies.
Maybe it makes sense to clarify this a bit?


>
> o Configuration parameters
> The document specifies configuration parameters such as
> a. PARENT_SET_SIZE ... Not defined
>

Thanks, we hadn't clarified that this is the same as the MRHOF
PARENT_SET_SIZE variable. Updated in master.


> b. cur_ap_min_path_cost: How can the cur_ap_min_path_cost be equated with
> PARENT_SWITCH_THRESHOLD as mentioned in section 3.2.2
>

Thank you but we are not very sure we understant the question. This section
basically says that in addition to the normal MRHOF cur_min_path_cost
variable, we add the cur_ap_min_path_cost variable which contains the the
path cost of the current AP.
We use the same threshold PARENT_SWITCH_THRESHOLD that MRHOF uses to decide
if we need to change AP.
Just to be sure, we have now clarified here that PARENT_SWITCH_THRESHOLD is
the same value that MRHOF uses. Updated in master.


> c. MAX_PATH_COST: No definition for this.
>

Again, thanks, we hadn't clarified that this comes from MRHOF. We added a
clarification and updated in master.


> The parameters warrant a rationale and a default value. Also more
> importantly,
> is it required that different nodes use the same value and if not what
> could be
> the impact.
>

The values used and their semantics should now be clear, basically in this
section we either reuse existing MRHOF variables with the same MRHOF
semantics, or we introduce new variables which have corresponding ones in
MRHOF and similar semantics.
Please let us know if you think we should define something in more detail,
but we would like to avoid too much duplication from MRHOF, if possible.


>
> o Terminology section
> Terminology section should explain Alternative Parent, Parent Set,
> Preferred
> Grand Parent.
>

Thank you very much, this is a good idea. We have amended the text with
this and updated in master.


>
> o Section realignment
> It is better to explain CA Strict/Medium/Relax policies before explaining
> the
> CAOF because as a reader one needs to be familiar with these policies
> before
> understanding the OF.
>

Thank you for this comment. We had a similar concern as well.
We are not sure what is best.
As the text is current structured, we introduce the CAOF first, mentioning
that different policies are possible and that a selection from the parent
set must be made.
We then describe the CAOF in terms of differences from/additions to MRHOF.
And finally we describe the policies.
To my mind, the policies are concrete, but they are also just examples, so
someone can devise different ones.
In that sense the CAOF is more "fixed" and the policies are more flexible.
Thus it makes sense to describe the CAOF first.

We are very open to changing the order, but we would like to have some
additional feedback that the order is problematic as it stands now.
We would like to hear any suggestions from the group on this topic.


> Regards,
> Rahul
>

> [1] https://github.com/roll-wg/draft-ietf-roll-nsa-extension/pull/1
>
>
Thank you very very much for the feedback and the thorough work Rahul. It
is very much appreciated!

Best,
Aris & Georgios