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!
_______________________________________________
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo
