-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Asynchronos PDR-ACK #12
Comments
From: Roll roll-bounces@ietf.org On Behalf Of Pascal Thubert (pthubert) Dear all This is now issue 12 in github #12 I see the power of an async PDR ack but have no use case for it. The question was sent to the list a month ago and there was no suggestion; I propose that we hold the odea for the day we need it and keep things ass is for now. Objection? Keep safe; Pascal From: Pascal Thubert (pthubert) Dear all: we had this thread as part of Li’s review:
[PT] yes: the NP DAO cleans the state in the network. It removes the Track. The PDR ACK signals to the Ingress that it is being done and why. Maybe we need to explain that those 2 may be asynchronous to one another. I agree with you that we can probably think this through a little more. Basically we need to clarify when the main Root sends an async PDR ACK, what status go on there and what the reaction is by the Track Ingress based on the status (including unknown). Comments welcome! Pascal From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert) Hello Li:
[PT] yes: the NP DAO cleans the state in the network. It removes the Track. The PDR ACK signals to the Ingress that it is being done and why. Maybe we need to explain that those 2 may be asynchronous to one another. I agree with you that we can probably think this through a little more. E.g., should the PDR ACK trigger a DCO (RFC 9009) ? Could the PDR ack signal status that is not the death of the Track but other stuff?
We need separate threads to solve these issues. Let me start them Keep safe! Pascal Pascal From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3) Hello Pascal, Please find my comments inline. Best regards, From: Roll <roll-bounces@ietf.org> on behalf of Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org> A great many thanks for your excellent review! Such are much needed at this time.
[PT] The no path DAO flow along the reverse path and cleans it; so the end result would be that the Track is terminated as you figured. So yes, it could be possible to add a status to the no-path DAO but remember that it is a normal DAO not a completion (IOW not an ack). How could we justify a status in all DAOs? I’m unclear why the async PDR ack is an issue. If the PDR can not be served, the track ingress already needs to support a PDR ack that ”terminates” a Track. To clarify that sentence we can say:
[PT] This was done in the interest to simplicity, and yes we can rediscuss that.
[PT] we used to have that (B Flag for bidir) but we removed it for simplification. I’m OK to add it back, but we still lake a good description of how the node will know that the link is roughly symmetrical.
[PT] There’s no protocol element to “send notification to the requesting node when those changes happen”. So it’s hard to say that the root MUST NOT do something that it cannot do. Reworded to “
[PT] I reworded to [Li] -> Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g. any flags? Normally, root won't receive any DAO-ACK from nodes. [PT] Done; I added a section for the P-DAO-ACK
[PT] I really meant Profile 1 enables… Changing that. I guess that’s it ! I submitted -23 with this, please have a look at https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-23 Again many thanks! Pascal From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3) Hello Authors, Thanks for your great effort. The PDAO draft looks more clear and detailed. Following is some concern: 3.5.2 Using Non-Storing Mode joining Tracks [Li] -> Should it be ?
4.1. Extending RFC 6550 [Li] -> Typo for “mantain” and “ot”? 4.1.6. [Li] -> Typo for “xref target='RFC6550'/>”. Why is flag named as “D”? There is no D in "Projected Routes Support"… 5.1 The Root may use an asynchronous PDR-ACK with an negative status to indicate that the Track was terminated before its time. [Li] -> What's the difference between negative status PDR-ACK and No-Path P-DAO in section 6.5? And when to use asynchronous PDR-ACK? 5.1 One and only one RPL Target Option MUST be present in the message. [Li] -> Is it possible to remove the limitation? It’s not flexible If PDR can only carry one RTO. 5.4 only the router with the lowest Interface ID in its registered address needs report the SIO, and the Root will assume symmetry. [Li] -> Is it possible to add a flag to indicate the symmetry? Otherwise, if A chooses B as sibling, but B doesn't choose A as sibling, Root may treat SIO from A as symmetry incorrectly when only receiving SIO from A. 6.2 There is no notification to the requesting node when those changes happen. [Li] -> Confuse with this claim. Is it a MUST NOT if root wants to send notification to the requesting node when those changes happen. 6.3 In a particular deployment where PDR are not used, the namespace can be delegated to the main Root, which can assign the TrackIDs for the Tracks it creates without collision. [Li] -> Can you add some description for the collision case? E.g., node trusts itself than Root. 6.4.1 In both cases the Track Ingress is the owner of the Track, and it generates the P-DAO-ACK when the installation is successful [Li] -> Is there any difference between P-DAO-ACK and normal DAO-ACK? E.g. any flags? Normally, root won't receive any DAO-ACK from nodes. 8 Profiles 0 and 1 are REQUIRED by all implementations that may be used in LLNs; this enables to use Storing Mode to reduce the size of the Source Route Header in the most common LLN deployments. [Li] -> Profile 0 is the Legacy support of [RPL] Non-Storing Mode. I’m confuse about “this enables to use Storing Mode to reduce the size of the Source Route Header in the most common LLN deployments.” Best regards, |
Source: https://mailarchive.ietf.org/arch/msg/roll/z5-8IIxs9sWQueSJJ1ksHssNlRM/
Dear all: we had this thread as part of Li's review:
[PT] yes: the NP DAO cleans the state in the network. It removes the Track. The PDR ACK signals to the Ingress that it is being done and why. Maybe we need to explain that those 2 may be asynchronous to one another. I agree with you that we can probably think this through a little more.
Basically we need to clarify when the main Root sends an async PDR ACK, what status go on there and what the reaction is by the Track Ingress based on the status (including unknown).
Comments welcome!
Pascal
From: Roll roll-bounces@ietf.org On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 14 janvier 2022 9:18
To: Routing Over Low power and Lossy networks roll@ietf.org
Subject: Re: [Roll] review of dao-projection -22
Hello Li:
[PT] yes: the NP DAO cleans the state in the network. It removes the Track. The PDR ACK signals to the Ingress that it is being done and why. Maybe we need to explain that those 2 may be asynchronous to one another. I agree with you that we can probably think this through a little more. E.g., should the PDR ACK trigger a DCO (RFC 9009) ? Could the PDR ack signal status that is not the death of the Track but other stuff?
We need separate threads to solve these issues. Let me start them
Keep safe!
Pascal
Pascal
The text was updated successfully, but these errors were encountered: