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

["Pascal Thubert (pthubert)" <[e-mail]>]

I do not agree that changes in routers are easier. There are tons of open source routers around that serve homes and they’re not maintained as agressively as your phone.

There are more vendors for routers than major stacks for hosts.

And the router vendors will not move an inch unless a clear business demands backs it.

Bottom line is that the best chance is to start upgrading open source code. And even there start with the client.

Regards,

Pascal

Le 20 août 2022 à 09:58, Vasilenko Eduard <vasilenko.eduard=[e-mail]> a écrit :


[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.

OK. Looks like you have dropped topic RFC 6059 (collecting stale information)
And returned to the flush renumbering problem: to understand what is stale and what is not then to depreciate stale (make it unpreferred).
Then the discussion is finished – I do not have objections.
The proposal from Fernando is not the best, but not bad, possible to go.

I believe that the requirement to change hosts is more challenging than changing routers.
Unfortunately, both competitive proposals have it. Not a big difference in difficulty from the implementation point of view.

It is more robust to signal then to guess (by timers).

Eduard
From: Ted Lemon [mailto:[e-mail]]
Sent: Friday, August 19, 2022 4:37 PM
To: Vasilenko Eduard <[e-mail]>
Cc: Fernando Gont <[e-mail]>; [e-mail]
Subject: Re: PIO Lifetimes (was: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information)

On Aug 19, 2022, at 3:14 AM, Vasilenko Eduard <[e-mail]<mailto:[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.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------