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

From: [email-masked]
Date: Sun, 23 Aug 2015 11:00:01 -0700

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.

---

From: 神明達哉 <[email-masked]>
Date: Tue, 25 Aug 2015 10:54:50 -0700

> believe it to be of operational utility, that is also an important

I've read the draft.  It's well-written, and I think the topic and its
content are useful.

I have one minor comment on Section 2.2:

   Some networks send periodic multicast Router Advertisements (e.g.,
   once every few seconds).

I guess the intent here is explain non-default cases where multicast
RAs are sent out very frequently (correct?).  But the actual text
doesn't necessarily read that way to me, since sending multicast RAs
periodically is the default behavior per RFC4861, and the default
interval is between 200sec and 600sec.  Assuming my interpretation of
the intent is correct, I suggest revising this sentence as follows:

   Some networks send periodic multicast Router Advertisements very
   frequently (e.g., once every few seconds).

--
JINMEI, Tatuya

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Thu, 27 Aug 2015 15:13:15 +0200

> believe it to be of operational utility, that is also an important
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]/

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

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.

s/Networks that serve battery-powered devices /Routers with network 
interfaces that are known to serve battery-powered devices/

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>

---

From: Alejandro Acosta <[email-masked]>
Date: Thu, 27 Aug 2015 09:08:40 -0430

Hello,
  I fully support this draft, in fact, I believe that all draft should
have a mandatory "Eco-friendly" section.

  My comments:

In section 3 - Consequences

   o  Some hosts simply experience bad battery life on these networks
      and otherwise operate normally.  This is frustrating for users of
      these networks.

  The sentence: "This is frustrating for users of   these networks." 
does not convince me. The impact of a bad battery life is quite big, to
say it's just "frustrating" IMHO is not enough. I think it should be
remove or create a stronger sentence.

In section 4.2:

   2.  Networks that serve large numbers (tens or hundreds) of battery-
       powered devices SHOULD enable this behaviour.

  This might be a dummy question but I wonder if this is automatic or
something that will be adjusted by the administrator (or both). Probably
we could be more specific in this section, I mean, just to be more clear.

Regards,

Alejandro,

El 8/27/2015 a las 8:43 AM, Ray Hunter (v6ops) escribió:
> 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?)
>
> concrete, provided rough consensus can be achieved. In order to
> maximize the benefit I'd suggest specifying the upper end of the
> suggested ranges.
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Thu, 27 Aug 2015 17:20:29 +0200

> hosts by Router Advertisement messages [RFC4861]/

Thanks, noted!

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

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

> interfaces that are known to serve battery-powered devices/

Thanks, noted!

--a

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Thu, 27 Aug 2015 17:31:23 +0200

Hello Alejandro,

> remove or create a stronger sentence.

If Lorenzo agrees, I'd opt for removing the sentence about the
frustrated users.

> we could be more specific in this section, I mean, just to be more clear.

Yeah, looks like this text needs tweaking - both you and Ray has
commented on it, copypasting from my reply to him, so to check with
you:

--a

---

From: Andrew Yourtchenko <[email-masked]>
Date: Thu, 27 Aug 2015 17:39:12 +0200 (CEST)

>   frequently (e.g., once every few seconds).

Thanks for the catch, I think this was exactly what we intended to say 
here, I've noted it down.

--a

---

From: Alejandro Acosta <[email-masked]>
Date: Thu, 27 Aug 2015 11:24:41 -0430

Hello Andrew,
  Inline:

> If Lorenzo agrees, I'd opt for removing the sentence about the

Perfect

>        powered devices SHOULD enable this behaviour."

It sounds ok to me.
In the future (and not that far away) another draft could be written
about making routers smarter.., I mean, they can recognize the number of
devices in the network (in your example tens or hundreds) and change the
behavior automatically to your draft. It looks feasible to me.

Regards,

---

From: "Ray Hunter (v6ops)" <[email-masked]>
Date: Fri, 28 Aug 2015 10:09:59 +0200

inline.

> Andrew 👽 Yourtchenko <mailto:[email-masked]>
> 27 Aug 2015 17:20
> On 8/27/15, Ray Hunter (v6ops)<[email-masked]>  wrote:
>> [email-masked] wrote:
Works for me.
> 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.
/

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Fri, 28 Aug 2015 14:23:18 +0200

inline.

> No, but it specifies an absolute value without explaining how that value

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.

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

> Section 6.2.1] suggesting MaxRtrAdvInterval = 1800 and MinRtrAdvInterval

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.

> 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

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 28 Aug 2015 16:57:43 +0200

