[arin-ppml] Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy

[George, Wes]

From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy

[WEG] /delurk, sorry I missed the deadline, but thought it was still important to provide some input before the meeting. I am opposed to this policy.

 - Is the problem statement clear to the community?  Do you have any questions on the problem the proposal is attempting to solve?
[WEG] clear, yes. Technically justified, not so much. I do not dispute that shuffling numbers around between mobility anchor (HA/P-GW/GGSN) or CGN instances within a mobile network is unpleasant, as is multiple reuse of RFC1918/6598 space. I also do not dispute that the submitter of the policy is attempting to solve a real problem within his company's implementation. I do, however, dispute the assertion that this is a mobile-industry-wide problem or somehow technically inherent to 3GPP networks, technically impossible, or even a new problem. I can speak from personal experience that some mobile providers waited as long as possible before moving to CGN, and as a result were/are required to do this shuffling of address blocks between mobility anchors to address uneven usage until they reached a documentable 80% utilization network-wide per ARIN policy. This was the reality, and they designed their tools and access lists and routing to manage that reality. Further, I can make a reasonable assumption based on what I know about other mobile providers that some of them have been successfully reusing the same 1918 space in multiple locations. Sure, it's cleaner to have addresses that are unique across a network, and to use global addresses instead of CGN, but sometimes one must make concessions to the cleanest design based on other factors (cost, resources, etc).

 - Do you feel that it is an important problem to try to solve?  Do you have any reasons you can share that we should or shouldn't do so?
[WEG] no, it's not an important problem to solve. At this point, changes to the burn rate of IPv4 due to changes in IPv4 *policy* rather than demand really need to stop. Most of the community have timelines built around assumptions for exhaustion that we have hung significant business and technical implementation plans on, and IMO this issue does not pass the bar to justify the change and upset those. Should we really be making it easier to justify more resources sooner for a specific industry that has already been both a major consumer of IPv4 addresses and reticent to deploy IPv6? I realize that it is unfair to paint the entire mobile industry with the same brush, as some providers are much better than others about both deploying IPv6 and conserving IPv4, but the reality is that if this policy is adopted, all of them benefit, and other potential consumers of addresses lose out for questionable technical benefit.

 - If so, how would you prefer we approach solving it?  Some suggestions are outlined in the proposal below, but we'll need to decide on an approach and write and discuss actual policy text in order to move this Draft Policy forward.  This proposal will *not* be eligible for last call after ARIN 31 in Barbados, but we will be discussing it there.
[WEG] Regarding the specific policy statement: in the mobile world, the difference between attached users and total subscribers has been rapidly disappearing as smartphones have replaced what the mobile industry calls "feature" phones for all but the most basic users (IIRC, smartphones overtook them as the majority last year). Even a few years ago, it was possible to assume a 3:1 or higher oversubscription on address use because the majority of phones were not using a data connection that frequently, and short DHCP leases could allow you to share addresses. The duration an address was in use largely tracked with the short periods of time when people were actively accessing content on their phones, and that usage was limited by the crap experience it represented. But smartphones offer a better user experience and therefore increase usage, and more importantly, are inherently "chatty" even when the user is not actively doing anything, due to background application updates. When you think about the fact that even one application relying on push notification can essentially drive you toward a constant data connection, and most devices have multiple simultaneous push apps running, it becomes increasingly difficult to assume that a significant percentage of devices will be idle long enough to make much of a difference when it comes to IP allocation (DHCP lease times). Note too that there is a difference between the amount of time that the *radio* is idle compared with the time that the data connection is idle, which is why push notifications are useful.

Thanks,
Wes George


On Wed, Mar 27, 2013 at 11:20 AM, ARIN <info at arin.net<mailto:info at arin.net>> wrote:
Draft Policy ARIN-2013-2
3GPP Network IP Resource Policy

On 21 March 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-184 3GPP Network IP Resource Policy" as a Draft Policy.

Draft Policy ARIN-2013-2 is below and can be found at:
https://www.arin.net/policy/proposals/2013_2.html

You are encouraged to discuss the merits and your concerns of Draft Policy 2013-2 on the Public Policy Mailing List. 2013-2 will also be on the agenda at the upcoming ARIN Public Policy Meeting in Barbados. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet Number Resource Policy as stated in the PDP. Specifically, these principles are:

 * Enabling Fair and Impartial Number Resource Administration
 * Technically Sound
 * Supported by the Community

The ARIN Policy Development Process (PDP) can be found at:
https://www.arin.net/policy/pdp.html

Draft Policies and Proposals under discussion can be found at:
https://www.arin.net/policy/proposals/index.html

Regards,

Communications and Member Services
American Registry for Internet Numbers (ARIN)


## * ##


Draft Policy ARIN-2013-2
3GPP Network IP Resource Policy

Date: 27 March 2013

Problem Statement:

Current 3GPP architectures consist of hierarchical aggregation, from cell site up to anchor nodes, approximately one per NFL city. Anchor nodes are the point where IP addresses are assigned and topologically positioned in the network. Generally an anchor node must be provisioned with enough addresses to handle all simultaneously attached users, plus enough headroom to handle failover from an adjacent anchor node in the event of an outage. Capacity planning generally ensures that all anchor nodes have approximately the same number of attached users at steady state. Moving addresses between anchor nodes would require significant renumbering effort and substantial increases in operational complexity, so cannot be performed during an outage. Generally addresses are not renumbered between anchor nodes: instead, aggregation nodes can be rehomed as needed to balance steady state capacity levels. Because of the 3GPP architecture's failover and capacity planning requirements, all cellular networks target approximately 50% simultaneous usage of each anchor node's IP addresses. However, even at 50% usage, the total number of subscribers generally exceeds the number of addresses needed.

Currently, a number of mobile networks are using non-RIR-assigned space internally to meet customer demand. However, there is insufficient private space (RFC1918, etc.) available for internal use, so other unassigned space is currently being used. As this unassigned space is brought into service via reclamation, returns, and transfers, it is no longer possible to use it internally, so globally unique space must be used instead. As a result, most of the need for additional RIR-assigned space is to serve existing customers, not to accommodate future growth.

Policy statement:

I can see two possible approaches to address this need. One approach would be to continue counting simultaneously attached users to measure IP needs, and apply a 50% usage requirement to justify allocations. Another approach would be to instead count total subscribers (rather than simultaneously attached users), and apply a much higher threshold, such as 80% or even 90%, to justify allocations.

Timetable for implementation: ASAP
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML at arin.net<mailto:ARIN-PPML at arin.net>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact info at arin.net<mailto:info at arin.net> if you experience any issues.


________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130409/aaec77ed/attachment.htm>