<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> arin-ppml-bounces@arin.net [mailto:arin-ppml-bounces@arin.net]
<b>On Behalf Of </b>Scott Leibrand<br>
<b>Subject:</b> Re: [arin-ppml] Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal"><b><i><span style="color:#1F497D">[WEG] </span></i></b><span style="color:#1F497D">/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.
</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> - Is the problem statement clear to the community? Do you have any questions on the problem the proposal is attempting to solve?<o:p></o:p></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[WEG]
</span></i></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">clear, yes.<b><i>
</i></b>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).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> - 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?<span style="color:#1F497D"><o:p></o:p></span></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[WEG]
</span></i></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">no, it’s not an important problem to solve. At this point, changes to the burn rate of IPv4 due to changes in IPv4 *<b>policy</b>* 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.<b><i><o:p></o:p></i></b></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> - 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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">[WEG]
</span></i></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">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 *<b>radio</b>*
is idle compared with the time that the data connection is idle, which is why push notifications are useful.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D">Wes George<o:p></o:p></span></p>
<p class="MsoNormal"><b><i><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></i></b></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D"><o:p> </o:p></span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">On Wed, Mar 27, 2013 at 11:20 AM, ARIN <<a href="mailto:info@arin.net" target="_blank">info@arin.net</a>> wrote:<o:p></o:p></p>
<p class="MsoNormal">Draft Policy ARIN-2013-2<br>
3GPP Network IP Resource Policy<br>
<br>
On 21 March 2013 the ARIN Advisory Council (AC) accepted "ARIN-prop-184 3GPP Network IP Resource Policy" as a Draft Policy.<br>
<br>
Draft Policy ARIN-2013-2 is below and can be found at:<br>
<a href="https://www.arin.net/policy/proposals/2013_2.html" target="_blank">https://www.arin.net/policy/proposals/2013_2.html</a><br>
<br>
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:<br>
<br>
* Enabling Fair and Impartial Number Resource Administration<br>
* Technically Sound<br>
* Supported by the Community<br>
<br>
The ARIN Policy Development Process (PDP) can be found at:<br>
<a href="https://www.arin.net/policy/pdp.html" target="_blank">https://www.arin.net/policy/pdp.html</a><br>
<br>
Draft Policies and Proposals under discussion can be found at:<br>
<a href="https://www.arin.net/policy/proposals/index.html" target="_blank">https://www.arin.net/policy/proposals/index.html</a><br>
<br>
Regards,<br>
<br>
Communications and Member Services<br>
American Registry for Internet Numbers (ARIN)<br>
<br>
<br>
## * ##<br>
<br>
<br>
Draft Policy ARIN-2013-2<br>
3GPP Network IP Resource Policy<br>
<br>
Date: 27 March 2013<br>
<br>
Problem Statement:<br>
<br>
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.<br>
<br>
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.<br>
<br>
Policy statement:<br>
<br>
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.<br>
<br>
Timetable for implementation: ASAP<br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
<br>
<hr>
<font face="Arial" color="Gray" size="1">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.<br>
</font>
</body>
</html>