Le 27/08/2015 17:54, Alejandro Acosta a écrit :
> Hello Andrew, Inline:
>>> Hello, I fully support this draft, in fact, I believe that all
>>> draft should have a mandatory "Eco-friendly" section.
>>>
>>> My comments:
>>>
>>> o  Some hosts simply experience bad battery life on these
>>> networks and otherwise operate normally.  This is frustrating for
>>> users of these networks.
>>>
>>>
>>> The sentence: "This is frustrating for users of   these
>>> networks." does not convince me. The impact of a bad battery life
>>> is quite big, to say it's just "frustrating" IMHO is not enough.
>>> I think it should be remove or create a stronger sentence.
>>> 2.  Networks that serve large numbers (tens or hundreds) of
>>> battery- powered devices SHOULD enable this behaviour.
>>>
>>>
>>> This might be a dummy question but I wonder if this is automatic
>>> or something that will be adjusted by the administrator (or
>>> both). Probably we could be more specific in this section, I
>>> mean, just to be more clear.
>> commented on it, copypasting from my reply to him, so to check
>> with you:
>>
>> hundreds) of battery- powered devices SHOULD enable this
>> behaviour."
>
> It sounds ok to me. In the future (and not that far away) another
> draft could be written about making routers smarter..,

The link-layers should be smarter, not the Routers.  The link-layers
should have link-layer messages about expressing interest in joining
link-layer multicast groups (have mssages, not just API primitives).

Alex

  I mean, they can recognize the number of
> devices in the network (in your example tens or hundreds) and change
> the behavior automatically to your draft. It looks feasible to me.
>
> Regards,
>
>
>>
>> --a
>>
>>
>>>
>>> Regards,
>>>
>>> Alejandro,
>>>
>>>>> 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:
>>>>
>>>> Advertisement messages. /Routing information is communicated to
>>>> IPv6 hosts by Router Advertisement messages [RFC4861]/
>>>>
>>>> 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?)
>>>>
>>>> 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.
>>>>
>>>> s/Networks that serve battery-powered devices /Routers with
>>>> network interfaces that are known to serve battery-powered
>>>> devices/
>>>>
>>>>
>>>>
>>>> -- regards, RayH
>>>> v6ops mailing list [email-masked]
> _______________________________________________ v6ops mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Nabil Benamar <[email-masked]>
Date: Fri, 28 Aug 2015 19:43:58 +0100

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 <[email-masked]>
wrote:

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

---

From: Andrew 👽 Yourtchenko <[email-masked]>
Date: Sat, 29 Aug 2015 01:27:36 +0200

Hi Nabil,

Inline...

> On 28 Aug 2015, at 20:43, Nabil Benamar <[email-masked]> 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
>        minutes for current battery-powered devices)​..."​ 

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 <[email-masked]> wrote:
>> inline.
>>

---

From: Nabil Benamar <[email-masked]>
Date: Sat, 29 Aug 2015 09:30:53 +0100

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 <[email-masked]>
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
>
> 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 <[email-masked]
> > wrote:
>
>> inline.
>>

---

From: David Farmer <[email-masked]>
Date: Sun, 30 Aug 2015 16:59:06 -0500

I've read the draft, think it is important work, and support it.

However, I have a few comments;

1. Section "3. Consequences" seems to express disapproval of ignoring RA's or IPv6 traffic altogether while devices are asleep.  However, there are no recommendations regarding the proper behavior of host implementations in this respect within Section 4.  Please clearly recommend RAs not be ignored, if that is the intent.  Otherwise, maybe suggest an upper limit on the period RA's or IPv6 traffic MAY be ignored by host implementations.

2. Section "4. Recommendations" currently intermixes recommendations for router implementations and network operators.  I would like to see three sets of recommendations that clearly delineate the recommendations for router implementations, host implementations, and network operators separately.  This may cause some slight repetition, however I think the clarity provided would be very beneficial. 

3. I think it should be noted somewhere, maybe in the introduction;

While not specifically considered in this document, too frequent multicast Router Advertisement messages can negatively impact the performance of hosts and networks in many other ways than just energy consumption.

4. Section "7. Security Considerations" should note frequent sending of Rouge Router Advertisements could also severely impact power consumption on battery-powered hosts, see RFC6104, Section 3 and RA-Guard [RFC6105] for mitigation of Rouge Router Advertisements.

-- 
===============================================
David Farmer                          Email: [email-masked]
Office of Information Technology
University of Minnesota    
2218 University Ave SE         Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===============================================

