Re: PIO Lifetimes (was: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information)

[Ted Lemon <[e-mail]>]

On Aug 19, 2022, at 3:14 AM, Vasilenko Eduard <[e-mail]> wrote:
> 
> I summarized because I'm just repeating things we've already discussed. When a new router shows up, we use that as a signal that the link may have changed. We probe our old routers using unicast RS. If they answer, great, if not, we deprecate their information. That takes care of the problem of continuing to use stale information.
> [EV] Looks like the explanation for Fernando’s proposal. I have compared it to another option in a response to Fernando. It has advantages and disadvantages. My conclusion: less robust than the competitive proposal, but possible – not very bad.

I think your idea of having the router signal that there is no additional information is a good one, but it will take a long time to deploy in hosts and routers, so it’s not all that interesting in the short term.

> Secondly, the draft already places constraints on how long we will consider a router to be alive if we haven't heard from it. If we don't hear from it over that time period, then we flush its information.
> [EV] I hate timers that are possible to avoid. It greatly influences robustness.

These are just the usual timers, nothing new. The difference is that we now cap the lifetimes to something reasonable.

> So the problem that you described of the table growing without bound is taken care of as well. I suppose we could add a heuristic that if the table exceeds an implementation-dependent size limit, the oldest router may be flushed to make room for a newer router. Perhaps that's already in the spec—I'd have to go look.
> [EV] I still do not understand why we need to keep stale information.

We don’t know that it’s stale. The only way to know is through some heuristic.