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

On 4/20/15 6:35 PM, Lorenzo Colitti wrote:
> On Sat, Mar 28, 2015 at 12:34 AM, Bob Hinden <bob.hinden@gmail.com 
> <mailto:bob.hinden@gmail.com>> wrote:
>
>     Title           : IPv6 Neighbor Discovery Optional Unicast RS/RA
>     Refresh
>
>
> All,
>
> 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.

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

So I'm confused by your statements.

Regards,
     Erik

>
> It seems to me that this document is proposing a model where there are 
> no periodic RAs being sent. That's something that can be proposed, but 
> if so, we need to carefully evaluate the implications to the 
> architecture, and how switching to such a model affects the properties 
> of the model we currently have. We also need to make sure we 
> understand how that model works for hosts that a) don't support either 
> resilient RS or this draft, b) support resilient RS but not this draft.
>
> If I am incorrect and the document is not proposing such a model, then 
> it should not mention this as a possibility. But then we need to 
> understand where the power savings are.
>
> Cheers,
> Lorenzo
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------