Subject: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT)

From: Suresh Krishnan <[email-masked]>
Date: Wed, 16 Aug 2017 15:54:15 -0700

Suresh Krishnan has entered the following ballot position for
draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-unique-ipv6-prefix-per-host/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

* Section 4

It is not clear what you intend here

"IPv6 Router Advertisement Interval = 300s"

The router advertisement interval is not configured as an absolute value but as
minimum and maximum bounds (MinRtrAdvInterval and MaxRtrAdvInterval) which are
used to calculate the actual advertisement interval. When the RA is sent from
an interface, the actual interval is an uniformly distributed random value
between the MinRtrAdvInterval and MaxRtrAdvInterval. At the very minimum you
need to clarify if you would like to have this as a lower bound or as an upper
bound.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 4

-> I think text is needed here to handle the case where the DNS server is
provided in the RA itself  (RFC8106)

"In addition it will use stateless DHCPv6 to get the IPv6 address of the DNS
server"

-> I am not sure what is the motivation for this text.

"however it SHOULD NOT use stateful DHCPv6 to receive a service provider
managed IPv6 address"

-> This text seems incorrect

"due to the L-bit set, it SHOULD send this traffic to the First Hop Provider
Router"

I think it should be the exact opposite. i.e. say *unset* instead of set

"due to the L-bit being unset, it SHOULD send this traffic to the First Hop
Provider Router"

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Aug 2017 08:15:14 +0900

> "IPv6 Router Advertisement Interval = 300s"

I'll also point out yet again that this value is in conflict with RFC 7772
in the case of networks that are provide service for battery-powered
devices. The text should either be changed to follow that RFC or to explain
the reason for the conflict.

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 21 Aug 2017 12:57:59 +0000

Hi Suresh,
   
Many thanks for the review and finding these issues. What do you think of the proposals below to fix those points of attention?

    * Section 4

    
    
GV> I changed the line to make it more clear that the timer indicates the maximum Advertisement Interval
GV>          <t>Maximum IPv6 Router Advertisement Interval = 300s</t>

    * Section 4

    

    

    
GV> What about the following modification in the text:

OLD:
The architected result of designing the RA as documented above is
   that each UE/subscriber gets its own unique IPv6 prefix for which it
   can use SLAAC or any other method to select its /128 unique address.
   In addition it will use stateless DHCPv6 to get the IPv6 address of
   the DNS server, however it SHOULD NOT use stateful DHCPv6 to receive
   a service provider managed IPv6 address.  If the UE/subscriber
   desires to send anything external including other UE/subscriber
   devices (assuming device to device communications is enabled and
   supported), then, due to the L-bit set, it SHOULD send this traffic
   to the First Hop Provider Router.

New:
The architected result of designing the RA as documented above is
that each UE/subscriber gets its own unique IPv6 prefix for which it
can use SLAAC or any other method to select its /128 unique address. 
Either stateless DHCPv6 <xref target="RFC3736">RFC3736</xref> or IPv6 
Router Advertisement Options for DNS Configuration 
<xref target="RFC8106">RFC8106</xref> can be used to get the 
IPv6 address of the DNS server. If the UE/subscriber desires to send
anything external including other UE/subscriber devices (assuming device
to device communications is enabled and supported), then, due to the
L-bit being unset, it SHOULD send this traffic to the First Hop Provider
Router.</t>

Kind Regards,
G/

---

From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" <[email-masked]>
Date: Mon, 21 Aug 2017 13:16:31 +0000

Hi Lorenzo,

The mentioned timer comes from John Brzozowski’s big scale network deployment…
RFC7772 indicates that for laptops etc it does not really matter regarding battery power, but that for energy conservative devices currently a 7 RA’s per hour (assuming those consume 0.1mW).

I’ll leave it to John Brzozowski to provide feedback regarding setting of timer to 300 sec has been a practical user experience problem for network users? Maybe there is user experience info
now that the deployment has been out in the wild for some time.

The current modified text proposal is:
   Maximum IPv6 Router Advertisement Interval = 300s

Alternatively, RFC4861 documents some timers, and maybe its better for draft-ietf-v6ops-unique-ipv6-prefix-per-host to reference RFC4861 timers instead? Maybe this draft should only document prefix-life times?

G/

From: Lorenzo Colitti <[email-masked]>
Date: Thursday, 17 August 2017 at 01:15
To: Suresh Krishnan <[email-masked]>
Cc: The IESG <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked] WG" <[email-masked]>
Subject: Re: [v6ops] Suresh Krishnan's Discuss on draft-ietf-v6ops-unique-ipv6-prefix-per-host-07: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Ron Bonica <[email-masked]>
Resent-Date: Thursday, 17 August 2017 at 01:15

On Thu, Aug 17, 2017 at 7:54 AM, Suresh Krishnan <[email-masked]<mailto:[email-masked]>> wrote:
It is not clear what you intend here

I'll also point out yet again that this value is in conflict with RFC 7772 in the case of networks that are provide service for battery-powered devices. The text should either be changed to follow that RFC or to explain the reason for the conflict.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 21 Aug 2017 23:06:24 +0900

On 21 Aug 2017 22:16, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <
[email-masked]> wrote:

RFC7772 indicates that for laptops etc it does not really matter regarding
battery power, but that for energy conservative devices currently a 7 RA’s
per hour (assuming those consume 0.1mW).

Right, there is a conflict - a max RA interval of 300s is a min interval of
100s and an average interval of 200s. That's 18 RAs per hour. 7772
recommends about 7.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 22 Aug 2017 19:31:30 -0400

Hi Gunter,
  Thanks for the proposed text changes. They adequately address my DISCUSS points. I am hoping you will also converge in the discussion with Lorenzo on the actual value for the timer and/or specify an applicability statement. I will clear once the new revision posts.

Regards
Suresh

> On Aug 21, 2017, at 8:57 AM, Van De Velde, Gunter (Nokia - BE/Antwerp) <[email-masked]> wrote:
> 
> Hi Suresh,
>