"SHOULD be set to MAX_PATH_COST...MUST NOT select"

[ariskou]

Context:

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.

---

Issue description:

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

---

UID_13_2

[ariskou]

From the Authors:
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!

[ariskou]

From the Authors:
We have removed the "As a result, the node MUST NOT select the candidate neighbor as its AP.".
However, we have not answered yet when it is ok to not use MAX_PATH_COST, since this is not clear to us either.
Leaving this issue open for now to address this.

[ariskou]

Hey @pthubert, could you give us a bit of feedback here?

[pthubert]

I'm good with MUST NOT

[dbarthel-ol]

The feedback Aris was asking for on Aug 30th is about "What are the cases when it is ok to not use MAX_PATH_COST?"

[pthubert]

Same old, if that's the only parent then you cannot omit it. It might be that there's no parent or no alt parent that satisfies the common ancestor. The node still needs to parent.

[ariskou]

After this discussion we agree that we need to specify:

1. "the node MUST NOT select the candidate neighbor as its AP"
2. "that neighbor SHOULD be set to MAX_PATH_COST" -> "that neighbor MUST be set to MAX_PATH_COST"

The cumulative effect of the two is that in the case of the Alternative Parent, we will never select an AP if it does not fulfill the CA requirement. We are able to be stricter in the case of the AP, since not having an AP is tolerable. On the contrary, it seems that in the case of the Preferred Parent, as defined in MRHOF, there may be cases where even if the requirements are not fulfilled, a candidate may still be selected as PP.