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

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

Hello Eduard:

I had to twist the standards of the day to make Mobile IPv6 (MIPv6) and NEMO work when I implemented the cisco mobile router (IOS-based), about 20 years ago.
Basically match the source address and the router that sent the PIO (which is now RFC 8028), and use the most recently seen router (which is still not in any standard). 
MIPv6 also defined a way to quickly deprecate a router that is not reachable anymore using a fast RA interval. That was never enough to keep sessions flowing, but at least it could turn 1 week into minutes.

So to your point, I'd say that we need more of a BCP to implement what exists rather than new stuff. Maybe Xipeng's v6Ops work could cover that?

Now there's still a need to "sync" state changes between a router and a host when one's state depends on the other, e.g., new PIO deprecating old PIO. 
In the context of stateful AAC (WiND) we defined a new ND option for what impacts the registration state, see https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast-registration-09#section-10. 

Erik K. (as 6lo A-D) raised the issue that this option may be generalized and sh/could be its own draft. Awaiting confirmation on that. 	

All the best;

Pascal

> -----Original Message-----
> From: ipv6 <[e-mail]> On Behalf Of Vasilenko Eduard
> Sent: mercredi 17 août 2022 12:13
> To: Ted Lemon <[e-mail]>; Fernando Gont <[e-mail]>
> Cc: [e-mail]
> Subject: RE: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale
> information
> 
> Hi Ted,
> 
> The case that Jen has mentioned, I have heard the 1st time from Olorunloba
> Olopade:
> CPE is switched off, thrown in the garbage basket, and a new CPE is
> installed.
> The old CPE is not in the reload - it would never be powered again.
> For some time (up to 30min), the host would think that 2 routers are
> available.
> For a long time (1 week), the host would think that the old PIO is
> available.
> Hence, the need to do something about this traffic black holing.
> 
> The case: "Router absence during reload" is out of "flash renumbering"
> scope Because such things needs something like BFD to fast detect.
> It is possible to add something like BFD to the host, but it is probably a
> different draft/RFC.
> 
> All cases in the scope of flash renumbering are "reaction to the
> new/different announcement of the router".
> It does not matter why announcement is new - host should have consistet
> configuration.
> "Flash renumbering" is about "fast depricate after new information arrival
> in RA".
> Reloading router could not deliver a new information. Hence, not related
> to this draft discussion.
> 
> Ed/
> -----Original Message-----
> From: Ted Lemon [mailto:[e-mail]]
> Sent: Tuesday, August 16, 2022 5:14 PM
> To: Fernando Gont <[e-mail]>
> Cc: Vasilenko Eduard <[e-mail]>; [e-mail]
> Subject: Re: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale
> information
> 
> Right, I think Eduard was talking about the case where the arrival of a
> new router signals a possible link change. In this case, if the old router
> is not reachable, that probably means you’re on a reconfigured link.
> However, it could also mean that the router is rebooting, and your timing
> is bad. So it makes sense to deprecate the prefixes you got from that
> router, so that you don’t continue to use them in case they won’t work,
> but to not flush them, and not break connections using them, because if
> the router is only temporarily gone, the other router that showed up may
> not be offering equivalent connectivity, and so trashing existing
> connections could result in a bad user experience.
> 
> Of course, the easy way out of this is to not look for signals that the
> network has been reconfigured, on the assumption that that should never
> happen without a link state transition. In a sense, the question is
> whether this is actually a valid assumption or not. How likely is a link
> reconfiguration without a link state change and without an explicit signal
> from the router?
> 
> Sent from my iPad
> 
> > On Aug 16, 2022, at 9:58 AM, Fernando Gont <[e-mail]>
> wrote:
> >
> > Hi, Ted,
> >
> >> On 16/8/22 10:49, Ted Lemon wrote:
> >>> On Aug 16, 2022, at 5:04 AM, Vasilenko Eduard
> <[e-mail]> wrote:
> >>> I do not understand the benefit to keep stale ND information
> >> It might not be stale. The router might just be briefly offline. You
> don’t want to break all your connections because of that. If the prefix is
> genuinely no longer valid, then a more advanced implementation could
> notice that all the connections on that deprecated prefix have timed out,
> and then flush it, but flushing it immediately seems premature.
> >
> > FWIW, in our I-D we only deprecate information when the router ceases to
> advertise a previously-advertised prefix while still sending RAs.
> >
> > (i.e., it's not that the router "disappears", but rather it simply stops
> advertising the previously-advertised prefix).
> >
> > Thanks,
> > --
> > Fernando Gont
> > SI6 Networks
> > e-mail: [e-mail]
> > PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------