RE: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt

Hi Loba,
I was the loudest shouting that "tweaking timers" is a very bad solution.
Hence, it was logical consequences that Ole did push me to develop my draft.
I am very close to publish it. I am in the context of this discussion. I have spent couple of weeks exclusively on this problem.

You probably mean: "multicast RS " or "multicast NS to all routers".
It is not possible to find "multicast" in your draft.

Your proposal by itself is not bad. Synchronization is needed, indeed.
I have proposed here (and it would be discussed in my draft) 1 additional flag in RA message that information is "complete".
IMHO: It is a little better way for synchronization, because it does not need additional messages to synchronize states.

But such type of solutions are considered by me as "long-term". It needs host support. It could not happen very soon.
Something for short-term is needed too.

Additionally, you have not discussed solutions for all use cases presented by Fernando in draft-ietf-v6ops-slaac-renum.
For example: abrupt prefix change on the router (without deprecation)
Or abrupt VLAN change on L2 (802.1X)
Or prefix is just disconnected from Carrier, because uplink is down (replacement is not proposed yet)
Or situation in multi-homing when many PA prefixes from different Carriers are announced and some could be disconnected from carrier.
But maybe it was not your goal to develop comprehensive solution for "ND prefix robustness" (the last term is the name of my draft)

Eduard
> -----Original Message-----
> From: v6ops [mailto:v6ops-bounces@ietf.org] On Behalf Of Olopade,
> Olorunloba
> Sent: 19 октября 2020 г. 21:54
> To: 6man <ipv6@ietf.org>; v6ops@ietf.org
> Subject: Re: [v6ops] New Version Notification for draft-olopade-6man-slaac-
> signaling-00.txt
> 
> Hello all,
> 
> I'm proposing an alternate way to address the SLAAC flash renumbering issue,
> and I've been advised to put this in a draft. This is the initial draft, and definitely
> need more work, but will like to know if people think this approach is worth
> considering.
> 
> Regards.
> 
> Loba Olopade
> 
> -----Original Message-----
> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
> Sent: 19 October 2020 19:43
> To: Olopade, Olorunloba <Loba.Olopade@virginmedia.co.uk>
> Subject: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt
> 
> 
> A new version of I-D, draft-olopade-6man-slaac-signaling-00.txt
> has been successfully submitted by Loba Olopade and posted to the IETF
> repository.
> 
> Name:		draft-olopade-6man-slaac-signaling
> Revision:	00
> Title:		Explicit signaling of Stateless Address Autoconfiguration (SLAAC)
> to Renumbering Events
> Document date:	2020-10-19
> Group:		Individual Submission
> Pages:		7
> URL:            https://www.ietf.org/archive/id/draft-olopade-6man-slaac-
> signaling-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-olopade-6man-slaac-
> signaling/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-olopade-6man-slaac-
> signaling
> Htmlized:       https://tools.ietf.org/html/draft-olopade-6man-slaac-signaling-00
> 
> 
> Abstract:
>    After a renumbering event in an IPv6 network utilizing SLAAC, hosts
>    might continue to use stale addresses, as they are unaware of the
>    changes. Likewise, routers, who may deprecate the use of these
>    prefixes, are unaware of their use on the hosts. This scenario could
>    have an adverse effect on communication with the host. This document
>    proposes changes to the SLAAC algorithm that will explicitly allow
>    routers to learn of these stale prefixes that are still assigned on
>    the network.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> 
> 
> --------------------------------------------------------------------
> Save Paper - Do you really need to print this e-mail?
> 
> Visit www.virginmedia.com for more information, and more fun.
> 
> This email and any attachments are or may be confidential and legally privileged
> and are sent solely for the attention of the addressee(s).
> 
> Virgin Media will never ask for account or financial information via email. If you
> are in receipt of a suspicious email, please report to
> www.virginmedia.com/netreport
> 
> If you have received this email in error, please delete it from your system: its
> use, disclosure or copying is unauthorised. Statements and opinions expressed in
> this email may not represent those of Virgin Media. Any representations or
> commitments in this email are subject to contract.
> 
> Registered office: 500 Brook Drive, Reading, RG2 6UU
> 
> Registered in England and Wales with number 2591237
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops