RE: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information

[Vasilenko Eduard <[e-mail]>]

Hi Ted,

OK. We did not understand each other.
Because your last explanation - is exactly 1 of 2 points why "flush renumbering" exists.

Reminder, "flush renumbering" should be dealt with for the case when:
1. route's PIO has been changed 
AND
2. host has not been informed about old PIO depreciation

Host interface re-initialization would clean stale information. No problem. No need for any additional solution. No need for draft-ietf-6man-slaac-renum.
Unfortunately, it is not the case. The interface has not been re-initialized when the router is behind the switch or the switch changes VLAN abruptly.

RFC 6059 has:
"Detecting Network Attachment is performed by hosts after detecting a link-layer "up" indication".
"Hosts receive indications when a link layer comes up.  Without this, they would not know when to commence the DNA procedure".
Makes it not relevant to the "flush renumbering" discussion. for sure, the host would clear stale information automatically.

RFC 6059 is discussing caching of stale ND information (from old routers not available now).
The use case is not properly discussed.
I do not understand the benefit to keep stale ND information.

Ed/
-----Original Message-----
From: Ted Lemon [mailto:[e-mail]] 
Sent: Monday, August 15, 2022 4:14 PM
To: Vasilenko Eduard <[e-mail]>
Cc: Fernando Gont <[e-mail]>; [e-mail]
Subject: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information

I don’t know if you’re talking to me or Fernando, but I’m talking about a situation where the link configuration changes without a link up/down signal, e.g. because you are connected to an access point and the infrastructure is reconfigured, or you are behind a router (although in this case you’d think the router would do the right thing).

Sent from my iPad

> On Aug 15, 2022, at 6:03 AM, Vasilenko Eduard <[e-mail]> wrote:
> 
> If there is information that the router has been reloaded (link up/down) then "flash renumbering" is not a problem - the host would re-initialize the stack.
> Hence, I do not understand what you are talking about below.
> 
> -----Original Message-----
> From: Fernando Gont [mailto:[e-mail]]
> Sent: Saturday, August 13, 2022 1:44 AM
> To: Ted Lemon <[e-mail]>
> Cc: Vasilenko Eduard <[e-mail]>; [e-mail]
> Subject: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate 
> stale information
> 
> Hi, Ted,
> 
>> On 12/8/22 19:23, Ted Lemon wrote:
>> On Fri, Aug 12, 2022 at 17:33 Fernando Gont <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>> 
>>>    On 12/8/22 13:52, Ted Lemon wrote:
>>> FWIW, I would like to see the points made in item 1 addressed in 
>>> slaac-renum.
>> 
>>    Regarding #1, nodes that change their address or that "disappear", I'd
>>    say that's not really renumbering.
>> 
>> 
>> The point is that if the router goes away, we would like to detect 
>> that quickly. A good way to detect it quickly is to notice signals 
>> that suggest the link has changed and probe for known routers. If 
>> they don’t answer, deprecate their information. Does this not make sense?
> 
> Agreed. Now, when it comes to the "signals" are you thinking of RFC6059? 
> link-status change events? Both? Something else?
> 
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494