Subject: Re: [Roll] nsa extension comments

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Fri, 7 Feb 2020 11:58:01 +0100 (CET)

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 <[email-masked]> 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

---

From: Rahul Jadhav <[email-masked]>
Date: Mon, 10 Feb 2020 14:02:46 +0530

Thanks Aris, Georgios for clarifications. Please find my responses inline.

>>
>> 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
>> format should be made part of different section and an IANA registry needs to

[RJ]: The reason why I was confused is that the "Optional TLVs"  are
mentioned in NSA section but there is no reference for the TLV format.
I now realized that section 2.1 has a para that explains the TLV
format which is applicable to all the optional TLVs in 6551. I stand
corrected. Thank you.

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

[RJ] This is sufficient, imo. Thanks

>
>>
>>
>> o Preference in PS set
>> The document assumes that the parent addresses in the PS set have been added in
> 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).

[RJ] I checked the PR. All ok except one question in the new changes,
"The number of p, wearent addresses in the PS IPv6" .... What is "wearent"?

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

[RJ] Sure, my concern is that it may be infeasible to use this work
without compression. I was hoping to use either 6lorh style or
P2P-RPL/AODV-RPL style (used for address vector) compression.

>> "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.
>
>
> 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.
> In any case, we do not want to reduce flexibility in this aspect by defining a spcific hierarchy/preference order on the policies.

[RJ] It would certainly help to clarify the bit. One question, is
there any reason/use-case why any node will not go for strict policy?
Why would administrator configure anything other than strict policy?
In the above response, it is suggested that to control
jitter/delay/reliability.  But the strict policy is best for any
use-case and for any metric or any group of metrics, isn't it?

> Thanks, we hadn't clarified that this is the same as the MRHOF PARENT_SET_SIZE variable. Updated in master.
>
>>
> 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 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.

[RJ] ok thanks. My confusion was that cur_ap_min_path_cost is the
aggregated cost to that AP from the root. This cost is the link local
cost of the node to that AP. Is this correct?

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

[RJ] Ok, lets wait for feedback. I, for one, would like to see
policies explained first and then an OF using them. I find this the
only logical way.

---

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Mon, 10 Feb 2020 15:46:07 +0100 (CET)

Hello Rahul,

thanks for the follow up. I think we've resolved most issues.
Responding inline.

> format which is applicable to all the optional TLVs in 6551. I stand

Great. Thanks as well.

>
> >
> > So yes, there is no NSA-specific TLV structure, it is common registry
> for all the routing metrics and constraints, including the NSA.
> > See
> > 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

Good we cleared that up. Thanks.

> "The number of p, wearent addresses in the PS IPv6" .... What is "wearent"?

Ah, unfortunately a typo. Fixed it in master, is should have read "The
number of parent addresses in the PS IPv6 address(es) field"
Thanks for the catch!

> > We agree that given the size of the IPv6 addresses, it would be
> prohibitive to include more than 2 addresses.
> > 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

I agree that compression is necessary but it looks like the consensus is to
handle this in a more all-encompassing and separate compression draft.
So from the feedback that we received from the WG so far, there doesn't
seem that there is something to do here.

> use-case and for any metric or any group of metrics, isn't it?

Actually, I that that it is not the best in all cases, so we have two
examples in mind.
1) Admin chooses relaxed to increase reliability (thus producing some
flooding) for specific, extremely important, alert packets. All normal data
traffic uses strict, but for the alert packets an exception is made.
2) One might devise a disjoint pattern, where the paths are on purpose
non-correlated, to increase path diversity and resilience against whole
groups of nodes failing. Of course, you pay with increased jitter. If
strict is always the default, you cannot ever replace it with another
policy with different characteristics.

By the way, nothing in the draft actually restricts an admin from
configuring the policies with a preference order of strict > medium >
relaxed, it's just that the draft does not enforce any particular such
ordering.

Does this make more sense?
Do you think it would help to include such examples as an appendix in the
draft?

> > 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 path cost of the current AP.
> > Just to be sure, we have now clarified here that PARENT_SWITCH_THRESHOLD
> is the same value that MRHOF uses. Updated in master.
>

Actually it *is* the aggregated cost.
As in RFC6719 (MRHOF). Section "3.1.  Computing the Path Cost",
"""The path cost of a neighbor represents
the cost of the path, in terms of the selected metric, from a node to
the root of the Destination-Oriented DAG (DODAG) through that
neighbor."""

So similarly to cur_min_path_cost, the new cur_ap_min_path_cost is the cost
of the path to the root, but through the AP instead of the preferred parent.

Is it clearer now?

> > The values used and their semantics should now be clear, basically in
> this section we either reuse existing MRHOF variables with the same MRHOF
> > 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
> > 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.
> > In that sense the CAOF is more "fixed" and the policies are more
> flexible. Thus it makes sense to describe the CAOF first.
> >

Sounds good, I will initiate a separate thread for this in the WG.

Again, thanks a lot for everything.

Best,
Aris