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

[Alvaro Retana <[e-mail]>]

Ping!

On March 17, 2022 at 1:33:05 PM, Alvaro Retana ([e-mail])
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.

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

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.

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.


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.


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


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


[nit] "additional parent(s)"  §2 uses "Additional Parents" capitalized.
Please be consistent when using defined terms.


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


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


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


[major] BTW, if there was more than one option, how would node S make that
tie-breaking decision?


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

[] Same questions about "can decide" and multiple nodes that satisfy the
condition.


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


[] Same questions about "can decide".


[major] How would node S select between A, B, and D?


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?


[] "the AP with the lowest rank will be registered."

Is this the tie-breaker for the policies in §3?


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

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.


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


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


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


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


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


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


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


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


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.


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


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


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


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


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


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

[major] If my math is correct, the length cannot be larger than 240.  What
should the receiver do if the length is not a multiple of 16 or more than
240?


[minor] Is 0 a valid length?  What does it mean to not have parents?


470   PS IPv6 address(es)  One or more 128-bit IPv6 address(es) without any
471         separator between them.  The field consists of one IPv6 address
472         per parent in the parent set.  The parent addresses are listed
473         in decreasing order of preference and not all parents in the
474         parent set need to be included.  The selection of how many
475         parents from the parent set are to be included is left to the
476         implementation.  The number of parent addresses in the PS IPv6
477         address(es) field can be deduced by dividing the length of the
478         PS IPv6 address(es) field in bytes by 16, the number of bytes
479         in an IPv6 address.

[] I am surprised that these addresses were not compressed.


481 5.1.  Usage

483   The PS SHOULD be used in the process of parent selection, and
484   especially in AP selection, since it can help the alternative path to
485   not significantly deviate from the preferred path.  The Parent Set is
486   information local to the node that broadcasts it.

[major] "PS SHOULD be used"

What are the cases where it should not be used, or when it is ok to not use
it?  In the context of this document, why is the use recommended and not
required?

The CA policy is defined per-node...and also (from above) the propagation
of the PS is not required.  Not propagating the PS may undermine any
efforts the downstream has to figure out their GP...


488   The PS is used only within NSA objects configured as a metric,
489   therefore the DAG Metric Container field "C" MUST be 0.
490   Additionally, since the information in the PS needs to be propagated
491   downstream but it cannot be aggregated, the DAG Metric Container
492   field "R" MUST be 1.  Finally, since the information contained is by
493   definition partial, more specifically just the parent set of the DIO-
494   sending node, the DAG Metric Container field "P" MUST be 1.

[major] What should a receiver do if the PS is included but the flags are
not set correctly?


496   It is important that the PS does not affect the calculation of the
497   rank through candidate neighbors.  It is only used with the CA OF to
498   remove nodes which do not fulfill the CA OF criteria from the
499   candidate neighbor list.

[] I'm not sure what you're trying to get to with the first sentence.  Are
you saying that the PS shouldn't be used for anything else?  How can you
prevent that?  What if in the future there's a new use?


501 6.  Controlling PRE

503   PRE is very helpful when the aim is to increase reliability for a
504   certain path, however its use creates additional traffic as part of
505   the replication process.  It is conceivable that not all paths have
506   stringent reliability requirements.  Therefore, a way to control
507   whether PRE is applied to a path's packets SHOULD be implemented.
508   For example, a traffic class label can be used to determine this
509   behavior per flow type as described in Deterministic Networking
510   Architecture [RFC8655].

[major] "a way to control whether PRE is applied to a path's packets SHOULD
be implemented."

Why is this a recommendation and not a requirement?  Is it expected that if
PRE is available on the node that it should apply to all traffic?  Even if
the configuration knob existed, what criteria should the network operator
use to decide whether to activate PRE or not?


512 7.  Security Considerations

[major] Please indicate that the security considerations from rfc6550,
rfc6551, and rfc6719 apply.


514   The structure of the DIO control message is extended, within the pre-
515   defined DIO options.  The additional information are the IPv6
516   addresses of the parent set of the node transmitting the DIO.  This
517   use of this additional information can have the following potential
518   consequences:

520   *  A malicious node that can receive and read the DIO can "see"
521      further than it's own neighbourhood by one hop, learning the
522      addresses of it's two hop neighbors.  This is a privacy / network
523      discovery issue.

[] I would stay away from "privacy".  In general, similar information can
be gleaned by looking at the traffic and (in storing mode) holding routes.
Topology discovery inside a domain is usually not an issue.

OTOH, if you have real privacy concerns, please take a look at rfc6973 and
include a section on it.


...
532 8.  IANA Considerations

534   This proposal requests the allocation of a new value TBD1 from the
535   "Objective Code Point (OCP)" sub-registry of the "Routing Protocol
536   for Low Power and Lossy Networks (RPL)" registry.

538   This proposal also requests the allocation of a new value TBD2 for
539   the "Parent Set" TLV from the "Routing Metric/Constraint TLVs" sub-
540   registry of the "Routing Protocol for Low Power and Lossy Networks
541   (RPL) Routing Metric/Constraint" registry.

[nit] s/This proposal/This document/g


...
569 10.2.  Informative references

571   [I-D.ietf-6tisch-architecture]
572              Thubert, P., "An Architecture for IPv6 over the TSCH mode
573              of IEEE 802.15.4", Work in Progress, Internet-Draft,
574              draft-ietf-6tisch-architecture-29, 27 August 2020,
575              <https://tools.ietf.org/html/draft-ietf-6tisch-
576              architecture-29>.

== Outdated reference: draft-ietf-6tisch-architecture has been published as
   RFC 9030


...
586   [MRHOF]    Gnawali, O. and P. Levis, "The Minimum Rank with
587              Hysteresis Objective Function", RFC 6719,
588              DOI 10.17487/RFC6719, September 2012,
589              <https://www.rfc-editor.org/info/rfc6719>.

[major] This reference has to be Normative.


...
596   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
597              Requirement Levels", BCP 14, RFC 2119,
598              DOI 10.17487/RFC2119, March 1997,
599              <https://www.rfc-editor.org/info/rfc2119>.

[major] This reference, and the required one to rfc8174, have to be
Normative.

[EoR -10]