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

[Samita Chakrabarti <[e-mail]>]

Hello Erik,

Finally I had some time to review the draft. Here are some of my comments:

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?



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?

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 .

Section 2. 
"
refresh is more efficient that periodic multicast RAs" ===>  refresh is more efficient *than* periodic multicast RA

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]

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.


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. 

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.

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.


 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