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

[Erik Nordmark <[e-mail]>]

On 10/15/14 1:03 PM, Andrew Yourtchenko wrote:
> 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 ..." ?

Clarified that any routers if sufficient. (But if some routers still 
send periodic multicast RAs it depends on the host implementation 
whether it will wake up from those all-nodes RAs.)
>
> "   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" ?
Added.
>
> "   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 :)
It should say "A node which implements this specification sets the R 
flag in the Router Solicitation message. That allows the router to 
determine whether there are legacy hosts on the link."
>
> 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."
We don't need to say what it means to implement the specification.

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

>
> "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" ?
Done but it is an unneeded use of 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.
I've strengthened that to a SHOULD. If we have a good argument for a 
MUST I wouldn't mind changing it, but don't yet have a good argument.
>
> "8.3.  Multicast RA when new information"
>
> rephrase as "Multicast RA to share new information" ?

Combined with Samita's comment about unicast being an option, I've 
changed the section heading to "Unsolicited RAs to share new information"

>
> ------------
>
> And now some free-form:
>
> 1) on updating the DNA: makes sense to me, indeed.
Just have to figure out the logistics. I guess we can later add a 
section in this document with updates to that RFC (which would say to 
use unicast RS instead of unicast NS for DNA purposes)
>
> 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 ?
Yep - if the RS has the current number, then the RA doesn't need any 
options (other than the epoch option). But this would just be a form of 
compression - merely saves bits on the wire (and a bit of CPU on the 
router and host).

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

I've added some more text.

Thanks for your comments,
    Erik

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