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

[Nabil Benamar <[e-mail]>]

Hi Andrew,

The suggested text is better than the original one. It doesn't contain an
arbitrary values for sending RAs. It replaces the "Networks administrators"
by " Networks", which is ok because we can't rely only on Admins to set up
the feature of RA unicast...Maybe another draft could tackle the issue of
smartness of routers and their ability to detect the nature of the network
in a given link (battery-powered devices )

Best regards
Nabil    نبيل



On Sat, Aug 29, 2015 at 12:27 AM, Andrew 👽 Yourtchenko <[e-mail]>
wrote:

> Hi Nabil,
>
> Inline...
>
> On 28 Aug 2015, at 20:43, Nabil Benamar <[e-mail]> wrote:
>
> 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 ?​
>
>
>
> Arbitrarily - on a basis that it is much better than every 3 seconds :-)
> I've sent the proposed text without arbitrary values (suggesting to
> maximize he interval within protocol limits taking into account potential
> packet loss).
>
> my message to Ray which you sent this reply to has a new proposed
> replacement text - could you take a look and tell what you think about it ?
>
> --a
>
> 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
>>
>
>