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

[Loba Olopade <[e-mail]>]

The 2 approaches don’t have to be mutually exclusive.

From: ipv6 <[e-mail]> On Behalf Of Pascal Thubert (pthubert)
Sent: 20 August 2022 12:31
To: Vasilenko Eduard <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)

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]<mailto: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]<mailto:[e-mail]>>
Cc: Fernando Gont <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[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]<mailto:[e-mail]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
Save Paper - Do you really need to print this e-mail?

This email contains information from Virgin Media and/or Telefonica UK Limited (O2) and may be confidential and legally privileged. Statements and opinions expressed in this email or any attachment may not represent either those of Virgin Media or Telefonica UK Limited. Any representations or commitments in this email or any attachment are subject to contract.  The information in this email is intended solely for the attention of the addressee(s) and if you are not the intended recipient please delete it (including any attachment) from your system, and be aware that any disclosure, copying distribution or use of any of this information is not permitted.

If you are in receipt of a suspicious email or you have received an email in error from Virgin Media, please report it to www.virginmedia.com/netreport, or for Telefonica UK Limited (O2), please report it to www.o2.co.uk/help/safety-and-security. 

 Registered offices:

 Virgin Media Limited, 500 Brook Drive, Reading, RG2 6UU. Registered in England and Wales: 2591237

 Telefonica UK Limited, 260 Bath Road, Slough, Berkshire SL1 4DX. Registered in England and Wales: 1743099

 VMED O2 UK Limited, Griffin House, 161 Hammersmith Road, London, United Kingdom, W6 8BS. Registered in England and Wales: 12580944