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

[Vasilenko Eduard <[e-mail]>]

Hi Pascal,

I do not believe that we have a solution to put in the BCP for situations:
when PIO has been just omitted from the router's announcements
Or the host has been moved between VLANs (to see the different router)
Or CPE has been brutally replaced (old router have no change to deprecate)

Moreover, you are talking below about MHMP use cases (many routers on the link).
That is almost resolved by RFC 8028, except for a couple of corner cases covered here https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-support-mhmp-00

I prefer a more stateful ND router too. But it is not the patch for the ND that is discussed here. It is an ND replacement. My vote is "+1", just I do not believe it would be accepted by this WG.
Reminder, I do not like that you made multi-link subnet (MLSN) the basic mandatory part of WiND. It is too complex and not needed for the majority of use cases.
I understand that MLSN is a good option for some mesh IoT links. It should be a non-mandatory option, clearly separated and really optional.
IMHO: draft-chakrabarti-nordmark-6man-efficient-nd was the best version of ND. It is effectively WiND without MLSN.

Eduard
-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:pthubert=[e-mail]] 
Sent: Wednesday, August 17, 2022 2:54 PM
To: Vasilenko Eduard <[e-mail]>; Ted Lemon <[e-mail]>; Fernando Gont <[e-mail]>
Cc: [e-mail]; Erik Kline <[e-mail]>
Subject: RE: draft-ietf-6man-slaac-renum: Heuristics to deprecate stale information

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