Skip to main content

Early Review of draft-ietf-6lo-path-aware-semantic-addressing-05
review-ietf-6lo-path-aware-semantic-addressing-05-genart-early-kyzivat-2024-04-29-00

Request Review of draft-ietf-6lo-path-aware-semantic-addressing-05
Requested revision 05 (document currently at 09)
Type Early Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2024-05-15
Requested 2024-04-24
Requested by Carles Gomez
Authors Luigi Iannone , Guangpeng Li , Zhe Lou , Peng Liu , Rong Long , Kiran Makhijani , Pascal Thubert
I-D last updated 2024-04-29
Completed reviews Genart Early review of -05 by Paul Kyzivat (diff)
Rtgdir Early review of -06 by Joel M. Halpern (diff)
Comments
We would like to request a review of the draft before considering WGLC in the 6lo WG.
The Gen-ART review may be useful, among others, to assess the general readability of the document. 
The Routing Area Directorate review may be useful, among others, since the document contains a stateless forwarding component for multihop network topologies.
Thanks in advance for your valuable input.
Assignment Reviewer Paul Kyzivat
State Completed
Request Early review on draft-ietf-6lo-path-aware-semantic-addressing by General Area Review Team (Gen-ART) Assigned
Posted at https://mailarchive.ietf.org/arch/msg/gen-art/MDm-ECT4Eyd-xEt1nl35wHV4TtQ
Reviewed revision 05 (document currently at 09)
Result Ready w/issues
Completed 2024-04-29
review-ietf-6lo-path-aware-semantic-addressing-05-genart-early-kyzivat-2024-04-29-00
I am the assigned Gen-ART reviewer for this draft.
For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-6lo-path-aware-semantic-addressing-05
Reviewer: Paul Kyzivat
Review Date: 2024-04-29
IETF LC End Date: TBD
IESG Telechat date: TBD

Summary:

This draft is on the right track but has open issues, described in the 
review.

This review was challenging for me because I know nothing of the subject 
area or any of the important references. I apologize for any stupid 
comments based on my lack of context.

Below I have not attempted to classify the severity of issues other than 
Nits vs. Issues.

ISSUES:

1) ISSUE: Router parents

In section 3 (Definition of Terms), in PASA Router:

Doesn't the router, like the host, request an address from its parent? 
If so then it should be stated.

In PASA Host:

s/to its selected parent/from its selected parent/ ???

2) ISSUE: Working of OT network domains

In section 4.4 Industrial Operational Technology Networks, regarding 
"The OT network is represented as PASA domain", I think you mean "The OT 
network is represented as *a* PASA domain".

In this domain do each of the sensors/actuators have an assigned PASA 
address so that the IPv6 nodes can address them directly?

IOW, does the PLC act as a PASA Router by assigning PASA addresses for 
each of the sensors/actuators? (Even though they don't carry out the 
steps for PASA Hosts.) It would be helpful for the document to be 
clearer about this.

3) ISSUE: Multiple Root Nodes

In section 5 (Architectural Overview) the description of PASA Root says 
"There is typically one root node in the PASA network". Using 
"typically" implies there may be exceptions where there are multiple 
root nodes. But I have the impression that this spec won't work right if 
there is more than one. Do you really want to define that?

4) ISSUE: Address Assignment

I have concerns about address assignment as described in section 5 
(Architectural Overview):

               ...  Each node acquiring a PASA address firstly needs to
    select a parent node by choosing among the nodes that replied with a
    Router Advertisement (RA) after an initial Router Solicitation (RS).
    A "first come first served" selection policy is sufficient.  Then it
    asks for a PASA address.  In its reply the parent will propose an
    address according to the node's role, which is indicated in the D-bit
    of the GAAO message (see Section 10).  The proposed address is
    algorithmically calculated using the PASA Address Assignment Function
    (AAF).

Is this algorithm stable if there are multiple replies to the RS 
message? IOW, will the same address be assigned regardless of the router 
chosen. This goes back to my question if you want to allow redundant 
routers.

5) ISSUE: Root Node Address

Figure 6 starts out with:
                             root           +--------------------------+
                                  1         | append more bits to form |
                                  O ----+   | brother's address        |

Subsequent discussion says the root address is "1". So why is the "0" 
present?

However the AAF algorithm always assigns addresses ending in "0" to 
routers. Wouldn't it be more consistent to give the root the address 
"0"? (Or does the address packing/unpacking described in section 7 
require the root address to begin with a "1" bit?)

6) ISSUE: Tree Address Assignment Function

In section 6.1 (Tree Address Assignment Function) the function is 
defined as "AAF(role, r, h)" but all the following examples show it as 
A(...). Please be consistent.

Also I don't understand *when* the AAF function is run for a particular 
node. It is when a particular node seeks its parent and then asks for an 
address, but does it every time it restarts? That doesn't seem 
deterministic. What if nodes start or restart at indeterminant times? I 
suspect you are making some assumptions that aren't stated. Please clarify.

7) ISSUE: Packet forwarding

In section 7.1 all the steps reduce to either "send to parent" or send 
to a particular child. How? I presume this requires a MAC address, but 
there has been no mention of these. It seems to require all nodes to 
keep a MAC address of their parent and routers to keep a MAC for each 
child with an assigned PASA address. This state hasn't been discussed.

8) ISSUE: PASA address padding

In section 8.2 (PASA-6LoRH Format) you say "PASA addresses are aligned 
on the least significant bits." But your example AAF assigns variable 
length addresses that are left aligned. I think these can only be 
reconciled by requiring the root node address to begin with a "1" bit 
and then left aligning to the first "1" bit when unpadding. One way or 
another you need to have a way to determine the bit length of the AAF 
address when unpadding.

9) ISSUE: Node role indication

In section 9 (Nodes role indication) you say "Nodes not setting both B 
and L bits are considered PASA Nodes." But I think you mean "Nodes with 
neither the B nor L bit set are considered PASA Nodes."

10) ISSUE: IANA registration

In section 11.2 (PASA Address Assignment Function) I couldn't find the 
IANA "Generic Address Assignment Option Parameters" registry. Do you 
intend to have it created? If so you need to request that.

11) ISSUE: Reliability Consideration

In section 12 (Reliability Considerations) as I mentioned above, I'm 
concerned that simple variability in the order that nodes start up may 
result in inconsistent address assignment. Hopefully I'm wrong about 
this. Can you explain this to me?

NITS:

In section 1 (Introduction), in "This document introduces a 
topology-based addressing mechanism with that allows".

s/with that/that/

In Figure 5, There is an extra space after "PASA Domain" that messes up 
the line art.

Section 7.1 (Forwarding toward a local PASA endpoint) starts with 
"Inner-domain packets carry ...". From context I conclude you mean 
"Intra-domain packets carry ..."

In section 7.2 (Forwarding toward an external IPv6 address), in "When 
the network forwarding operation are based on [RFC8138]",

s/operation are based/operation is based/
or
s/operation are based/operations are based/

In section 10 (PASA Address Configuration Procedure), in "The requester 
MUST indicate its role as indicated in {SEC:role}", what is 
"{SEC:role}"? I don't find any other mention of it. Is it intended to be 
an internal cross reference?

In section 13 (Security Considerations),

s/rouge/rogue/

In section 14 (Privacy Considerations),

s/buildbased/build based/
s/avoid expose/avoid exposing/

That's all!