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

[Lorenzo Colitti <[e-mail]>]

On Wed, Apr 22, 2015 at 2:10 AM, Erik Nordmark <[e-mail]> wrote:

> I think the root of my objections to this draft is that it proposes what
>> is in effect a substantial change to the current configuration model in
>> IPv6 networks without saying so explicitly.
>>
>> Currently, we have an easy-to understand, easy-to-reason-about model:
>> periodic RAs periodically notify everyone on link of the current
>> configuration information, and nodes that don't want to wait for such
>> periodic configuration information can solicit said information by sending
>> a request.
>>
>
> Lorenzo,
> which RFC states "nodes that don't want to wait for such periodic
> configuration information can solicit said information by sending a
> request"?
> AFAIK that isn't allowed. If you do that you would be violating this MUST
> in RFC 4861:
>    Once the host sends a Router Solicitation, and receives a valid
>    Router Advertisement with a non-zero Router Lifetime, the host MUST
>    desist from sending additional solicitations on that interface, until
>    the next time one of the above events occurs.


As I said in my other reply, I think the event that occurs here is "The
host re-attaches to a link after being detached for some time." To me, if
you can't receive packets, you're arguably not attached.

I agree that this is interpretation is not particularly clear, but it's
also something that can be clarified without substantially changing the
semantics.

With this document, it's not clear what model is proposed.
>>
> AFAICT the document is clear on what it is proposing. If others find it
> unclear we can definitely add some wording.
>
> You seem to disagree with the change in the model? Or perhaps you don't
> since the paragraph above seems to say that that the model already allows
> for "pull" by sending RSes? Even though that is not allowed in RFC 4861!!
>

I disagree with changing the model in such a way that push configuration
becomes optional (either through explicit design, or de facto, over time,
due to sloppy / buggy implementations or developers / network operators
used to IPv4-style pull configuration).

Today, a node cannot rely only on periodic refresh without losing
information, unless it's prepared to engage in a relatively heavyweight
process of sending multicast RS and waiting for RA (or doing DNA). This
document will change that.