Re: [Roll] AD Review of draft-ietf-roll-nsa-extension-10

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

Hello Alvaro,

Thank you very much for your response and review.  Sorry for the
delayed response also on our side, due to a period of increased
workload.

Overall we are in wide agreement with you.
Please see inline for responses and we'll work on a revised version
addressing them:

On 17/03/2022 18:33, Alvaro Retana wrote:
> Dear authors:
>
> Thank you for this work!  The draft is clear and to the point.  I am
> sorry it took me so long to get to it due to too many other documents
> in the queue.
>
>
> I have a general comment that I will mention up-front and several
> in-line comments/questions (below).  I will wait for at least a
> revision to start the IETF Last Call.
No problem, makes absolute sense.
> (1) Motivation -- are there other applications?
>
> The document starts by prominently using PRE to justify the work.  The
> Abstract even promises that it "details how to apply Packet
> Replication and Elimination in RPL"  However, PRE is barely mentioned
> beyond the Introduction.  The only significant mention comes in §6,
> where implementation control is recommended -- but no guidance is
> given on when or how to use it (see specific comments below).
>
> This document aims to specify the CA OF and the PS NSA extension (as
> the title mentions).  PRE may have been the original inspiration, just
> that.  But, IMHO, the document shouldn't be centered around it -- we
> could even eliminate §6.
At this point we are having some thoughts as well. We think that
completely removing §6 may be unwarranted but definitely you are
right about the issue of focus. For us PRE is quite important because
it is the the feature which along with the use of APs enables higher
reliability. However, there are other features (as you mention below)
for which PRE is not necessary. So a re-focusing, without changing
necessarily the technical content is definitely a good idea.
> Are there other potential users of these extensions?  Thinking out
> loud...  The AP can be used as a load-sharing path (at least until the
> traffic reaches a CA).  The AP could also be used as a pre-calculated
> backup path.
We are in complete agreement, and we will shamelessly borrow your
ideas. We had reliability and availability as our primary concerns when
designing this, but load-balancing is also a very good point as well as
protecting (or reducing to be more exact) cases of consecutive packet
losses (e.g. 4 in a row) which are particularly problematic in industrial
settings.
We will add all these.
> This comment is not a show stopper, but I think the document would
> benefit from less focus on PRE: using it as an example of potentially
> many other applications.
We are definitely open to making these changes, though we will try
to keep them manageable in scale to facilitate the next review.
> Thanks!
>
> Alvaro.
>
>
> [Line numbers from idnits.]
>
>
> ...
> 141	2.  Terminology
>
> 143	   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> 144	   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> 145	   document are to be interpreted as described in [RFC2119].
>
> [major] Use the text in rfc8174.

Sorry, missed that, of course will fix.


> 147	   The draft uses the following Terminology:
> ...
> 156	   Parent Set (PS):  Given a RPL node, the set of its neighbor nodes
> 157	      which participate in the same RPL DODAG and which can potentially
> 158	      take the role of the node's preferred parent.
>
> [minor] This term already exists in rfc6550.  It looks like the
> definition is the same, but to avoid confusion or divergence please
> point there instead.  For example: "The following terms from rfc6550
> are used in this document: PS, ...".

This is absolutely right and we will refer to RFC6550 for this.


