Re: [Roll] nsa extension comments

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

Hello Rahul,

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

On Mon, Feb 10, 2020 at 9:33 AM Rahul Jadhav <[e-mail]> wrote:

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

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
> 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?
>
> [RJ] This is sufficient, imo. Thanks
>

Good we cleared that up. Thanks.


>
> >
> >>
> >>
> >> 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).
>
> [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"?
>

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!


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

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.



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

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?


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

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?


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

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

Again, thanks a lot for everything.

Best,
Aris