Re: rs-refresh

[Lorenzo Colitti <[e-mail]>]

On Fri, Mar 6, 2015 at 8:02 AM, Erik Nordmark <[e-mail]> wrote:

> 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.
>

But at least as far as I can see they can't sleep if there are legacy hosts
on link, unless you break the current semantics of RAs.

Let me try to state that another way. The draft seems to imply that with
this scheme you can have all of the following:



   1. "Preserve the timely and scalable reconfiguration capabilities that a
   periodic RA model provides"
   2. Allow updated nodes to sleep.
   3. Support legacy hosts on the network.

But you can't, right? The reason you can't is that #3 requires that
multicast RAs be sent periodically to ensure non-updated hosts. But if
you're sending multicast RAs periodically, then the updated nodes either
sleep and ignore them (in which case you can't reconfigure them
dynamically, which means you lose the current capabilities of RAs to
rapidly disseminate new information, i.e., you get #2 but not #1), or the
updated nodes stay awake, in which case you get #1 but not #2.

  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.
>

But there are billions of existing nodes that do not support resilient-rs.
Suppose one of those nodes joins the network when there were none before,
and for some reason the router misses all three RS packets. How will the
router know that it's there and thus it needs to send periodic RAs?


>  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.


Unless I'm misreading that section, sending
MAX_INITIAL_RTR_ADVERTISEMENTS is only a MAY, so it can't be relied on.


>  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.
>

What part of that problem cannot be solved by upping the maximum value for
MaxRtrAdvInterval? The calculations in the draft use a value of 1800, which
is 5 times less than the current maximum, and 36 times less than the
maximum value that can be stored in the packet.