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

["Ray Hunter (v6ops)" <[e-mail]>]

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.

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.

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.

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

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