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!