> ...
> 169	3.  Common Ancestor AP Selection Policies
>
> 171	   In the RPL protocol, each node maintains a list of potential parents.
> 172	   For PRE, the Preferred Parent (PP) node is defined to be the same as
> 173	   the RPL DODAG Preferred Parent node.  Furthermore, to construct an
> 174	   alternative path toward the root, in addition to the PP node, each
> 175	   node in the network selects additional parent(s), called alternative
> 176	   parent(s), from its Parent Set (PS).
>
> [minor] "For PRE, the Preferred Parent (PP) node is defined to be the
> same as the RPL DODAG Preferred Parent node."
>
> IOW, there isn't really a PRE PP, just a PP, as defined in rfc6550, right?
>
> Suggestion>
>     PRE uses the RPL DODAG Preferred Parent node.
>
> [** See related comment below in §4. **]
Yes, you are right. We basically use the normal /default / vanilla RPL
preferred parent (PP) as usual, and then go on to add the Alternative
Parent on top. But the PP in CA OF is the same as the default PP.
> [nit] "additional parent(s)"  §2 uses "Additional Parents"
> capitalized.  Please be consistent when using defined terms.
Oops, sorry, will of course fix this and re-do a pass to make sure we 
didn't miss
nothing else of similar nature.
> ...
> 181	   All three policies defined perform AP selection based on common
> 182	   ancestors, named Common Ancestor Strict, Common Ancestor Medium, and
> 183	   Common Ancestor Relaxed, depending on how restrictive the selection
> 184	   process is.  A more restrictive policy will limit flooding but might
> 185	   fail to select an appropriate AP, while a less restrictive one will
> 186	   more often find an appropriate AP but might increase flooding.
>
> [major] Besides the consideration of more or less flooding, what other
> things should an operator keep in mind when selecting a policy?
>
> [** I revisit this question in §4.1. **]
You are right and we will address this in terms of different goals: 
availability,
reliability, load-balancing, consecutive lost packets, energy consumption,
flooding / shared resource exhaustion.
> ...
> 192	3.1.  Common Ancestor Strict
> ...
> 233	   node S can decide to use node B as its AP node, since PP(PP(S)) = Y =
> 234	   PP(B).
>
> [nit] s/node S/Node S
Thanks again, you shouldn't have been able to find errors like this so we'll
do a careful pass on the whole text again.
> [major] "node S can decide to use node B as its AP node"
>
> What do you mean by "can decide"?  If Node S is using the CA Strict OF
> then B *is* its AP node.  There's no room for other decisions.  Am I
> missing something?
>
> I can see the case where multiple nodes meet the condition -- for
> example if a new node E also has PP(E) = Y -- then I can see how node
> S "can decide" to use one or the other.  Are you implying that the
> result of the policy is somehow optional?

You are absolutely right. There are no other options in this specific
example, though it obviously can happen more generally that there
may be multiple nodes meet the condition. No, the policy is not
optional. The "can decide" incorrectly,in this example, refers to the
choice between multiple condition-meeting nodes.

Will fix it to clarify it beyond doubt.

> [major] BTW, if there was more than one option, how would node S make
> that tie-breaking decision?
The candidate with the lowest rank as per the OF will be chosen. If 
there are
multiple such nodes it is left undefined / is the implementation's 
choice, since
from the point of view of RPL OF used, the candidates are exactly 
equivalent.
> 236	3.2.  Common Ancestor Medium
> ...
> 251	   node S can decide to use node B or D as its AP node.
>
> [nit] s/node S/Node S
Thanks!
> [] Same questions about "can decide" and multiple nodes that satisfy
> the condition.

No, the policy is not optional. The "can decide" incorrectly, in this 
example,
refers to the choice between multiple condition-meeting nodes.

Will fix it to clarify it beyond doubt.

> 253	3.3.  Common Ancestor Relaxed
> ...
> 269	   node S can decide to use node A, B or D as its AP node.
>
> [nit] s/node S/Node S
Thanks!
> [] Same questions about "can decide".
No, the policy is not optional. The "can decide" incorrectly, in this 
example,
refers to the choice between multiple condition-meeting nodes.

Will fix it to clarify it beyond doubt.

> [major] How would node S select between A, B, and D?
The candidate with the lowest rank as per the OF will be chosen. If 
there are
multiple such nodes it is left undefined / is the implementation's 
choice, since
from the point of view of RPL OF used, the candidates are exactly 
equivalent.

> 271	4.  Common Ancestor Objective Function
>
> 273	   An OF which allows the multiple paths to remain correlated is
> 274	   detailed here.  More specifically, when using this OF a node will
> 275	   select an AP node close to its PP node to allow the operation of
> 276	   overhearing between parents.  For more details about overhearing and
> 277	   its use in this context see the "Complex Track with Replication and
> 278	   Elimination" in Section 4.5.3 of [I-D.ietf-6tisch-architecture].  If
> 279	   multiple potential APs match this condition, the AP with the lowest
> 280	   rank will be registered.
>
> [minor] "a node will select an AP node close to its PP node to allow
> the operation of overhearing between parents"
>
> How is this used in the policies defined in §3?  Are you referring to
> physical distance or inferring proximity based on the selection
> policy?
Thanks for the comment. I guess we were not clear here. We have no
intention of introducing any geographical / physical location tracking.
The idea is that, as a rough estimate, we *hope* that nodes with similar
ranks will be closer together, increasing the likelihood of overhearing
being taken advantage of, but there is no way to ascertain this.
The basic intuition is that candidate parent nodes which have common
parents themselves and which are also accessible from the source node
should be physically close, though it's of course not guaranteed.
We can clarify this notion of "closeness".
> [] "the AP with the lowest rank will be registered."
>
> Is this the tie-breaker for the policies in §3?
Yes. We will clarify this. Thanks!
> 282	   The OF described here is an extension of The Minimum Rank with
> 283	   Hysteresis Objective Function [MRHOF].  In general, this OF extends
> 284	   MRHOF by specifying how an AP is selected.  Importantly, the
> 285	   calculation of the rank of the node through each candidate neighbor
> 286	   and the selection of the PP is kept the same as in MRHOF.
>
> [minor] "Importantly, the...selection of the PP is kept the same as in MRHOF."
>
> §3 says that "For PRE, the Preferred Parent (PP) node is defined to be
> the same as the RPL DODAG Preferred Parent node."  I made a comment
> there about clarifying that the PP was selected according to rfc6550
> -- but the text here talks about using rfc6719 instead.  Please
> clarify.
>
> [major style nit] Personally, I prefer using references in the form of
> "[RFCxxx]" instead of a name, for example "[MRHOF]".  In this case,
> the reference to "MRHOF" is used both as a reference to rfc6719 and as
> an abbreviation.  The result is that the rest of the text is not clear
> as to whether you're extending the objective function defined in
> rfc6719, or rfc6719 itself (as in a formal Update).
Thanks, we have no real preference either way so we can easily switch to
your preferred style.

We are not doing a formal update of rfc6719. We are re-using the existing
definition of MRHOF in rfc6719 to build a new OF which provides
additional functionality, and to ease implementation and compatibility
we maintain the existing functionality of MRHOF for the preferred parent.

