Subject: FW: New Version Notification for draft-vv-6man-nd-prefix-robustness-00.txt

From: Paolo Volpato <[email-masked]>
Date: Wed, 14 Apr 2021 08:25:34 +0000

Dear WG,

We have posted a new draft that presents the results of an analysis on cases where a loss of information (primarily prefixes) may happen, bringing to connectivity issues.
This analysis has the target of:
- discussing the cases that may lead to network prefix invalidity;
- developing a root cause analysis for those cases and propose a solution.

This proposal does not modify current standards, it proposes only possible extensions.

Much of the work of this analysis has been inspired by draft-ietf-6man-slaac-renum (https://datatracker.ietf.org/doc/draft-ietf-6man-slaac-renum/?include_text=1). 
Special thanks to Fernando Gont for the offline discussions and other drafts focusing on the same issue.

Best regards
Eduard, Paolo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 14, 2021 9:41 AM
To: Vasilenko Eduard <[email-masked]>; Vasilenko Eduard <[email-masked]>; Paolo Volpato <[email-masked]>
Subject: New Version Notification for draft-vv-6man-nd-prefix-robustness-00.txt

A new version of I-D, draft-vv-6man-nd-prefix-robustness-00.txt
has been successfully submitted by Paolo Volpato and posted to the IETF repository.

Name:		draft-vv-6man-nd-prefix-robustness
Revision:	00
Title:		ND Prefix Robustness Improvements
Document date:	2021-04-13
Group:		Individual Submission
Pages:		30
URL:            https://www.ietf.org/archive/id/draft-vv-6man-nd-prefix-robustness-00.txt
Status:         https://datatracker.ietf.org/doc/draft-vv-6man-nd-prefix-robustness/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness
Htmlized:       https://tools.ietf.org/html/draft-vv-6man-nd-prefix-robustness-00

Abstract:
   IPv6 prefixes could become invalid abruptly as a result of outages,
   network administrator actions, or particular product shortcomings.

   That could lead to connectivity problems for the hosts attached to
   the subtended network.

   This document has two targets: on the one hand, to analyze the cases
   that may lead to network prefix invalidity; on the other to develop
   a root cause analysis for those cases and propose a solution.

   This may bring to extensions of the protocols used to convey prefix
   information and other options.

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

---

From: "Olopade, Olorunloba" <[email-masked]>
Date: Mon, 19 Apr 2021 14:04:01 +0000

Hello Eduard, Paolo,

I like the draft. How are you catering for the scenario where the CPE is abruptly replaced. I don't believe the proposed options (e.g. complete flag, prefix deprecation)  helps in this situation. However, some form of signalling from the host to the router can assist here.  

For proper SLAAC robustness, I believe we need information flow from host to the router. 

Loba Olopade
Principal Design Engineer | CTIO | Planning and Engineering 

Liberty Global Technology & Innovation
Enabling growth across Europe

-----Original Message-----
From: ipv6 <[email-masked]> On Behalf Of Paolo Volpato
Sent: 14 April 2021 09:26
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: FW: New Version Notification for draft-vv-6man-nd-prefix-robustness-00.txt

Dear WG,

Best regards
Eduard, Paolo

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Wednesday, April 14, 2021 9:41 AM
To: Vasilenko Eduard <[email-masked]>; Vasilenko Eduard <[email-masked]>; Paolo Volpato <[email-masked]>
Subject: New Version Notification for draft-vv-6man-nd-prefix-robustness-00.txt

Abstract:

The IETF Secretariat

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 19 Apr 2021 15:11:04 -0300

Folks,

In your email below, you are thanking me for off-line discussions. BUt I 
don't remember being involved in any discussions related to this document.

That aside:

* You seem to analyze cases for prefix invalidity -- when the IETF 
(v6ops) recently published RFC8879 on the topic.

* In an off-line note, you commented that you took some ideas from 
draft-ietf-6man-slaac-renum, but then:

    + Why not send feedback on the mailing list for 
draft-ietf-6man-slaac-renum instead of submitting  anew I-D?

    + Why don't you even reference draft-ietf-6man-slaac-renum?

The above doesn't seem right (or at least desirable) -- unless I'm 
missing something...

Thanks,
Fernando

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fred Baker <[email-masked]>
Date: Mon, 19 Apr 2021 19:43:30 -0700

> For proper SLAAC robustness, I believe we need information flow from host to the router.

That raises a number of interesting questions, surrounding the word “the”. “The host”? Is there only one? “The router”? Is there only one? What if a message is sent and fails to arrive? And so on…

---

From: "Olopade, Olorunloba" <[email-masked]>
Date: Tue, 20 Apr 2021 08:22:35 +0000

Hmm, I don't think it matters if there is more than one host or router. Information sent from multiple hosts do not have to be the same. It conveys their view of the network. And multiple routers can receive the information and act accordingly. 

Information flow from host to routers would mean we do not need persistent storage on the router. Stale PIOs can be recovered from information on the hosts. Routers can then do garbage collection. 

Loba Olopade

-----Original Message-----
From: Fred Baker <[email-masked]> 
Sent: 20 April 2021 03:44
To: Olopade, Olorunloba <[email-masked]>
Cc: Paolo Volpato <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: New Version Notification for draft-vv-6man-nd-prefix-robustness-00.txt

This email and any attachments are or may be confidential and legally privileged and are sent solely for the attention of the addressee(s).

---

From: Vasilenko Eduard <[email-masked]>
Date: Tue, 20 Apr 2021 09:16:59 +0000

Hi all,
IMHO: you have a little general discussion that creates difficulties in understanding each other.
Could I say in a more specific way how I understand the proposal from Olopade?
It is the simple algorithm:

If a host would receive RA from a new router (different LLA)
Then the host should initiate multicast RS (to all routers) to check who is still available.
If MAX_RTR_SOLICITATIONS RSs separated by RTR_SOLICITATION_INTERVAL would be not responded to by RA then delete the respective router from the list and all associated information.

It is effectively the same procedure that is specified in RFC 4861 section 6.3.7 for the search of routers after interface or forwarding initialization on the host.
Such an additional flood of messages would happen only after the new router attached to the link - it is a rare event.

It should effectively disclose abruptly replaced hardware.
Eduard
-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Olopade, Olorunloba
Sent: Tuesday, April 20, 2021 11:23 AM
To: Fred Baker <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: RE: New Version Notification for draft-vv-6man-nd-prefix-robustness-00.txt

Loba Olopade

---

From: Paolo Volpato <[email-masked]>
Date: Wed, 21 Apr 2021 07:20:45 +0000

Hi Fernando,
Thanks for your feedback. 
Please see inline my comments.

BR
Paolo

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] 
Sent: Monday, April 19, 2021 8:11 PM
To: Paolo Volpato <[email-masked]>; [email-masked]
Cc: Vasilenko Eduard <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: FW: New Version Notification for draft-vv-6man-nd-prefix-robustness-00.txt

