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

[Erik Nordmark <[e-mail]>]

On 10/2/14 9:05 AM, Samita Chakrabarti wrote:
> Hello Erik,
>
> Finally I had some time to review the draft. Here are some of my comments:
Sorry for the delay - I deferred responding until the deadline got closer.

>
> 1. Observation: This document is trying to cover the issue with multicasts in ND(RFC4861) and also suggesting some sort of registration ? [ Section 7.2]   From efficient-nd  adoption call discussions I remember  some folks complained about the changes required in their clients (mobile devices?). Will they  be fine now with the new option and changes in the host with this new option?

Sorry, that mention of registration was a cut and paste error. Should be 
about refreshing prefixes etc.
>
>
>
> 2. Thoughts: IMHO,  the rs-ra solution will be flexible and widely applicable with different usecases and turning on or implementing different options if it OPTIONALLY includes the ARO option as well for address registration and controlling better movement such as TID bits.  In that case, the Address Registration Method can be useful for implementations that need them (both Router and host) and others can ignore them.
> Address registration (ARO) itself has some benefits with reliability - we can document them for the sleepy and constrained devices that are in IPV6 network or lowpower Wifi network(in future).
> However, I see that rs-ra solution still sends at least one multicast RA. That can be harmful in some networks.
> What about subnets with new and legacy hosts? What should the router do - keep sending multicast RA?

I think we can keep any use of explicit (or implicit) registrations 
orthogonal to the RS refresh.
>
> 3. Other comments ( mostly editorial):
>
> Section -1 : (Introduction)
>
>
> "However, on for instance WiFi links
>     the performance and reliability for multicast is quite different than
>     for unicast (see for instance [I-D.vyncke-6man-mcast-not-efficient]).
>     Cellular networks which employ paging and support sleeping hosts have
>     different issues (see e.g., [I-D.garneij-6man-nd-m2m-issues] that
>     would benefit from having the hosts wake up and request information
>     from the routers instead of the routers periodically multicasting the
>     information."
>
> ==> This sentence can be broken down into two sentences to be simpler. Now it is complex to understand .

Done.

>
> Section 2.
> "
> refresh is more efficient that periodic multicast RAs" ===>  refresh is more efficient *than* periodic multicast RA
Fixed.
>
> Section 4.
>
> It'd be good to clarify the sequence of  messaging here. It would provide a clear picture in the beginning  about the sequence of Router and  Host messages. [ I can volunteer to provide some picture and text here]
I don't know what is complex. Still the case that host sends RS and 
routers send RA.
>
> Also,  I am not clear what happens in the mixed environment where both hosts exist -- RTO enabled or legacy? If this draft recommends homogeneous environment for all practical purposes in order to take advantage of efficiency then it might be worthwhile to say that upfront and simplify the solution.
> Learning from efficient-nd : supporting MIXED MODE  is complex and can't solve problems really.
>
> For example: If the Router receives ARO/RTO, it  expects that nodes in this network will register itself periodically. Of-course it is up to the deployment how the router would be configured but the draft can always recommend.
There is a section on routers verifying the consistency of the RAs with 
other routers. I'm adding some text in the host section as well.

>
>
> Section 7.2:
> " When a host wakes up it can combine movement detecting (DNA), NUD,
>     and refreshing its Address Registration by sending a unicast RA to"
>                                                                                                              ^^^^^^^^^^^^
>
> What is this "address registration" here?  Should it be "unicast RS" from the host  above?
> We can add ARO here.
s/address registration/prefixes etc/
Unicast RS is correct.

>
> Section 8.3: Router can multicast for changes that are applicable to ALL-nodes in the network in one shot. In future, with RTO or ARO(OPTINAL features), one should be capable of pushing  RA-feature per host as well. So, if we are going to use SHOULD/MUST, we might take the per-host consideration into account.
I'll add that possibility.
>
> Finally, if the DT agrees to put forward this document, then it would be good to add multiple co-authors in the document. Efficient-nd co-authors could be able to do a summary analysis of differences between the two and how this one might be a better solution as a middle-ground. Other option is to keep two separate solutions. But I think it's better to have one document with options for implementations.

I'm open to multiple authors - but need to decide before Monday.

Thanks for your comments.
    Erik

>
>
>   Thanks,
> -Samita
>
>
> -----Original Message-----
> From: Efficientnd-dt [mailto:[e-mail]] On Behalf Of Erik Nordmark
> Sent: Thursday, August 21, 2014 12:36 AM
> To:[e-mail]
> Subject: [Efficientnd-dt] Food for thought - router-controlled RS refresh
>
>
> 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
>
>
>
>
>