Re: [6lo] Gen-ART Early review of draft-ietf-6lo-path-aware-semantic-addressing-05
Luigi IANNONE <luigi.iannone@huawei.com> Mon, 06 May 2024 11:18 UTC
Return-Path: <luigi.iannone@huawei.com>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB50C14F68B; Mon, 6 May 2024 04:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.894
X-Spam-Level:
X-Spam-Status: No, score=-1.894 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3V4Ov3IqUqem; Mon, 6 May 2024 04:18:01 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95177C14F61A; Mon, 6 May 2024 04:18:00 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.216]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4VXzMq5nXLz6JBCG; Mon, 6 May 2024 19:15:03 +0800 (CST)
Received: from lhrpeml100006.china.huawei.com (unknown [7.191.160.224]) by mail.maildlp.com (Postfix) with ESMTPS id 78F34140D26; Mon, 6 May 2024 19:17:57 +0800 (CST)
Received: from lhrpeml500002.china.huawei.com (7.191.160.78) by lhrpeml100006.china.huawei.com (7.191.160.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 6 May 2024 12:17:57 +0100
Received: from lhrpeml500002.china.huawei.com ([7.191.160.78]) by lhrpeml500002.china.huawei.com ([7.191.160.78]) with mapi id 15.01.2507.039; Mon, 6 May 2024 12:17:57 +0100
From: Luigi IANNONE <luigi.iannone@huawei.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "draft-ietf-6lo-path-aware-semantic-addressing.all@ietf.org" <draft-ietf-6lo-path-aware-semantic-addressing.all@ietf.org>, "6lo@ietf.org" <6lo@ietf.org>
Thread-Topic: Gen-ART Early review of draft-ietf-6lo-path-aware-semantic-addressing-05
Thread-Index: AQHamong9GbkdUSygEe+rvgV5YRewbGAwe5QgAOVvwCAANa04A==
Date: Mon, 06 May 2024 11:17:57 +0000
Message-ID: <5fbaff2f2f8643baa72c0f0ca9b5c00f@huawei.com>
References: <83cef4a3-9260-4b89-aa6a-c4352e0d010a@alum.mit.edu> <22f9041652ac46f98d4f38e41950d6e2@huawei.com> <8589407b-73f5-4d48-9cbb-4389a92a2aa7@alum.mit.edu>
In-Reply-To: <8589407b-73f5-4d48-9cbb-4389a92a2aa7@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.206.215.39]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/vsM1kR_I5uuBgkAYYcUoVOUtpMg>
Subject: Re: [6lo] Gen-ART Early review of draft-ietf-6lo-path-aware-semantic-addressing-05
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 May 2024 11:18:05 -0000
Hi Paul, Thank you for the more detailed comments. My answers inline. Let me know if I missed something. L. > -----Original Message----- > From: Paul Kyzivat <pkyzivat@alum.mit.edu> > Sent: Thursday, 2 May 2024 22:25 > To: Luigi IANNONE <luigi.iannone@huawei.com> > Cc: draft-ietf-6lo-path-aware-semantic-addressing.all@ietf.org > Subject: Re: Gen-ART Early review of draft-ietf-6lo-path-aware-semantic- > addressing-05 > > Luigi, > > Please find my replies inline. I'm happy with everything I didn't comment on. > > Thanks, > Paul > > On 5/2/24 5:07 AM, Luigi IANNONE wrote: > > 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 <pkyzivat@alum.mit.edu> > >> Sent: Tuesday, 30 April 2024 01:06 > >> To: draft-ietf-6lo-path-aware-semantic-addressing.all@ietf.org > >> Cc: General Area Review Team <gen-art@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? > > Generally, except for some English usage. How about: > > s/so to acquire and address/by acquiring an address/ [LI] Thanks for the suggestion. Will change accordingly. > > >> 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? > > I'm still having trouble understanding. I think you are saying that the > sensors/actuators under the PLC may or may not use IPv6 and support PASA. > If so then they will act as PASA Hosts and the PLC will act as a normal PASA > Router. Otherwise, I'm inferring that the PLC will interact with those devices > using their chosen protocols. It then will assign PASA addresses for each of > them, and then translate between PASA messages and the device protocol, > making the devices appear as PASA Hosts within the enclosing PASA Domain. > > Do I have that right? I don't think that is clear in your revised text. [LI] You got it right. What about the following (re-using part of your wording): * 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. For field devices not supporting IPv6 the PLC will assign PASA addresses for each of them, and then translate between IPv6 packets and the device protocol, making the devices appear as PASA Hosts within the enclosing PASA Domain. [LI] Clear enough? > > >> > >> 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. > > OK. But note my later comments. > > >> 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 ?? > > Can this happen if there are no redundant routers? For instance, can the > multicast reach routers for other subtrees of the domain? If so, how does > the host choose the proper one in a deterministic way? > > (Am I correct in assuming the order that responses to a multicast are > received is nondeterministic?) [LI] The assumption is correct, but note that this is the case only if there is no addressing state in the non-volatile memory (aka the very first time the node joins the network). The document states that in case of several node replying to the initial RS a "first come first served" selection policy is sufficient (in Section 5). > > I had been assuming that the typologies shown in the examples were > predetermined. For instance in Figure 2 will the doorbell always discover the > Living Room PLC-R as its router? Or after a reset might it happen to see and > choose the Kitchen PLC-R as its router? [LI] That should not happen if the cabling has been done correctly. [LI] May be we should add a sentence after the FCFS policy. Something like: "Some deployments may have tighter constrains on the router selection, but enforcing such selection is beyond the scope of this document." What do you think? > > >> > >> 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? > > Yes, better. Maybe too much when applied throughout the tree . It is the > "O" that is confusing. Perhaps simply replacing it with another > character (e.g., "^") might be sufficient. You understand why I raised > the issue so I'm confident you will find a good solution. [LI] Thanks. It is a good idea to replace the O with another (less confusing) character. > > >> 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. > > Its a different point - more of a nit than an issue. The AAF algorithm > always assigns a "0" as the last bit of router addresses and a "1" as > the last bit of Host addresses. The root *is* a router, so I think it > would be nicer if the root address conformed to this. > > That can be achieved in two ways: > - Make the root address be "0"; > - Revise the AAF to use "0" for hosts and "1" for routers. > > I see a problem if the root address is "0" (which I discuss below) so I > think revising the AAF would be better. > > Or simply accepting this current special case inconsistency for the > router will work. [LI] Now I see you point. The reason why the root address is always 1 is because of the question in issue 8. In this way it is very easy to unpad the address, just drop all the leading zeros. I think is worth to add text to better highlight the exception of why the root, while being a router, has the address 1. We will add a sentence. > > >> 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. > > I didn't study that reference and so didn't understand that. > > But it raises different questions in my mind: > > If all of these devices are stateful then there may be situations when a > device is reset and forgets all that state. This is fine if every device > in the domain is reset simultaneously. But if a subset of devices is > reset there will be problems: > > If a host is reset it will request a new address from its old router. > (Assuming it chooses the same router.) its old address becomes an > orphan. Or is the router supposed to recognize the host and send back > the old address? [LI] Good point. This must be covered in the GAAO document. The router needs to store address assignments in non-volatile memory. > > If a router is reset, then it won't remember any of its children, but > they will still remember it and won't have any reason to reconnect. [LI] Not sure I understand you here. Children can still re-register their address since they remember. [LI] > > I'm hoping you have answers to these issues. But will the reader of this > document know those? If this is all addressed in the references then > maybe nothing more is needed. Else I think more text (maybe a lot more) > is needed to make this clear. [LI] These are covered in RFC 8505, and draft-iannone-6lo-gaao. [LI] Actually the latter still needs to include some text covering it. [LI] I think that some discussion on these issue is also needed in draft-iannone-pasa-reliability. > > > We can fix this in several points: > > I'm not going to comment on this fix because I can't evaluate them until > I hear more about my questions above. > > > 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. > > If this would be understood by a reader who is familiar with the > references then don't make changes just for me. [LI] You highlight some lack of clarity. I think that the suggested changes derived from your comments improve the document. > > >> 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? > > It was already clear to me how a variable length bit string address is > padded to a whole number of bytes. My question is the inverse - how to > extract the bit string address from the padded form. It may be necessary > to remove some zero bits from the beginning, but how many? > > *If* the root address is always "1", then the answer is to always remove > all leading zeros. If the root address might start with "0" then I see > no solution. > > Maybe this was your intent but it isn't stated anywhere I can find. I > only see the root address as "1" in Figure 6 which is only an example. > [LI] Reply in issue 5 applies here. Plus, we will improve the text so to have normative statements. Thanks for the very interesting feedback. Ciao L. > For that matter I find no normative statements regarding the TAAF. I > assume it is intended to be normative since it is registered in IANA. I > would hope to see a lot of normative language about the TAAF. > > DONE FOR NOW > > >> 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] Gen-ART Early review of draft-ietf-6lo-path… Paul Kyzivat
- Re: [6lo] Gen-ART Early review of draft-ietf-6lo-… Luigi IANNONE
- Re: [6lo] Gen-ART Early review of draft-ietf-6lo-… Luigi IANNONE
- [6lo] Re: Gen-ART Early review of draft-ietf-6lo-… Paul Kyzivat
- [6lo] Re: Gen-ART Early review of draft-ietf-6lo-… Luigi IANNONE
- [6lo] Re: Gen-ART Early review of draft-ietf-6lo-… Carles Gomez Montenegro