Folks,

In your email below, you are thanking me for off-line discussions. BUt I don't remember being involved in any discussions related to this document.
[PV] I probably misunderstood or over-estimated this, when talking to my co-author. I wrongly inferred you had discussions.

That aside:

* You seem to analyze cases for prefix invalidity -- when the IETF
(v6ops) recently published RFC8879 on the topic.
[PV] Actually, we started our analysis trying to discuss more cases, not just related to flash-renumbering. A new version could improve the scope and remove the overlapping cases.

* In an off-line note, you commented that you took some ideas from draft-ietf-6man-slaac-renum, but then:

    + Why not send feedback on the mailing list for draft-ietf-6man-slaac-renum instead of submitting  anew I-D?
[PV] Please see above. Said that, if you and the community see value in our analysis we would be happy to provide comments or even merge parts into your work.

    + Why don't you even reference draft-ietf-6man-slaac-renum?
[PV] You are right. Sometimes, when you read your text too many times you tend to take for granted that everything is fine, which was not the case :-(. FWIW, the reference was there in our working draft.

The above doesn't seem right (or at least desirable) -- unless I'm missing something...

Thanks,
Fernando

On 14/4/21 05:25, Paolo Volpato wrote:
> To: Vasilenko Eduard <[email-masked]>; Vasilenko Eduard 
> <[email-masked]>; Paolo Volpato 
> <[email-masked]>
> Subject: New Version Notification for 
> draft-vv-6man-nd-prefix-robustness-00.txt
> 
>