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

[Lorenzo Colitti <[e-mail]>]

On Tue, Apr 21, 2015 at 2:41 AM, Erik Nordmark <[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.

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.

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.

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.


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

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.