Re: 6MAN WG Adoption Call: draft-nordmark-6man-rs-refresh-01

[Erik Nordmark <[e-mail]>]

On 4/20/15 6:21 PM, Lorenzo Colitti wrote:
> On Tue, Apr 21, 2015 at 2:41 AM, Erik Nordmark <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     On 4/20/15 6:54 AM, Lorenzo Colitti wrote:
>
>         But then the "timely and scalable reconfiguration
>         capabilities" cannot be maintained. The network can't tell
>         that host about any new information, because that host won't
>         receive it. The host will only receive it when it wakes up next.
>
>     The host will take no action on any state until it wakes up.
>     "timely" implies that hosts do not take any actions on stale
>     state, and with RS refresh they would not. Hence it is very "timely".
>
>     Note that without RS refresh hosts can take action on stale state
>     if the packet loss experienced by the RAs is such that they miss
>     e.g., the RAs that set the preferred lifetime for a prefix to
>     zero, or set the default router lifetime to zero. Thus RFC 4861
>     operates in a probabilistic mode - which made sense when all
>     networks were wires and one could assume the packet loss were
>     independent events. Walking out of range of a radio does not
>     result in independent events.
>
>     Thus using RS refresh makes the "timely" work better than in RFC 4861.
>
>
> Wait - are you arguing that soliciting information when the refresh 
> timer expires, or when the node wakes up, is more "timely" than the 
> network just sending an RA and having the node receive it? That 
> doesn't make sense.
No, that wasn't what I said. I'll repeat. (But perhaps it is better for 
me to explain this over the phone instead of bothering the whole list?)
1. If there is no packet loss then the RS refresh is as timely as the 
host waking up to receive the unsolicited RAs. This is because the host 
will not use any of the state from the RA until it is time for it to 
wake up.
2. In the presence of packet loss things are more complex, but it is 
clear that unsolicited RAs do not provide any time guarantees. One can 
only make a probabilistic argument (assuming independent event packet 
loss) of how likely it is for a host to have received the information 
after N RAs have been sent. RS refresh provides has a lower expected 
delay; the host will retransmit the RS (following resilient-RS 
retransmissions) until it gets an RA. With unsolicited RAs the host 
would be waiting up to 15 minutes (or 6 hours with a larger maxra) for a 
the next unsolicited RA. With RS refresh it would send a new RS after a 
second. If the host implementations don't act on the state until RS 
refresh has succeeded (or the host has detected it has moved to a 
different link and received the RAs for that link), then the amount of 
time during which the host operates on stale state becomes zero. But in 
practice a host might act on the, potentially stale, state after the 
first RS refresh.

Hence for hosts sleeping on a schedule
   if we don't care about packet loss, then unsolicited and refresh are 
the same.
   if we care about packet loss, then refresh has a lower average delay.

>
> If what you're saying is that the sleeping node is going to ignore RAs 
> anyway, then you don't need an RS refresh option for the node to send 
> an RS and receive an RA when it wakes up. That's already possible.
There is no RFC which suggests or recommends sending a RS after wakeup. 
RFC 4861 is very prescriptive on when RS can and can not be sent.


>
> If what you're saying is that the node won't receive the RA due to 
> general packet loss, then that can happen even for a solicited RA.
See above.

>
>         It depends how frequent the RAs are. In general purpose
>         networks, they might be more frequent. Also, any node joining
>         may cause a solicited multicast RA. Depending on the
>         application, "after 10 minutes" may be a lot better than "never".
>
>     For the network deployments where frequency of RAs is a concern,
>     the desire seems to be to increase the time.
>     If you read e.g. section 5.1 in
>     draft-yourtchenko-colitti-nd-reduce-multicast you'll see that.
>
>
> The document says that if you want to reduce multicast, you can 
> increase the RA interval. Personally, I don't think that makes sense, 
> because one RA every half hour is a tiny amount of traffic, which is 
> trivial on any general-purpose network.

IPv6 needs to apply to a large range of network technologies, just like 
IPv4 does.
I think that is the fundamental disconnect here.

>
>
>         What about points #2 and #3?
>
>     I think this email thread should about WG adoption and not WG last
>     call or even about WG discussion.
>     Are you arguing that all your points in the draft need to be
>     addressed to your satisfaction before it can even become a WG draft?
>     That isn't how an IETF working group is supposed to operate.
>
>
> No. I am worried that this document cannot meet its goals, and even if 
> it does not, after adoption we will be unable to abandon it and 
> instead ship something that does not meet its goals.
>
> Perhaps the issue here is that we don't agree on a problem statement, 
> or more accurately, what we're trying to accomplish with this drafts.

You've said that for > 2 years now, but never provided any useful 
suggestions.

AFAICT you are in the rough here. But up to the WG chairs to decide.

Regards,
    Erik

>
>     FWIW your #2 was a statement of fact, but not clear how it is
>     relevant to the discussion. Seems to be related to your assumption
>     that any multicast RA makes this null and void, which is incorrect.
>
>
> It is relevant to the discussion because the draft proposes a mode 
> where periodic multicast RAs are suppressed. My point #2 observes that 
> it's not possible to exit that mode because there is no way to know 
> whether legacy hosts have left the network.
>
>     #3 was AFAICT a restatement of your conclusion based on some
>     unstated assumptions. I already tried to guess at that unstated
>     assumption in my first respond and I responded based on that. Was
>     my guess wrong? Did I you make some other unstated assumptions?
>
>
> My assumption is that in order to allow nodes to be updated 
> dynamically, hosts will still need to listen to periodic RAs. If 
> you're saying that that's now optional, then that's quite a change to 
> the existing specs, and that statement should be made very very clear 
> in the draft.