Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt

From: Erik Nordmark <[email-masked]>
Date: Thu, 5 Nov 2015 10:47:13 +0900

[Resent with corrected from address]

On 10/2/15 3:39 AM, Fred Baker (fred) wrote:
> Folks - I'd appreciate it if you would look at the update and comment 
> quickly. The big new text is in section 4 and the security 
> considerations. 
> https://tools.ietf.org/rfcdiff?url2=draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt 
>
>
> My issue is that I moved too quickly. I looked at the list traffic and 
> noted that it had come to a hiatus, and assumed that Lorenzo/Andrew 
> had dealt with the open issues. This draft is intended to be the 
> update that does that. However - I filed it with the IESG. If I need 
> to snatch it back, say so now, please.
Fred,

I had reviewed draft-ietf-v6ops-reducing-ra-energy-consumption-00 and 
fully agreed with the the recommendations in section 4 about 
implementation and configuration of routers.

However, in 01 there was a section added (4.2 - now 5.2) with device 
side recommendations/requirements, with with I have serious reservations 
at several levels:
1. The text uses terms like "maintain IPv6 connectivity" and "disconnect 
from the IPv6 network" which are not defined. I would not know what 
impact this has on an implementation with those terms being defined. 
E.g., does "disconnect" mean to discard all IPv6 addresses and prefixes 
and release all DHCPv6 leases? Kill all connections? What?

2. Section 5.2 changes (or at least clarifies) the IPv6 standards which 
seems to not be in scope in the v6ops charter.

Thus I think section 5.2 should be removed and that discussion be had in 
the 6man WG.

Sorry for not catching the scope expansion in -01 earlier.

Regards,
     Erik

>
>> On Oct 1, 2015, at 8:13 AM, Lorenzo Colitti <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> On Fri, Oct 2, 2015 at 12:09 AM, <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>           Title           : Reducing energy consumption of Router
>>     Advertisements
>>             Authors         : Andrew Yourtchenko
>>                               Lorenzo Colitti
>>             Filename        :
>>     draft-ietf-v6ops-reducing-ra-energy-consumption-02.txt
>>             Pages           : 6
>>             Date            : 2015-10-01
>>
>>
>> The changes from -02 are as follows:
>>
>>  1. Added a section on RA intervals and lifetimes.
>>  2. Added text on RA guard in the security considerations section.
>>
>> Both are in response to previous WG comments.
>> _______________________________________________
>> v6ops mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/v6ops
>
>
>
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Nov 2015 11:01:03 +0900

On Thu, Nov 5, 2015 at 10:47 AM, Erik Nordmark <[email-masked]> wrote:
>
> However, in 01 there was a section added (4.2 - now 5.2) with device side
> recommendations/requirements, with with I have serious reservations at
> several levels:
> from the IPv6 network" which are not defined. I would not know what impact
> this has on an implementation with those terms being defined. E.g., does
> "disconnect" mean to discard all IPv6 addresses and prefixes and release
> all DHCPv6 leases? Kill all connections? What?
>

"Maintain IPv6 connectivity" means "maintain the ability to correctly send
and receive IPv6 packets as configured by the network".

Example: suppose that while a node is asleep a network sends out a number
of RAs setting the lifetime of the current default router to 0 and adding
another default router, or changing the on-link prefix. The node's IPv6
connectivity is broken until such time that it receives an RA.

"Disconnect from the IPv6 network" means whatever process the device would
follow when disconnecting from the link.

Happy to clarify that in the draft if necessary.

> the 6man WG.

Section 5.2 changes does not clarify the standards. It provides operational
guidance to implementers. It points out that if implementations do not
listen to RAs when asleep, then they will lose the ability to correctly
send packets off-link, and says that if implementations want avoid that,
then they need to listen to RAs.

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Thu, 5 Nov 2015 04:10:29 +0000

> On Nov 5, 2015, at 10:43 AM, Erik Nordmark <[email-masked]> wrote:
> 
> Thus I think section 5.2 should be removed and that discussion be had in the 6man WG.

Dumb question - is your reservation a charter question or a technical question? If it's a charter question, one possible resolution would be to request a supporting 6man consensus statement. If it's technical, that is a whole different discussion.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Nov 2015 13:45:06 +0900

> recommendations/requirements, with with I have serious reservations at

Erik, are you still in Yokohama? Do you have time to discuss in person to
see if we can reach consensus?

---

From: James Woodyatt <[email-masked]>
Date: Thu, 5 Nov 2015 15:00:13 +0900

On Nov 5, 2015, at 10:47, Erik Nordmark <[email-masked]> wrote:
> 
> I had reviewed draft-ietf-v6ops-reducing-ra-energy-consumption-00 and fully agreed with the the recommendations in section 4 about implementation and configuration of routers.
> 
> However, in 01 there was a section added (4.2 - now 5.2) with device side recommendations/requirements, with with I have serious reservations at several levels:
> 1. The text uses terms like "maintain IPv6 connectivity" and "disconnect from the IPv6 network" which are not defined. I would not know what impact this has on an implementation with those terms being defined. E.g., does "disconnect" mean to discard all IPv6 addresses and prefixes and release all DHCPv6 leases? Kill all connections? What?

