Subject: [Efficientnd-dt] Food for thought - router-controlled RS refresh

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Aug 2014 00:35:43 -0700

I mentioned this in our Friday meeting in Toronto - finally put it on paper.

Do folks think this is a reasonable starting point for some Design Team
output when it comes to RS/RA?
If so, should we include all the RS/RA pieces in one document?
(implementation advise, raise the max advinterval, etc)

     Erik

---

From: Erik Kline <[email-masked]>
Date: Mon, 25 Aug 2014 15:51:50 +0900

Thanks for writing this up.

A question: is it a problem if we make resilient-rs a MUST for rs-refresh
implementations?
​

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 25 Aug 2014 11:07:44 -0700

On 8/24/14, 11:51 PM, Erik Kline wrote:
> A question: is it a problem if we make resilient-rs a MUST for 
> rs-refresh implementations?
> ​

IMHO It would make sense to implement both at the the same time.

If we could argue that a MUST dependency makes sense it would be fine 
with me.
The argument could be something like:
---
If rs-refresh is implemented and someone deploys a network which assume 
hosts do rs-refresh, than a host which didn't do resilent-rs would be 
completely dead if their 3 initial RSs were lost. But even without a 
rs-refresh such hosts would be dead for a long time (until the periodic 
multicast RA).
Therefor it is strongly RECOMMENDED that hosts which implement 
rs-refresh also implement resilent-rs.
---

Can we make that a MUST or do we need a stronger argument?

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 21 Aug 2014 00:34:14 -0700

Erik