Re: rs-refresh

[Erik Nordmark <[e-mail]>]

On 3/4/15 10:28 PM, Lorenzo Colitti wrote:
> On Thu, Mar 5, 2015 at 2:37 PM, Erik Nordmark <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     The idea is to provide an option where the network operator can
>     move away from doing periodic multicast RA messages (on links like
>     3GPP/LTE, or WiFi where it is expensive) and instead have the
>     routers instruct the hosts to send unicast RS messages to refresh
>     the information - get a unicast RA.
>
>
> I don't think this is as useful as it appears to be at first glance, 
> for a few reasons:
>
>  1. This is only useful if all the hosts on the link support it. If
>     one host does not support it, then we fall back to sending
>     multicast RAs again.
>  2. Despite what the document says (in two different sections), it is
>     not possible to make it so that "updated nodes can sleep better"
>     AND "preserve the timely and scalable reconfiguration capabilities
>     that a periodic RA model provides" unless there are no legacy
>     hosts on the network
>

Lorenzo,

I think you are missing the difference between the host and router behavior.
True that to support unmodified hosts *the routers* would need to 
continue to multicast unsolicited RAs.
But *the hosts* that perform the rs-refresh can sleep without having to 
wake up due to those RAs.

>  1. If the router misses all the RSes from a legacy node (which for a
>     legacy node that doesn't implement resilient RS, means a total of
>     3 packets sent within 3 seconds of each other, which is quite
>     possible) then that node is blackholed.
>
That is an issue that is independent and resilent-rs already solves it.
>
>  1. If the router loses state, all legacy nodes are blackholed.
>
What part of the draft leads you to that (incorrect) conclusion? I can 
definitely clarify that it does not.
Nothing in the draft removes part of section 6.2.4 in RFC4861 about 
sending MAX_INITIAL_RTR_ADVERTISEMENTS initial unsolicited RAs.

> In general I'd prefer to see what the problems with the RA push model 
> are, and then address those, rather than going to a hybrid push/pull 
> model like this.
We discussed draft-garneij-6man-nd-m2m-issues (which points out problems 
in large cellular networks) in the efficient-nd design team and you were 
present during those discussions.

Regards,
     Erik