I had to talk verbally with Lorenzo before I understood this properly that A) “maintain IPv6 connectivity” means to delegate either an internal or an external sleep proxy with the task of remaining “reachable” under NUD, e.g. the ECMA ProxyZzzz service or the Bonjour Sleep Proxy service, and that B) “disconnect from the IPv6 network” means to detach from the link, thereby leaving the set of “reachable” nodes under NUD and entailing the commission of the DNAv6 procedure (RFC 6059) when the host reawakens and reattaches to the link.

Perhaps some wordsmithing would be in order, to use terminology more in keeping with the language of RFC 6059.

> 2. Section 5.2 changes (or at least clarifies) the IPv6 standards which seems to not be in scope in the v6ops charter.
> 

I’m opposed to that suggestion. The practice described in section 5.2 is necessary today for dealing with behavior of deployed networks that conform to existing standards. If 6MAN wants to clarify or improve the ND6 specification to change the need for the behavior documented here, then that would be splendid, but please count me on the list of people who prefer not to wait for the deliberations in 6MAN to resolve successfully before a practical solution to real world problems can be applied.

—james

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 5 Nov 2015 16:32:19 +0900

On Thu, Nov 5, 2015 at 3:00 PM, James Woodyatt <[email-masked]> wrote:

> I’m opposed to that suggestion. The practice described in section 5.2 is
> necessary today for dealing with behavior of deployed networks that conform
> to existing standards. If 6MAN wants to clarify or improve the ND6
> specification to change the need for the behavior documented here, then
> that would be splendid, but please count me on the list of people who
> prefer not to wait for the deliberations in 6MAN to resolve successfully
> before a practical solution to real world problems can be applied.
>

Erik, James and I worked on this together and I believe we're OK with the
following text:

   1.  Maintaining IPv6 connectivity requires that hosts be able to
       receive periodic multicast RAs [RFC4861]. Therefore, hosts that
       process unicast packets sent while they are asleep MUST also
       process multicast RAs sent while they are asleep. Hosts MAY
       rate-limit identical RAs if they are sent too frequently.

   2.  Mobile devices that do not intend to maintain IPv6 connectivity
       while asleep SHOULD either disconnect from the network, abandoning
       all IPv6 configuration, or perform DNAv6 procedures [RFC6059]
       when waking up.

Erik, James, can you confirm?

Cheers,
Lorenzo

---

From: James Woodyatt <[email-masked]>
Date: Thu, 5 Nov 2015 17:01:36 +0900

On Nov 5, 2015, at 16:32, Lorenzo Colitti <[email-masked]> wrote:
> On Thu, Nov 5, 2015 at 3:00 PM, James Woodyatt <[email-masked] <mailto:[email-masked]>> wrote:
> Erik, James and I worked on this together and I believe we're OK with the following text:
> 

I confirm. I’m tempted to suggest that inserting some subclause indicators in the second paragraph might improve the clarity. Like so:

  2.  Mobile devices that do not intend to maintain IPv6 connectivity
       while asleep SHOULD either A) disconnect from the network, abandoning
       all IPv6 configuration, or B) perform DNAv6 procedures [RFC6059]
       when waking up.

—james

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 5 Nov 2015 18:52:50 +0900

> Dumb question - is your reservation a charter question or a technical question? If it's a charter question, one possible resolution would be to request a supporting 6man consensus statement. If it'…
FWIW It was both as I specified the technically unclear aspects.

    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 5 Nov 2015 18:56:21 +0900

> Erik, James, can you confirm?
The above text works for me.

#1 captures how we've always thought IPv6 works.
And #2 captures that we have DNAv6 for the purposes of quickly 
re-attaching to a network e.g. when waking up.

    Erik

---

From: David Farmer <[email-masked]>
Date: Thu, 5 Nov 2015 09:12:36 -0600

-- 
===============================================
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 Nov 5, 2015, at 01:32, Lorenzo Colitti <[email-masked]> wrote:
> 

I still don't understand why this is using the term "mobile device", and the rest of the text uses "battery-powered host".  

Thanks

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 6 Nov 2015 10:54:20 +0900

Le 06/11/2015 00:12, David Farmer a écrit :
> <mailto:[email-masked]>
> On Nov 5, 2015, at 01:32, Lorenzo Colitti <[email-masked]
>>     I’m opposed to that suggestion. The practice described in section
>>     5.2 is necessary today for dealing with behavior of deployed
>>     networks that conform to existing standards. If 6MAN wants to
>>     clarify or improve the ND6 specification to change the need for
>>     the behavior documented here, then that would be splendid, but
>>     please count me on the list of people who prefer not to wait for
>>     the deliberations in 6MAN to resolve successfully before a
>>     practical solution to real world problems can be applied.
>>
>>
> I still don't understand why this is using the term "mobile device", and
> the rest of the text uses "battery-powered host".

If one needs to say mobile device, it would be ok to follow the 
terminology in the Mobility Terminology RFC - a Mobile Node.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 6 Nov 2015 11:00:17 +0900

> the rest of the text uses "battery-powered host".

Fix queued up for -03.

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 5 Nov 2015 10:43:51 +0900

Fred,

Regards,
     Erik