Hi Paul, Thank you a lot for your review. Please find comment s directly inline. Please let us know if you agree with the proposed changes.
Ciao L. > -----Original Message----- > From: Paul Kyzivat <pkyzi...@alum.mit.edu> > Sent: Tuesday, 30 April 2024 01:06 > To: draft-ietf-6lo-path-aware-semantic-addressing....@ietf.org > Cc: General Area Review Team <gen-...@ietf.org>; 6lo@ietf.org > Subject: Gen-ART Early review of draft-ietf-6lo-path-aware-semantic- > addressing-05 > > 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. [LI] Good point. What about switching PASA Router and PASA Host, so to have the host first and modifying the PASA router text as follows: PASA Router: A PASA Router is an internal node, different from the PASA Root, acting as a router, hence as what [RFC8505] names 6LR (6LowPAN Router). Before acting as a router it will act as a PASA Host so to acquire and address. Then, similar to the PASA Root, it uses the Tree Address Assignment Function (TAAF) and performs the address assignment for its children. Would this work? > > In PASA Host: > > s/to its selected parent/from its selected parent/ ??? [LI] Thanks for catching this. We will fix it as suggested. > > 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". [LI] Thanks for catching this. We will fix it as suggested. > > In this domain do each of the sensors/actuators have an assigned PASA > address so that the IPv6 nodes can address them directly? [LI] Yes > > 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. [LI] It depends whether the end-device supports or not IPv6. May be modifying the text as: * In an idealized PASA-based OT domain, a leaf-node could be a field device (sensor or actuator) that always connects to PLC serving as last node forwarding traffic to/from the leaves, i.e. sensors and actuators. Hence, the PLC will work as a PASA Router only for field devices supporting IPv6. Would that work? > > 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? [LI] Not really. Multiple roots are needed only in case of reliability issues, but you can use existing solutions. We will delete 'typically" and add a comment in section 12. > > 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. [LI] No, depending on the parent selected the address will be different since the topology will be different. There is only one router selected as default gateway. Do you prefer that we add an explicit sentence ?? > > 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? [LI] That is actually an "O" not a "zero". But is true that it can be misleading. [LI] We will change the figure to avoid such an issue. A solution could be to frame the addresses like: root +---+ +--------------------------+ | 1 | | append more bits to form | +----+ | brother's address | / | \ Better? > > 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?) [LI] This is related to the previous issue. Hope with the new figure everything will be clearer. > > 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. [LI] Good point. We will fix this. > > 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. [LI] Excellent point. According to RFC 8505 every node has to keep addressing state in non-volatile memory so that in case of reboot the node can re-register the same address, not asking for a new one. We can fix this in several points: Section 5: append the following sentence to the paragraph finishing with the sentence " The node will then ignore replies from other 6LR neighbors.": According to [RFC 8505] nodes have store in non-volatile memory the PASA address configuration state, so that in case of reboot, they just re-register the address without asking for a new one. Section 6.1 : add the sentence: The indexes r and h MUST be stored in non-volatile memory so that in case of reboot a PASA-Router can continue its role without disruptive addressing. Section 10: change the sentence: When a PASA node bootstraps, it typically does multicast a Routing Solicitation(RS)... To: When a PASA node bootstraps, and it has address configuration state in its non-volatile memory, it will re-register the address to its parent using [RFC 8505] procedures. Otherwise, it will multicast a Routing Solicitation(RS).... Add a sentence ass well in section 12 about reliability (See issue 11). > > 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. [LI] That is correct. PASA leverages on RFC 8505 as mentioned elsewhere. We can add the reference here as well. > > 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. [LI] What we means is that no matter the length the address is put on the least significant bits and the we add on the left as many bits are necessary to achieve a multiple of 8 bits. [LI] may be the sentence should be: PASA addresses are padded so to have a length that is a multiple of 8 bits. The padding is done by adding a sufficient number of bits, with value zero, in the most significant bits of the bit string, so that the PASA address occupies the least significant bits. Is this sufficiently precise? > > 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." > [LI] That is correct. Thanks for the suggestion. > 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. [LI] That registry will be created by [I-D.iannone-6lo-nd-gaao], which is advancing in parallel. > > 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? [LI] This is also related to the point you made in issue 6. Here after an improved Section 12, which, with the other changes described in issue 6, will hopefully address your concerns. 12. Reliability Considerations Because PASA uses algorithmically generated addresses based on the network topology, nodes do not generate and store forwarding table entries in the normal case. They are limited to have a default gateway and the ND table. One of the potential issues is the risk of renumbering of addresses in case of topology changes. Because of the applicability domain of PASA, the common case of topology change is known in advance and can be planned, so to reduce disruption due to renumbering. Another case is temporary link failures or node temporary failures, where the underlying technology is still able to provide connectivity through alternative links, which is strictly related to the underlying technology, the network topology, the deployed redundancy, and the expected reliability. Failures may raise the issue of topology changes and re-numbering. Such an issue can be avoided following the procedures in [RFC8505] keeping state in non-volatile memory. More complex reliability scenarios, including the case for multiple root nodes and alternative solutions, are beyond the scope of this document, which is focused only on the address allocation framework and stateless forwarding. Furthermore, specific reliability solutions can depend as well on the specific Address Assignment Function used (different from the one presented in this document). Reliability is discussed in more details in [I-D.li-6lo-pasa-reliability]. > > NITS: [LI] Thanks catching these. We will fix them. > > 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
