Re: rs-refresh

[Erik Nordmark <[e-mail]>]

On 3/5/15 3:41 PM, Lorenzo Colitti wrote:
> On Fri, Mar 6, 2015 at 8:02 AM, Erik Nordmark <[e-mail] 
> <mailto:[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.
That isn't actually the case. See below.
> 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.

Not quite.

It depends on how we think the hosts should handle DNA and whether that 
is invoked each time the host wakes up from sleep, or whether DNA can be 
suppressed based on some l2 information.

If DNA is not suppressed, then the text in 7.2 applies:


      7.2
      <https://tools.ietf.org/html/draft-nordmark-6man-rs-refresh-00#section-7.2>.
      Movement



    When a host wakes up it can combine movement detecting (DNA), NUD,
    and refreshing its prefixes etc by sending a unicast RS to each of
    its existing default router(s).

This unicast RS serves to get the new configuration information when the 
host wakes up.
(Note that there is also a listed open issue whether we want to optimize 
the "nothing changed" case by having some epoch number in the RA and RS.)

Given the needs of NUD I think it would make sense to require hosts to 
unicast a RS when upon wakeup (or strictly speaking, as part of using 
the network upon wakeup - if the host only wakes up to display the time 
there is no need for this). I think we can make this a requirement for 
the hosts that want to sleep while ignoring multicast 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.
>
>
> 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?

It depends on the operational environment. Some environments might be 
able to control the versions of software in the hosts that connect, in 
which case they can more aggressively assume support for new features.
Others might want to continue to "support" any old IPv6 implementation, 
hence continue to multicast periodic RAs. (But the sleeping hosts can 
ignore those RAs.)

But note that the current RFC4861 "support" for such hosts without 
resilent-rs is quite unsatisfactory. With MaxRtrAdvInterval at 1800 
seconds that host would sit there with no connectivity for on average 15 
minutes. And there is discussion to raise/remote the upper limit on 
MaxRtrAdvInterval e.g., in section 4.5 in 
draft-yourtchenko-colitti-nd-reduce-multicast-00, thus this would become 
as much as an average of 150 minutes of no service.

The point is that hosts which do not implement resilent-rs will not work 
well on a network with high loss rate for the multicast RS packets; not 
today, not with draft-yourtchenko-colitti-nd-reduce-multicast, and not 
with rs-refresh.

>          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.
It reads as a SHOULD to me in section 6.2.4, and I think I've seen this 
in the IPv6 logo tests.
Even if it had been a MAY, we could have updated it to a SHOULD for 
routers that support rs-refresh.

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

1800 is the current max.
       MaxRtrAdvInterval
                      The maximum time allowed between sending
                      unsolicited multicast Router Advertisements from
                      the interface, in seconds.  MUST be no less than 4
                      seconds and no greater than 1800 seconds.

As you increase that max you run into the issue above.

Regards,
    Erik