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

["Olopade, Olorunloba" <[e-mail]>]

Hello Eduard,

Yes, I do mean Multicast RS. 

Yes, we do need synchronisation. I believe some form of "feedback" is needed to achieve a "stable system". This is the premise I'm working on. With SLAAC as it currently is, we don't have a means of feeding back information from hosts to routers. That area is what I'm trying to address in this draft. By including information in RS messages, routers can learn about the state of the host.

This is an initial draft. So I wasn't attempting to document the complete solution at this time. But wanted to see if others would see the benefit of moving in this direction. In my opinion, I will like to see 2 changes to increase SLAAC robustness. This and a means for the router to indicate that it is sending "complete"  information (like you are indicating with the flag). 

But if we are to look into the various use cases, a common factor would be the forming of a new address. Hence, my proposal leverages on this, by sending the RS, as the address transitions from tentative to preferred. So, I believe all the use cases should be covered. 

Although, I'm having a change of heart on how to achieve this. I now think that using options in RS is better than relying on the source address. The key difference is that the current proposal is limited to PIO information. We also need to consider how to do garbage collection for RIO and RDNSS

I agree that this are long term solutions. For the short term, I think we are stuck with just lowering the timers.


-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Vasilenko Eduard
Sent: 20 October 2020 09:04
To: Olopade, Olorunloba <Loba.Olopade=[e-mail]>; 6man <[e-mail]>; [e-mail]
Subject: Re: [v6ops] 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:[e-mail]] On Behalf Of Olopade, 
> Olorunloba
> Sent: 19 октября 2020 г. 21:54
> To: 6man <[e-mail]>; [e-mail]
> 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: [e-mail] [mailto:[e-mail]]
> Sent: 19 October 2020 19:43
> To: Olopade, Olorunloba <[e-mail]>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops
--------------------------------------------------------------------
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