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

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 2 Oct 2014 16:05:28 +0000

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:[email-masked]] On Behalf Of Erik Nordmark
Sent: Thursday, August 21, 2014 12:36 AM
To: [email-masked]
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

---

From: Andrew Yourtchenko <[email-masked]>
Date: Wed, 15 Oct 2014 22:03:57 +0200

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

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 24 Oct 2014 14:38:57 -0700

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

Sorry, that mention of registration was a cut and paste error. Should be 
about refreshing prefixes etc.
> 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.
> ==> This sentence can be broken down into two sentences to be simpler. Now it is complex to understand .

Done.

> refresh is more efficient that periodic multicast RAs" ===>  refresh is more efficient *than* periodic multicast RA
Fixed.
> 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 pictur…
I don't know what is complex. Still the case that host sends RS and 
routers send RA.
> 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 th…
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.

>     and refreshing its Address Registration by sending a unicast RA to"
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…
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 differenc…

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

Thanks for your comments.
    Erik

> To:[email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 24 Oct 2014 15:13:16 -0700

> 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.)
> capabilities that a periodic RA model provides" ?
Added.
> 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."
> (i.e., will send unicast RS
We don't need to say what it means to implement the specification.

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

> => rephrase "will" into "MUST" ?
Done but it is an unneeded use of MUST.

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

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)
> subsequent RSs, allowing the router to make a decision how to form the 
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).

> somewhat discusses it but I'd say we should have something about it.

I've added some more text.

Thanks for your comments,
    Erik