> On Aug 23, 2015, at 13:00, [email-masked] wrote:
>

---

From: David Farmer <[email-masked]>
Date: Mon, 31 Aug 2015 00:12:27 -0500

> On Aug 30, 2015, at 16:59, David Farmer <[email-masked]> wrote:
> ...

Thinking about this a little bit more; most of the mitigation methods discussed in section 3 of RFC6104 are not effective for the power consumption issue, except 3.2 (which is RA-Guard) and 3.3 (ACLs).  The host would still see the Rouge RA messages with the other mitigation methods.  I also think it is important to note Rouge RAs can be caused by malicious activity or simply host misconfiguration.

So how about something like this;

7. Security Considerations

   The frequency of multicast Router Advertisement messages on a network will be 
   significantly increased with the addition of Rouge Router Advertisements [RFC6104]
   either from malicious activity or simply host misconfiguration.  RA-Guard [RFC6105] 
   or ACLs, as discussed in section 3.3 of RFC6104, effectively mitigate increased 
   power consumption on battery-powered hosts that would be caused by any Rouge 
   Router Advertisements.  

   While effective at ensuring proper default router information is delivered to hosts, 
   most of the other mitigation methods discussed in section 3 of RFC6104 do not 
   prevent the additional Router Advertisement messages from getting to hosts and 
   therefore do not mitigate the power consumption issue.  Furthermore, some of the 
   methods deliver even more Router Advertisement messages to hosts, exasperating 
   the power consumption issue.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 31 Aug 2015 17:41:21 +0900

>    power consumption on battery-powered hosts that would be caused by any

I think this paragraph is much too long. If your network does not have RA
guard, you have *way* bigger problems than just increased power
consumption. We can certainly mention RA guard in passing though.

>    the power consumption issue.

I think this text is superfluous. A host can always cause another host to
chew up battery by sending it unicast packets.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 31 Aug 2015 17:44:04 +0900

On Fri, Aug 28, 2015 at 9:23 PM, Andrew 👽 Yourtchenko <[email-masked]>
wrote:

> parameters contained within the RA.
>

I'd still prefer to have an absolute lifetime here, expressed in minutes.
Otherwise network administrators will do silly things like set max interval
= 12s, lifetime = 4s. I say "will" instead of "might" because I have
personally seen this happen on a network whose administrators should have
known better.

You make a very good point that text must be clear that this only applies
to periodic RAs, *not* to RAs sent when something has changed.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 31 Aug 2015 17:45:55 +0900

> If Lorenzo agrees, I'd opt for removing the sentence about the

Personally, I'd be more in favour of replacing "frustrating" with
"infuriating", but I guess removing it is fine too :-)

---

From: Nabil Benamar <[email-masked]>
Date: Mon, 31 Aug 2015 10:49:52 +0100

It makes sens Lorenzo to have exact values...but these values should be
expressed using a formula not arbitrary !

Best regards
Nabil    نبيل

On Mon, Aug 31, 2015 at 9:44 AM, Lorenzo Colitti <[email-masked]> wrote:

> On Fri, Aug 28, 2015 at 9:23 PM, Andrew 👽 Yourtchenko <[email-masked]
> > wrote:
>

---

From: Owen DeLong <[email-masked]>
Date: Mon, 31 Aug 2015 10:24:36 -0700

Yes and no… A pure formula means that the output is entirely dependent on the input.

If we don’t provide good guidance on valid (arguably arbitrary) input value ranges, then
silliness in = silliness out as Lorenzo mentioned.

Owen

> On Aug 31, 2015, at 02:49 , Nabil Benamar <[email-masked]> wrote:
> 
> It makes sens Lorenzo to have exact values...but these values should be expressed using a formula not arbitrary ! 
> 
> Best regards
> Nabil    نبيل
> 
> 
> 
> On Mon, Aug 31, 2015 at 9:44 AM, Lorenzo Colitti <[email-masked] <mailto:[email-masked]>> wrote:
> On Fri, Aug 28, 2015 at 9:23 PM, Andrew 👽 Yourtchenko <[email-masked] <mailto:[email-masked]>> wrote:
> I'd still prefer to have an absolute lifetime here, expressed in minutes. Otherwise network administrators will do silly things like set max interval = 12s, lifetime = 4s. I say "will" instead of "might" because I have personally seen this happen on a network whose administrators should have known better.
> 
> You make a very good point that text must be clear that this only applies to periodic RAs, *not* to RAs sent when something has changed.
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/v6ops <https://www.ietf.org/mailman/listinfo/v6ops>
> 
>