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

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

Hello Eduard

Efficient ND is a prequel to RFC 8505, please do not consider them as competing.


RFC 8505 covers efficient ND though it misses a few things like the RA option, which is now defined in https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast-registration<https://datatracker.ietf.org/doc/html/draft-ietf-6lo-multicast-registration-09>.

The MLSN is conceptual in RFC 8505/8929. It was also implicitly there in efficient ND. What it means is that each host to router is its own IP link and the subnet is not onlink. If you look at it not onlink is MLSN by definition. But the physical connectivity can be a single wired switched Ethernet in either case.

We call backbone a L2 network where RFC 8505 coexists with RFC 4861.  In that case you need RFC 8929 for the coexistence.

A wired host on the backbone can perfectly register its addresses with RFC 8505; and if all nodes do register then RFC 8929 is not needed. In that case, lookup can be unicast to the 6LBR (with the 6lo-unicast-lookup draft) so all NS NA are unicast. Big win.

The 6LBR is abstract. It can be Implemented using LISP and it can be RIFT or EVPN. The host doesn’t need to know.

All the best;

Pascal

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

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
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------