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

[Erik Nordmark <[e-mail]>]

On 4/22/15 7:27 AM, Lorenzo Colitti wrote:
> On Wed, Apr 22, 2015 at 2:10 AM, Erik Nordmark <[e-mail] 
> <mailto:[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.

Lorenzo,

If you re-read your own text above you'll find that is says "nodes that 
don't want to wait for such periodic ..." and I was responding to that 
statement
because it seems incorrect. So I think you need some more work on your 
description of existing model that you you claim is easy to understand 
and easy to reason about, since you don't seem to be able to describe it 
correctly.

If you want to fold in DNA aspects (re-attaching to a link - possibly 
the same or different) as you are trying to, then I suspect your model 
description will need more work. Might be better to write an internet 
draft instead of doing this back and forth over email. That would also 
ensure that we can get a permanent record of the model.

But might not be as easy to understand and reason about as you claim.

Regards,
    Erik


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