[Roll] Rtgdir last call review of draft-ietf-roll-nsa-extension-11

[Alvaro Retana via Datatracker <[e-mail]>]

Reviewer: Alvaro Retana
Review result: Has Issues

Subject: RtgDir Early Review of draft-ietf-roll-nsa-extension-11

Hi!

I have been selected to do a routing directorate "early" review of this draft.
https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/

The routing directorate will, on request from the working group chair, perform
an “early” review of a draft before it is submitted for publication to the
IESG. The early review can be performed at any time during the draft’s lifetime
as a working group document. The purpose of the early review depends on the
stage that the document has reached.

As this document is close to working group last call, my focus for the review
was to determine whether the document is ready to be published. Please consider
my comments along with the other working group last call comments.

For more information about the Routing Directorate, please see
https://wiki.ietf.org/en/group/rtg/RtgDir

I performed a review of this document over a year ago [1].  I am doing this
review based on my original comments.

Thanks!

Alvaro.

[1] https://mailarchive.ietf.org/arch/msg/roll/QTnFl5T7KlbiST8xSC2zrfJLDKA/

Document: draft-ietf-roll-nsa-extension-11
Reviewer: Alvaro Retana
Review Date: Oct. 4, 2023
Intended Status: Standards Track

Summary:  I have some relatively minor concerns about this document that I
think should be resolved before it is submitted to the IESG.

Comments: I'm providing comments in line with the latest text (see below).

[Line numbers from idnits.]

...
166     3.  Common Ancestor AP Selection Policies
...
191        If after the filtering there are multiple condition-meeting candidate
192        nodes, the node MUST decide to use at least one of them as its AP
193        node.  The way this choice is made depends on which OF is used.  If
194        the CA OF is used, the way this choice is made is described in
195        Section 4.

[major nit] "MUST decide to use at least one of them as its AP node"

The action you want to enforce is the selection, not the decision.  Perhaps
something like this: MUST select at least one...

There are 2 more occurrences of "MUST decide".

...
277     4.  Common Ancestor Objective Function

279        An OF which allows the multiple paths to remain correlated is
280        detailed here.  More specifically, when using this OF a node will
281        select an AP node "close" to its PP node to allow the operation of
282        overhearing between parents.  Closeness here is not strictly defined,
283        however, the premise is that those candidate parent nodes that have
284        common parents themselves have a higher probability of being within
285        each other's radio range, though it's of course not guaranteed.  For
286        more details about overhearing and its use in this context see the
287        "Complex Track with Replication and Elimination" in Section 4.5.3 of
288        [RFC9030].  If multiple potential APs match this condition, the AP
289        with the lowest rank will be registered.

[major] What should happen if multiple APs have the same rank?

I understand that the next step may be intended to be left to be
implementation-specific.  Please say so.

...
321        [RFC6719], Section 3.1 "Computing the Path Cost":
322           Same as MRHOF extended to AP selection.  If a candidate neighbor
323           does not fulfill the CA requirement then the path cost through
324           that neighbor SHOULD be set to MAX_PATH_COST, the same value used
325           by MRHOF.

[major] When is it ok not to set the path cost to MAX_PATH_COST?

I know there's an open issue and an action item from the last interim meeting.

https://github.com/roll-wg/draft-ietf-roll-nsa-extension/issues/28
https://datatracker.ietf.org/doc/minutes-interim-2023-roll-01-202309211300/

...
500     5.1.  Usage

502        The PS SHOULD be used in the process of parent selection, and
503        especially in AP selection since it can help the alternative path to
504        not significantly deviate from the preferred path.  The Parent Set is
505        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 not to 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 the downstream's
efforts to figure out their GP...

The best solution may be: s/PS SHOULD be used/PS is used

...
515        The presence of incorrectly configured flags MUST render the Parent
516        Set TLV invalid.  This case MUST be handled the same as having valid
517        flags and a valid Parent Set TLV with no addresses in the PS IPv6
518        address(es).

520        The presence of a PS Length value that is not a multiple of 16 or
521        larger than 240 MUST render the Parent Set TLV invalid.  This case
522        MUST be handled the same as a valid Parent Set TLV with no addresses
523        in the PS IPv6 address(es).

[major] In the last two paragraphs: "MUST be handled the same as a valid Parent
Set TLV with no addresses in the PS IPv6 address(es)"

How is that case handled?  You require a behavior that is not specified.

Let me try and work through this.  Not including "addresses in the PS IPv6
address(es)" field means that the PS length has to be set to 0.  Otherwise, we
have a different error.  The text in §4 about not having metric containers
seems better: "equivalent to operating with a Parent Set TLV where there are no
PS IPv6 addresses and the PS Length is 0."

[EoR -11]