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

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

Would confess that I hadn't consider DHCP. But the logic can still work i.e. DHCP Solicit to validate address that was assigned via DHCPv6.

So scenario one, host with address assigned via DHCPv6 starts to receive RA with PIO having A flag set. New SLAAC address is formed, and host should validate previous address by sending DHCP solicit message. If response is received, address is still valid. Otherwise, address should no longer be preferred

Scenario 2, host with address assigned via SLAAC, start to receive RAs with A flag cleared. Host should send DHCP Solicit message to get net address. And then RS message to routers, who can then deprecate the prefix if required.  

-----Original Message-----
From: Vasilenko Eduard [mailto:[e-mail]] 
Sent: 21 October 2020 08:39
To: Olopade, Olorunloba <[e-mail]>; 6man <[e-mail]>; [e-mail]
Subject: RE: New Version Notification for draft-olopade-6man-slaac-signaling-00.txt

> a common factor would be the forming of a new address.
[Ed: ] Nope. Prefix could be for DHCP (A flag cleared). New address would be given not inside ND engine (DHCP demon is different in Unix).
By the way, on the problem statement: similar problem could happen for DHCP too. Timers would be better (hours against days), but it is not acceptable for user anyway (far from 50ms standards of the previous age). DHCP corner case is just have not been found in live, not yet. In reality we have here general prefix robustness problem of ND - it is not related only to SLAAC.
My "Complete" flag would resolve this problem too - enough information to deprecate DHCP after 1st RA.
How host should do DHCP address deprecation in your solution? Feedback from DHCP demon to ND?

>  So, I believe all the use cases should be covered.
[Ed: ] Nope. You see above.

> I agree that this are long term solutions. For the short term, I think we are stuck with just lowering the timers.
[Ed: ] Nope. I would show.

> We also need to consider how to do garbage collection for RIO and 
> RDNSS
[Ed: ] RIO is better to deprecate for "telco broadband services" because of multi-prefix (many PA prefixes) environment. I would show why - MHMP is a little complex story.
RIO make sense only for Enterprise environment (with single address space, probably PI) - I have put this statement in the draft.

Ed/
> -----Original Message-----
> From: Olopade, Olorunloba [mailto:[e-mail]]
> Sent: 21 октября 2020 г. 2:14
> To: Vasilenko Eduard <[e-mail]>; 6man 
> <[e-mail]>; [e-mail]
> Subject: RE: New Version Notification for 
> draft-olopade-6man-slaac-signaling-
> 00.txt
> 
> 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
[Ed: ] RIO is better to deprecate. I would show why.
> 
> 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
--------------------------------------------------------------------
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