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

2022-05-23 Thread Klaus Hueske 
@Paul Duffy<mailto:padu...@cisco.com> 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) 
Sent: Monday, May 23, 2022 8:18:30 PM
To: Klaus Hueske 
Cc: Hett, Chris ; 6lo@ietf.org <6lo@ietf.org>; Paul 
Duffy (paduffy) 
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  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 
Sent: Freitag, 20. Mai 2022 21:52
To: Pascal Thubert (pthubert) ; Klaus Hueske 
; 6lo@ietf.org
Cc: Paul Duffy (paduffy) 
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) mailto:pthub...@cisco.com>>; 
Klaus Hueske mailto:klaus.hue...@renesas.com>>; 
6lo@ietf.org<mailto:6lo@ietf.org>
Cc: Paul Duffy (paduffy) mailto:padu...@cisco.com>>
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) mailto:pthub...@cisco.com>>
Sent: Wednesday, May 18, 2022 1:20 PM
To: Hett, Chris mailto:chris.h...@landisgyr.com>>; 
Klaus Hueske mailto:klaus.hue...@renesas.com>>; 
6lo@ietf.org<mailto:6lo@ietf.org>
Cc: Paul Duffy (paduffy) mailto:padu...@cisco.com>>
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=05%7C01%7CKlaus.Hueske%40renesas.com%7C4e4f1fa1624f4a527d1208da3ce8a69d%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637889267173327121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=tZaXdTKwvvDCQVFiV0XpaAQh4200zvhUE%2B3jx7QdJeQ%3D=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=05%7C01%7CKlaus.Hueske%40renesas.com%7C4e4f1fa1624f4a527d1208da3ce8a69d%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637889267173327121%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=D%2FlvWu6IdH3McQkgVM1jw%2Fj8pcgYbyTnyVdRpBnM%2FjE%3D=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 mailto:chris.h...@landisgyr.com>>
Sent: jeudi 12 mai 2022 16:47
To: Klaus Hueske mailto:klaus.hue...@renesas.com>>; 
6lo@ietf.org<mailto:6lo@ietf.org>
Cc: Pascal Thubert (pthubert) mailto:pthub

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

2022-05-23 Thread Klaus Hueske 
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 
Sent: Freitag, 20. Mai 2022 21:52
To: Pascal Thubert (pthubert) ; Klaus Hueske 
; 6lo@ietf.org
Cc: Paul Duffy (paduffy) 
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) mailto:pthub...@cisco.com>>; 
Klaus Hueske mailto:klaus.hue...@renesas.com>>; 
6lo@ietf.org<mailto:6lo@ietf.org>
Cc: Paul Duffy (paduffy) mailto:padu...@cisco.com>>
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) mailto:pthub...@cisco.com>>
Sent: Wednesday, May 18, 2022 1:20 PM
To: Hett, Chris mailto:chris.h...@landisgyr.com>>; 
Klaus Hueske mailto:klaus.hue...@renesas.com>>; 
6lo@ietf.org<mailto:6lo@ietf.org>
Cc: Paul Duffy (paduffy) mailto:padu...@cisco.com>>
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=05%7C01%7CKlaus.Hueske%40renesas.com%7Cf632b6bad87843e3092b08da3a9a3a24%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637886731331574446%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=PcaJ6JnBhAlOhtHDAuPJMQojniCzAAgCQaqEzSIRmj0%3D=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=05%7C01%7CKlaus.Hueske%40renesas.com%7Cf632b6bad87843e3092b08da3a9a3a24%7C53d82571da1947e49cb4625a166a4a2a%7C0%7C0%7C637886731331574446%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=Gmh9huZfT4HlskkAY1bU1vMfJuS26TMLUZV3wbRG0pk%3D=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 mailto:chris.h...@landisgyr.com>>
Sent: jeudi 12 mai 2022 16:47
To: Klaus Hueske mailto:klaus.hue...@renesas.com>>; 
6lo@ietf.org<mailto:6lo@ietf.org>
Cc: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>; 
Paul Duffy (paduffy) mailto:padu...@cisco.com>>
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 mailto:klau

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

2022-05-18 Thread Pascal Thubert (pthubert) 
Hello Chris:
I just published 05 with the diffs here 
https://www.ietf.org/rfcdiff?url2=draft-ietf-6lo-multicast-registration-05.txt

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 
Sent: jeudi 12 mai 2022 16:47
To: Klaus Hueske ; 6lo@ietf.org
Cc: Pascal Thubert (pthubert) ; Paul Duffy (paduffy) 

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 mailto:klaus.hue...@renesas.com>>
Sent: Thursday, May 12, 2022 4:56 AM
To: 6lo@ietf.org<mailto:6lo@ietf.org>
Cc: Pascal Thubert (pthubert) mailto:pthub...@cisco.com>>; 
Hett, Chris mailto:chris.h...@landisgyr.com>>; Paul 
Duffy mailto:padu...@cisco.com>>
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) mailto:pthub...@cisco.com>>
Sent: Freitag, 6. Mai 2022 11:11
To: 6lo@ietf.org<mailto:6lo@ietf.org>
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.

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

2022-05-12 Thread Pascal Thubert (pthubert) 
Makes sense to me Chris

So we probably want a sequence counter that is in every RA by the 6LR and an 
asynchronous broadcast NA upon reboot.

 The 6LR as a router mais do periodic RAs with capabilities etc. There’s no 
periodic NA though, so if we wanted regular broadcast NAs that would probably 
constitute an issue, to be validated by the list.

What do you think ?

Pascal

Le 12 mai 2022 à 16:47, Hett, Chris  a écrit :


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 
Sent: Thursday, May 12, 2022 4:56 AM
To: 6lo@ietf.org
Cc: Pascal Thubert (pthubert) ; Hett, Chris 
; Paul Duffy 
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) mailto:pthub...@cisco.com>>
Sent: Freitag, 6. Mai 2022 11:11
To: 6lo@ietf.org<mailto:6lo@ietf.org>
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://urldefense.com/v3/__https:/jpn01.safelinks.protection.outlook.com/?url=https*3A*2F*2Fdatatracker.ietf.org*2Fdoc*2Fhtml*2Frfc6550*23section-6.3.1=05*7C01*7Cklaus.hueske*40renesas.com*7Cc6095f0e524742e74d5108da2de3ab9f*7C53d82571da1947e49cb4625a166a4a2a*7C0*7C1*7C637872753125005927*7CUnknown*7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0*3D*7C3000*7C*7C*7C=5PLxb2Vqb3sMtbjFx7onAM8eT1CP1Uqhf3Cc*2FmnpAEI*3D=0__;JSUlJSUlJSUlJSUlJSUlJSUlJSUlJSUl!!EEzGOCEfvrF80k8sMoAmtYTD!Ij9D4FHBc4lj2Fedt1ezN7EOYbV-bYHbuEGX_DPRWVtrXiv0euhjwYv2zyTXlAfoCFRKo_V1shse3XKqov49jfVTzA$>).
 A new sequence indicates that the child that sees it

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

2022-05-12 Thread Klaus Hueske 
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) 
Sent: Freitag, 6. Mai 2022 11:11
To: 6lo@ietf.org
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).
 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
 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
___
6lo mailing list
6lo@ietf.org
https://www.ietf.org/mailman/listinfo/6lo