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]