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

[Andrew 👽 Yourtchenko <[e-mail]>]

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