Re: [6lo] Router reboot - loss of state

[Klaus Hueske <[e-mail]>]

@Paul Duffy<mailto:[e-mail]> Tomorrow is an official call. Do you think we'll have time for further discussion or shall we postpone until next week?
________________________________
From: Pascal Thubert (pthubert) <[e-mail]>
Sent: Monday, May 23, 2022 8:18:30 PM
To: Klaus Hueske <[e-mail]>
Cc: Hett, Chris <[e-mail]>; [e-mail] <[e-mail]>; Paul Duffy (paduffy) <[e-mail]>
Subject: Re: [6lo] Router reboot - loss of state

Hello Klaus

Wi sun would not need to implement the new option in ND messages. But sleeping devices will miss the Reboot time NA and need an opportunity later to realize they have an issue.

I am double booked tomorrow at the meeting but I’ll try to join for a short window if that’s ok?


Regards,

Pascal

Le 23 mai 2022 à 14:32, Klaus Hueske <[e-mail]> a écrit :



Hi Pascal,



I’ve just had a look at the updated parts related to router reboot in your latest draft. Thanks for preparing this!



As it looks like you are proposing three distinct mechanisms, i.e. propagating uptime, NSSI and "Registration Refresh Request". Do you think we need all three? Using the "Registration Refresh Request" along with the TID would certainly already solve the issue we have in the current FAN TPS. Then, since FAN only makes use of NA messaging between routers in case of error, NSSI and "Registration Refresh Request" would be hardly applicable.



If you can make it for tomorrow’s call, let’s discuss then.



Best regards,



Klaus



From: Hett, Chris <[e-mail]>
Sent: Freitag, 20. Mai 2022 21:52
To: Pascal Thubert (pthubert) <[e-mail]>; Klaus Hueske <[e-mail]>; [e-mail]
Cc: Paul Duffy (paduffy) <[e-mail]>
Subject: RE: [6lo] Router reboot - loss of state



Hi Pascal,



I have taken a preliminary look at the latest draft and it looks good to me.



Thanks,

Chris.



From: Hett, Chris
Sent: Wednesday, May 18, 2022 3:00 PM
To: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; Klaus Hueske <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Paul Duffy (paduffy) <[e-mail]<mailto:[e-mail]>>
Subject: RE: [6lo] Router reboot - loss of state



Hi Pascal,



Great, thanks!  I will review your latest draft and let you know if I have any feedback.



Regards,

Chris.



From: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Sent: Wednesday, May 18, 2022 1:20 PM
To: Hett, Chris <[e-mail]<mailto:[e-mail]>>; Klaus Hueske <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Paul Duffy (paduffy) <[e-mail]<mailto:[e-mail]>>
Subject: RE: [6lo] Router reboot - loss of state



Hello Chris: I just published 05 with the diffs here https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast-registration-05.txt<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-6lo-multicast-registration-05.txt&data=05%7C01%7CKlaus.Hueske%40renesas.com%7C4e4f1fa1624f4a527d1208da3ce8a69d%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637889267173327121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=tZaXdTKwvvDCQVFiV0XpaAQh4200zvhUE%2B3jx7QdJeQ%3D&reserved=0> You’ll find 2 things: - the capability to send an asynchronous (multicast to all nodes) NA(EARO, target=

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hello Chris:



I just published 05 with the diffs here https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast-registration-05.txt<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-6lo-multicast-registration-05.txt__%3B!!EEzGOCEfvrF80k8sMoAmtYTD!I_g-YbTlit8UyYOpUxj4S5p7S0Um1QHQoxFTsGEifVg-fJs-MvGnWVrWCGTGiRtZvWH2unsQb63ljWyfef4%24&data=05%7C01%7CKlaus.Hueske%40renesas.com%7C4e4f1fa1624f4a527d1208da3ce8a69d%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637889267173327121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D%2FlvWu6IdH3McQkgVM1jw%2Fj8pcgYbyTnyVdRpBnM%2FjE%3D&reserved=0>



You’ll find 2 things:

- the capability to send an asynchronous (multicast to all nodes) NA(EARO, target= self) at reboot with a new status asking for reregistration.

- a new Node Uptime Option that allows (the peer 6LN) to discover that the node (e.g. 6LR)  rebooted since last seen. That option can be used in NS, NA, RS and RA.



Note that any new proposed option has to go through 6MAN and that’s sometimes a huge step. So relying on it at this stage is a bet, and pressure to 6MAN if you do will be needed.



Please let me know if that flies with you.



Keep safe;



Pascal



From: Hett, Chris <[e-mail]<mailto:[e-mail]>>
Sent: jeudi 12 mai 2022 16:47
To: Klaus Hueske <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Cc: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; Paul Duffy (paduffy) <[e-mail]<mailto:[e-mail]>>
Subject: RE: [6lo] Router reboot - loss of state



Hi Klaus, Pascal,



Yes, I agree that this is a gap that should be addressed.  It is not always practical to expect constrained devices to store – potentially hundreds of – neighbor cache details across a power cycle.  There should be a way for a 6LR implementing RFC 6775 to notify its neighbors that it has lost its neighbor cache and signal that its neighbors should reregister their addresses.



Since this is a Neighbor Discovery related issue, I think it makes sense to add some kind of sequence number option (similar to a DTSN) for NA messages.  If a neighbor detects the sequence number has incremented, they can reregister their addresses.



Best Regards,

Chris.



From: Klaus Hueske <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, May 12, 2022 4:56 AM
To: [e-mail]<mailto:[e-mail]>
Cc: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>; Hett, Chris <[e-mail]<mailto:[e-mail]>>; Paul Duffy <[e-mail]<mailto:[e-mail]>>
Subject: RE: [6lo] Router reboot - loss of state



Hi Pascal, Thanks for pointing this out! Indeed, the problem is not limited to sleepy devices, but relevant for all nodes that expect address registration according to RFC6775 Section 3.3. The mechanism assumes that hosts actively register

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

ZjQcmQRYFpfptBannerEnd

Hi Pascal,



Thanks for pointing this out! Indeed, the problem is not limited to sleepy devices, but relevant for all nodes that expect address registration according to RFC6775 Section 3.3. The mechanism assumes that hosts actively register their address with the router using NS with ARO and that the hosts are responsible for maintaining the registration depending on the configured lifetime. However, if the router is rebooted unexpectedly (e.g. due to a power outage) it will lose its neighbor cache information. This may not even be noticed by the connected hosts, so they will assume their address registration at the router is still okay, which is not the case. Considering the possible long registration lifetime, this would lead the connected nodes unreachable for a long period of time.



The DTSN present in DIO messages can be used to refresh routing information by triggering DAO transmissions, but it will not trigger any address re-registration. What we need then is kind of an advertisement issued by the router after reboot that asks the connected hosts to send another NS with ARO to refresh their neighbor cache registration at the router. Probably this could be done by creating a dedicated option to be used in an unsolicited NA send to link local multicast after reboot. This option could be conceptually similar to the DTSN, just for ARO.



The lack of such a feature has clearly been identified as a gap, especially when operating mains powered nodes in unstable grids. Hence, I’d prefer to extend the scope of the existing multicast draft to get this fixed as soon as possible. Happy to contribute to a new version of the draft if desired.



Best regards,



Klaus



From: Pascal Thubert (pthubert) <[e-mail]<mailto:[e-mail]>>
Sent: Freitag, 6. Mai 2022 11:11
To: [e-mail]<mailto:[e-mail]>
Subject: [6lo] Router reboot - loss of state



Dear all :



There’s one thing that was left unspecified in the RFC chain from RFC 6775, 8505, and 9010.  That’s the case where the 6LR reboots and the 6LN is not aware of the event, maybe it was sleeping. In that case the 6LR forgets the registration and the 6LN might become unreachable till it reregisters. A router that knows the event will happen  goes could send a final RA but the 6LN might not hear it either, so the result is not deterministic. Anyway that does not cover the unintended reboot.



Usually the L2 detects a loss of association or something, that triggers the 6LN to reparent.  But that is not guaranteed to be available in all networks.

RPL has a method, the DTSN in the DIO (https://datatracker.ietf.org/doc/html/rfc6550#section-6.3.1<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fjpn01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc6550*23section-6.3.1%26data%3D05*7C01*7Cklaus.hueske*40renesas.com*7Cc6095f0e524742e74d5108da2de3ab9f*7C53d82571da1947e49cb4625a166a4a2a*7C0*7C1*7C637872753125005927*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C%26sdata%3D5PLxb2Vqb3sMtbjFx7onAM8eT1CP1Uqhf3Cc*2FmnpAEI*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!EEzGOCEfvrF80k8sMoAmtYTD!Ij9D4FHBc4lj2Fedt1ezN7EOYbV-bYHbuEGX_DPRWVtrXiv0euhjwYv2zyTXlAfoCFRKo_V1shse3XKqov49jfVTzA%24&data=05%7C01%7CKlaus.Hueske%40renesas.com%7C4e4f1fa1624f4a527d1208da3ce8a69d%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637889267173327121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Nt9lskw2eIvU1I6U9tLMa0DtPeRLJN6H40V5try4OEk%3D&reserved=0>). A new sequence indicates that the child that sees it needs to send its state, DAO in this case. The child will eventually see a DIO, and when it sees it, the child will know that the sequence was incremented. Though the text in RFC 6550 does not list all the cases when that is useful, a reboot in storing mode is certainly one.



But this only requires resending  DAO messages and has no effect on ND. https://datatracker.ietf.org/doc/html/draft-chakrabarti-nordmark-6man-efficient-nd-07#section-6.3<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2Fjpn01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Fdraft-chakrabarti-nordmark-6man-efficient-nd-07*23section-6.3%26data%3D05*7C01*7Cklaus.hueske*40renesas.com*7Cc6095f0e524742e74d5108da2de3ab9f*7C53d82571da1947e49cb4625a166a4a2a*7C0*7C1*7C637872753125005927*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C%26sdata%3D7L53ZM1wt*2BMbYAZEoMPssWOBXiDpi9XlNjGBCx*2Bu2iY*3D%26reserved%3D0__%3BJSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUlJQ!!EEzGOCEfvrF80k8sMoAmtYTD!Ij9D4FHBc4lj2Fedt1ezN7EOYbV-bYHbuEGX_DPRWVtrXiv0euhjwYv2zyTXlAfoCFRKo_V1shse3XKqov7tUDMiQg%24&data=05%7C01%7CKlaus.Hueske%40renesas.com%7C4e4f1fa1624f4a527d1208da3ce8a69d%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637889267173327121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yAdBx8zQSMApdO8TKWDx4z3RhKFVk5hzoNJ7BzNo1Rk%3D&reserved=0> has the same operation with a new RA option, the RAO, which also has a sequence counter, the router epoch; but the draft was stalled at 6MAN and the function is still missing. My suggestion is to fix that gap sooner than later.



The fast path is to integrate the option in the multicast draft. The slow path is to make yet another RFC. What would you guys prefer?



Keep safe



Pascal





Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647



P PLEASE CONSIDER OUR ENVIRONMENT BEFORE PRINTING THIS EMAIL.

This e-mail (including any attachments) is confidential and may be legally privileged. If you are not an intended recipient or an authorized representative of an intended recipient, you are prohibited from using, copying or distributing the information in this e-mail or its attachments. If you have received this e-mail in error, please notify the sender immediately by return e-mail and delete all copies of this message and any attachments. Thank you.



Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647



Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647