Re: [Efficientnd-dt] Food for thought - router-controlled RS refresh

[Andrew Yourtchenko <[e-mail]>]

Hi Erik,

finally have read the draft and the comments below...

First a few nits on the text:

"As soon as the router(s) on a link
    which supports these optimizations, then the updated hosts on the
    link can sleep better, while co-existing on the same link with
    unmodified hosts."

=> "As soon as there are routers on a link which support ..." ?

or is it "As soon as all the routers on a link support ..." ?

"   The key goal is to allow the operator to choose whether unicast RS
    refresh is more efficient that periodic multicast RAs."

Maybe add "..while preserving the timely and scalable reconfiguration 
capabilities that a periodic RA model provides" ?

"   A node which implements this specification i.e., will send unicast RS
    refresh messages if so instructed by the router, sets the R flag in
    the Router Solicitation message."

I had to read this twice before I could parse it :)

Suggestion: parenthesize: "A node which implements this specification 
(i.e., will send 
unicast RS
    refresh messages if so instructed by the router), sets the R flag in
    the Router Solicitation message."

also maybe worth explicitly saying "in all RS messages" ?

"A router which implements this specification can be configured to
    operate without periodic multicast Router Advertisements. When the 
operator configures this mode of operation, then the router will ..."

=> rephrase "will" into "MUST" ?

section 7 says:

"A host implementing this specification MAY also implement
    [I-D.ietf-6man-resilient-rs]."

OTOH in the intro there is a sencence saying that it is assumed that the 
host will implement resilient-rs. Looks like either SHOULD or MUST would 
be better here.

"8.3.  Multicast RA when new information"

rephrase as "Multicast RA to share new information" ?

------------

And now some free-form:

1) on updating the DNA: makes sense to me, indeed.

2) on including the epoch to RS/RA: This seems interesting, something like
a 64-bit blob sent by a router within RA and echoed by the host in the 
subsequent RSs, allowing the router to make a decision how to form the RA ?

3) We should mention what happens in the mixed-case when there are 
different routers on the link. the text in section "7. Host Behavior" 
somewhat discusses it but I'd say we should have something about it.

--a

On Thu, 21 Aug 2014, Erik Nordmark wrote:

> I mentioned this in our Friday meeting in Toronto - finally put it on paper.
>
> Do folks think this is a reasonable starting point for some Design Team 
> output when it comes to RS/RA?
> If so, should we include all the RS/RA pieces in one document? 
> (implementation advise, raise the max advinterval, etc)
>
>   Erik
>
>