> The RFC Style Guide (rfc7322) says this:
>
>     3.6.  Abbreviation Rules
>
>     Abbreviations should be expanded in document titles and upon first
>     use in the document.  The full expansion of the text should be
>     followed by the abbreviation itself in parentheses.
>
> s/The Minimum Rank with Hysteresis Objective Function [MRHOF]/the
> Minimum Rank with Hysteresis Objective Function (MRHOF) [RFC6719]
>
> Please use "[RFC6719]" as the reference throughout.
We will, thanks a lot and sorry.
> [major] I am assuming that this document doesn't intend to formally
> Update rfc6719.  Instead, it defines a new OF (with a different OCP)
> based on MRHOF.  Is that correct?
Yes, you guessed correctly and we clarify it in a previous answer. We
will make to super clear about this in the revised version.
> 288	   The ways in which the CA OF modifies MRHOF in a section-by-section
> 289	   manner follows in detail:
>
> [minor] s/CA OF modifies MRHOF/CA OF differs from MRHOF
Will fix, thanks a lot.
> ...
> 298	   [MRHOF], Section 3 "The Minimum Rank with Hysteresis Objective
> 299	   Function":
> 300	      Same as MRHOF extended to AP selection.  Minimum Rank path
> 301	      selection and switching applies correspondingly to the AP with the
> 302	      extra CA requirement of having some match between ancestors.
>
> [] "extra CA requirement of having some match between ancestors"
>
> You're referring to the policies defined §3, right?  If so, please say so.
Yes, definitely, and we will be more explicit to to avoid any potential 
confusion.
> 304	   [MRHOF], Section 3.1 "Computing the Path Cost":
> 305	      Same as MRHOF extended to AP selection.  If a candidate neighbor
> 306	      does not fulfill the CA requirement then the path through that
> 307	      neighbor SHOULD be set to MAX_PATH_COST, the same value used by
> 308	      MRHOF.  As a result, the node MUST NOT select the candidate
> 309	      neighbor as its AP.
>
> [minor] s/the path...set to MAX_PATH_COST/the path cost...set to MAX_PATH_COST
Thanks, and sorry. Will fix it.
> [major] "SHOULD be set to MAX_PATH_COST...MUST NOT select"
>
> When is it ok to not set the path cost to MAX_PATH_COST?  Why is this
> action recommended and not required?
>
> I realize that rfc6719 also only recommends the setting.  This is the
> text from §3.1:
>
>     If the selected metric is a link metric and the metric of the link to
>     a neighbor is not available, the path cost for the path through that
>     neighbor SHOULD be set to MAX_PATH_COST.  This cost value will
>     prevent this path from being considered for path selection.
>
> The difference is that the text in rfc6719 goes on to say what the
> expected result of setting the cost to MAX_PATH_COST is -- in a
> non-normative way.
>
> OTOH, this document follows up by saying that "As a result, the node
> MUST NOT select the candidate neighbor as its AP."  So -- the required
> action to not select is contingent on the recommended action of
> setting the cost.  What are the cases when it is ok to not use
> MAX_PATH_COST?
>
> [Even if you use the wording from rfc6719 I will still want to know
> when it is ok to not use MAX_PATH_COST.]
Thanks a lot for his great catch. You are of course right. Our intention was
to ape the RFC6719 definition, but we failed... We tried to avoid too much
copy paste in order to avoid also our text becoming obsolete if/when RFC6719
is updated. Our intention was to do exactly as MRHOF would do (whether
setting the the cost to MAX_PATH_COST or not). So the "As a result, the node
MUST NOT select the candidate neighbor as its AP." should be removed, 
and left
to the lowest-rank selection mechanism to deal with that cost in the 
same way that
it is dealt with in MRHOF.
We will update this. Again, thanks for the great catch!
> ...
> 319	   [MRHOF], Section 3.2.2 "Parent Selection Algorithm":
> 320	      Same as MRHOF extended to AP selection.  If the smallest path cost
> 321	      for paths through the candidate neighbors is smaller than
> 322	      cur_ap_min_path_cost by less than PARENT_SWITCH_THRESHOLD (the
> 323	      same variable as MRHOF uses), the node MAY continue to use the
> 324	      current AP.  Additionally, if there is no PP selected, there MUST
> 325	      NOT be any AP selected as well.  Finally, as with MRHOF, a node
> 326	      MAY include up to PARENT_SET_SIZE-1 additional candidate neighbors
> 327	      in its alternative parent set.  The value of PARENT_SET_SIZE is
> 328	      the same as in MRHOF.
>
> [minor] s/MUST NOT be any AP selected as well/MUST NOT be any AP selected either
Thanks again! Will fix.
> ...
> 336	   [MRHOF], Section 3.5 "Working without Metric Containers":
> 337	      It is not possible to work without metric containers, since CA AP
> 338	      selection requires information from parents regarding their parent
> 339	      sets, which is transmitted via the NSA object in the DIO Mectric
> 340	      Container.
>
> [major] "It is not possible to work without metric containers..."
>
> What if the metric container is not present?  Is this one of the risks
> that should also be mentioned in the Security section?
You are right, we assumed that writing what is required (MUST) is 
sufficient, and
specifying fallback options is not necessary if the requirements are not 
met.
Basically, we were ready to allow implementation-defined behavior when
operating outside of the required parameters.
Maybe we should specify that a lack of metric container SHOULD lead to 
the use
of MRHOF (i.e with no AP). This way we recommend a full MRHOF 
implementation
to be available to fall back on, but if such an implementation is 
undesirable or
another fallback OF is preferable, that instead can be used.
> ...
> 353	      Alternative parent set:  Corresponding to the MRHOF parent set.
> 354	         The size is defined by the same PARENT_SET_SIZE parameter as in
> 355	         MRHOF.  The Alternative parent set MUST be a non-strict subset
> 356	         of the parent set.
>
> [major] "MUST be a non-strict subset of the parent set"
>
> Maybe I don't understand the full meaning of non-strict, but the AP
> set should at least not include the PP, right?  That means that the AP
> set has to be a strict subset of the parent set.  What am I missing?
Our bad, you're absolutely right. It needs to be strict subset of the 
parent set.
> 358	      cur_ap_min_path_cost:  Corresponding to the MRHOF
> 359	         cur_min_path_cost variable.  To support the operation of the
> 360	         hysteresis function for AP selection.
>
> [major] "Corresponding to the MRHOF cur_min_path_cost variable."
>
> This is an additional variable which is similar to cur_min_path_cost,
> right?  IOW, you're not replacing one with the other.
Exactly, this is not a typo and we are not replacing the original, but to
replicate the relevant functionality available in MRHOF for the PP onto the
AP in CA OF.
Not sure if we should highlight this.
> ...
> 371	4.1.  Usage
>
> 373	   All OF policies apply their corresponding criterion to filter the
> 374	   list of candidate neighbours in the alternative parent set.  The AP
> 375	   is then selected from the alternative parent set based on Rank and
> 376	   using hysteresis as is done for the PP in MRHOF.  It is noteworthy
> 377	   that the OF uses the same Objective Code Point (OCP): TBD1 for all
> 378	   policies used.
>
> [minor] s/All OF policies/All Common Ancestor AP Selection Policies (Section 3)
Thanks again. Will fix that.
> [minor] s/Objective Code Point (OCP): TBD1/Objective Code Point (OCP) (TBD1)
>
>
> 380	   The PS information can be used by any of the described AP selection
> 381	   policies or other ones not described here, depending on requirements.
> 382	   It is optional for all nodes to use the same AP selection policies.
> 383	   Different nodes may use different AP selection policies, since the
> 384	   selection policy is local to each node.  For example, using different
> 385	   policies can be used to vary the transmission reliability in each
> 386	   hop.
>
> [] It is ok to not require the same policy for on all nodes, but it
> opens questions about policy selection and configuration (below).
>
> [major] Operational Considerations: How should an operator choose
> which policy to apply where?  I understand the difference with respect
> to the strictness, but what makes a policy appropriate for a specific
> situation.  For example, (just making this up) should more strict
> policies be applies closer to the edge (leaves) of the network where
> there's a greater probability of common GP?
>
> I later found Appendix B...  Please reference it from here.
Will do. Thanks.
> [major] How are the different policies provisioned at different nodes?
>   In many instances the root decides about the behavior of the DODAG
> and propagates that information (all do the same).  But in this case
> all nodes won't have the same configuration.  How is that provisioned?
There are a lot of degrees of freedom in approaching this so
providing some rough suggestions in the Appendix was what
we though would be the appropriate degree of detail.
Do you think that more should be explained?
Provisioning is both complicated and very dependent on what
one wants to do. Even using the DIO, one could extend it
to carry multiple rank-specific or node-specific policies. E.g.:
For ranks < 1000: apply policy X
For ranks < 2000: apply policy Y
...
We are not sure how much can be specified without hamstringing
some potential implementations.
> 388	5.  Node State and Attribute (NSA) object type extension
> ...
> 455	   The structure of the DAG Metric Container data in the form of a Node
> 456	   State and Attribute (NSA) object with a TLV in the NSA Optional TLVs
> 457	   field is shown in Figure 3.  The first 32 bits comprise the DAG
> 458	   Metric Container header and all the following bits are part of the
> 459	   Node State and Attribute object body, as defined in [RFC6551].  This
> 460	   document defines a new TLV, which MAY be carried in the Node State
> 461	   and Attribute (NSA) object Optional TLVs field.  The TLV is named
> 462	   Parent Set and is abbreviated as PS in Figure 3.
>
> [major] "MAY be carried"
>
> It is an optional TLV.  However, in the context of this document it is
> required to convey the PS.  I would prefer it if the text mentioned
> that: "MUST be carried to indicate the PS...".
Yes, this makes a lot of sense. We were reticent to putting a MUST there
since exactly it is to be carried in the NSA object *Optional* TLVs field.
We will change it to reflect that within the context of the use of the 
CA OF,
this is a mandatory field.
> [related] If the network is using the CA OF, what does it mean for the
> TLV to not be present?  Everyone has a parent...well, except for the
> root...
This is similar to the question of not having a metric container.
Do we specify that the recommended choice is to fall back to MRHOF,
and if that is not available to any other OF, disregarding CA OF, or
should we leave this unspecified?
> ...
> 466	   PS Length:  The total length of the TLV value field (PS IPv6
> 467	         address(es)) in bytes.  The length is an integral multiple of
> 468	         16, the number of bytes in an IPv6 address

We think the comment for this got cut-off.


Thank you again for the detailed read-up and comments.
We plan to very quickly get all the issues sorted.

Best,
Aris & Georgios