Re: [v6ops] draft-ietf-v6ops-reducing-ra-energy-consumption WGLC

[Nabil Benamar <[e-mail]>]

I have read the draft and I'm supporting it. I have just one question about
the chosen values of RA. " Networks that serve battery-powered devices SHOULD
NOT send

       multicast RAs too frequently (e.g., more than one every 5-10
       minutes for current battery-powered devices)
​..."​

​How these values have been chosen ? Why 5-10 minutes exactly ?​


Best regards
Nabil    نبيل



On Fri, Aug 28, 2015 at 1:23 PM, Andrew 👽 Yourtchenko <[e-mail]>
wrote:

> inline.
>
> On 8/28/15, Ray Hunter (v6ops) <[e-mail]> wrote:
> > inline.
> >
> >> Andrew 👽 Yourtchenko <mailto:[e-mail]>
> >> 27 Aug 2015 17:20
> >> On 8/27/15, Ray Hunter (v6ops)<[e-mail]>  wrote:
> >>> [e-mail] wrote:
> >>>> This is to initiate a two week working group last call of
> >>>>
> http://tools.ietf.org/html/draft-ietf-v6ops-reducing-ra-energy-consumption
> .
> >>>> Please read it now. If you find nits (spelling errors, minor suggested
> >>>> wording changes, etc), comment to the authors; if you find greater
> >>>> issues, such as disagreeing with a statement or finding additional
> >>>> issues that need to be addressed, please post your comments to the
> >>>> list.
> >>>>
> >>>> We are looking specifically for comments on the importance of the
> >>>> document as well as its content. If you have read the document and
> >>>> believe it to be of operational utility, that is also an important
> >>>> comment to make.
> >>>>
> >>>>
> >>> I have read this draft. I understand the motivation, it is clearly
> >>> written, and I support it.
> >>>
> >>> Minor Suggestions:
> >>>
> >>> I'd reference 4861 in the first sentence of the intro.
> >>> s/Routing information is communicated to IPv6 hosts by Router
> >>> Advertisement messages. /Routing information is communicated to IPv6
> >>> hosts by Router Advertisement messages [RFC4861]/
> >>
> >> Thanks, noted!
> >>
> >>> Recommendation 2 is redundant IMHO. THere's no way a router
> manufacturer
> >>> can really know if the devices it is serving are battery powered
> devices
> >>> or not (perhaps the subject of another draft e.g. perhaps extension to
> >>> 4620 to discover this via NI on creating a new ND cache entry?)
> >>
> >> It's not entirely redundant, the intent here is that this mechanism is
> >> enabled on the network, which has two parts:
> >>
> >> 1) the equipment on the network has an option to enable it. (e.g. the
> >> administrator needs to ensure that their equipment supports it).
> >>
> >> 2) the administrator has enabled it. (e.g. today's Cisco
> >> implementation simply has the command "ipv6 nd ra solicited unicast"
> >> which needs to be configured).
> >>
> >> How about a small tweak as below:
> >>
> >> "2) Administrators of networks that serve large numbers (tens or
> >> hundreds) of battery-
> >>         powered devices SHOULD enable this behaviour."
> > Works for me.
> >>> For recommendation 3: the timing recommendations should be more
> >>> concrete, provided rough consensus can be achieved. In order to
> maximize
> >>> the benefit I'd suggest specifying the upper end of the suggested
> >>> ranges.
> >>
> >> I tend to configure such networks with the RA interval of 1800
> >> seconds, with router lifetime of 9000 seconds (and when
> >> draft-krishnan-6man-maxra gets through, will be happy to bump those
> >> values up to 21K and 64K respectively). Lorenzo's take is that "every
> >> few minutes is already much better than every 3 seconds".
> >>
> >> So, based on my today's knowledge the upper limit is whatever is
> >> enforced by the protocol + the usual "three-RA-per-lifetime" rule of
> >> thumb - which looks to be in line with the text in the draft that does
> >> not specify any upper bound.
> >>
> >> Does the text suggest differently ?
> > No, but it specifies an absolute value without explaining how that value
> > is derived.
>
> no, it specifies a *lower limit* - it tells the networks in question
> should send the RAs with the interval *bigger* than X - so it's not
> subject to change if the protocol limit increases. OTOH the X is kinda
> pulled out of the hat, I agree.
>
> So, how about the following change instead:
>
> s/Networks that serve battery-powered devices SHOULD NOT send
>         multicast RAs too frequently (e.g., more than one every 5-10
>         minutes for current battery-powered devices) unless the
>         information in the RA packet has substantially changed.  /
>
> Networks that serve battery-powered devices should try to maximize the
> interval between the  multicast RAs within the limits allowed by
> protocol - unless the information in the RA packet has changed. On the
> other hand, the maximum value should be bound to allow a sufficient
> number of RAs to be sent within the router/prefix lifetimes - to
> account for the potential packet loss in the wireless network. This
> packet loss will depend on the quality of the radio spectrum/coverage
> and may need to be decided on a per-network basis. In the best-case
> scenario one would ensure that at least 3 (a chosen arbitrary value)
> RAs are transmitted within the smallest of the lifetimes for the
> parameters contained within the RA.  /
>
> Or something along these lines.
>
> >
> > So if the protocols ever change, the BCP value may no longer appropriate
> > e.g. if draft-krishnan-6man-maxra becomes a standard.
> >
> > Why not specify in terms of the upper limit of the protocol, and
> > formula, rather than a specific time?
> >
> > e.g. MaxRtrAdvInterval/3 where MaxRtrAdvInterval at the time of writing
> > is 1800 seconds (derived from RFC4861 Section 6.2.1)
> >
> > Suggested text:
> >
> > s/Networks that serve battery-powered devices SHOULD NOT send
> >         multicast RAs too frequently (e.g., more than one every 5-10
> >         minutes for current battery-powered devices) unless the
> >         information in the RA packet has substantially changed.  If there
> >         is a desire to ensure that hosts pick up configuration changes
> >         quickly, those networks MAY send frequent Router Advertisements
> >         for a limited period of time (e.g., not more than one minute)
> >         immediately after a configuration change./
> >
> > 3. Routers with network interfaces that are known to serve
> > battery-powered devices SHOULD NOT send multicast RAs too frequently
> > unless the information in the RA packet has substantially changed.
> >
>
> Up until here I agree with the bullet point text, but I have a comment
> for the below.
>
> > The BCP value for MinRtrAdvInterval can be derived using the formula
> > 0.33 * MaxRtrAdvInterval. As of the time of writing this BCP, the
> > maximum permitted value of MaxRtrAdvInterval is 1800 seconds [RFC4861
> > Section 6.2.1] suggesting MaxRtrAdvInterval = 1800 and MinRtrAdvInterval
> > = 600 seconds.
>
> This part largely rephrases the text from RFC4861:
>
>       MinRtrAdvInterval
> ....
>
>                      Default: 0.33 * MaxRtrAdvInterval If
>                      MaxRtrAdvInterval >= 9 seconds; otherwise, the
>                      Default is MaxRtrAdvInterval.
>
> Why repeating it here ?
>
> Also, I find the reasoning using the final effective RA interval to be
> easier for the reader to get the spirit of the document, rather than
> prescribing the Min/Max values.
>
> Thus the suggested alternative wording above.
>
> >
> > 4. If there is a desire to ensure that hosts pick up configuration
> > changes quickly, those router interfaces MAY send frequent multicast RA
> > for a limited period of time immediately after a configuration change.
> >
> > A suggested (arbritary) time limit for this behavior is one minute.
>
> Splitting this into a separate bullet point for extra emphasis is
> reasonable indeed, thanks!
>
> --a
>
> > /
> >
> >>> s/Networks that serve battery-powered devices /Routers with network
> >>> interfaces that are known to serve battery-powered devices/
> >>>
> >>
> >> Thanks, noted!
> >>
> >> --a
> >>
> >>> --
> >>> regards,
> >>> RayH
> >>> <
> https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach
> >
> >>>
> >>
> >
> > --
> > regards,
> > RayH
> > <
> https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach
> >
> >
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops
>