Send ARIN-PPML mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.arin.net/mailman/listinfo/arin-ppml
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: Draft Policy ARIN-2013-2: 3GPP Network IP Resource Policy
(George, Wes)
2. Re: Draft Policy ARIN-2013-3: Tiny IPv6 Allocations for ISPs
(Milton L Mueller)
----------------------------------------------------------------------
Message: 1
Date: Tue, 9 Apr 2013 14:07:13 -0400
From: "George, Wes" <[email protected]>
To: Scott Leibrand <[email protected]>
Cc: ARIN-PPML List <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-2: 3GPP Network IP
Resource Policy
Message-ID:
<2671c6cdfbb59e47b64c10b3e0bd5923042d458...@prvpexvs15.corp.twcable.com>
Content-Type: text/plain; charset="us-ascii"
From: [email protected] [mailto:[email protected]] 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 <[email protected]<mailto:[email protected]>>
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 cell
ular 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
([email protected]<mailto:[email protected]>).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected]<mailto:[email protected]> 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:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130409/aaec77ed/attachment-0001.html>
------------------------------
Message: 2
Date: Wed, 10 Apr 2013 09:21:41 +0000
From: Milton L Mueller <[email protected]>
To: Paul Vixie <[email protected]>, "cb.list6" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [arin-ppml] Draft Policy ARIN-2013-3: Tiny IPv6
Allocations for ISPs
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
> so i thought i'd chime in: i consider that case to be extremely unmade as
> yet. even though i am in most other ways a free-marketeer. as stewards of a
> public resource ARIN has always been guided by RFC 2050 which requires
> recipients of these public resources to justify their need, no matter whether
> these resources are coming from a central pool or a private transfer.
[Milton L Mueller] This is a religious argument Paul. A statement of your
belief, nothing more. Can we try to move beyond that? We've all got beliefs.
I would like to know your definition of "public resource," and precisely how
such resources are different from other resources. Addresses are clearly not
"public goods" which is a term with a precise definition in economics, so don't
waste time arguing about that. The characteristics of public goods are well
known and IP numbers don't fit them (IP numbers are both rival in consumption
and excludable, so they are not public goods.)
But there is more. If you somehow succeed in providing a definition, I then
would like to see a scientific and/or logical derivation of how "being a public
resource" requires administrative needs assessment rather than market-based
allocation. What exactly is being optimized via needs assessment? Conservation?
Unlikely, higher prices do a better job of conserving than any other social
mechanism. In an environment in which the free pool is completely or almost
gone, and in which prices can do the work of rationing, please tell me why
needs assessments do anything we need to have done.
After you do those two things, you might explain why there is strong, perhaps
overwhelming support for eliminating needs assessment in the RIPE region. Have
they all gone mad there? Are they possessed by the Devil?
Looking forward to substantive exchanges on this topic
--MM
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.arin.net/pipermail/arin-ppml/attachments/20130410/70d67910/attachment.html>
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 94, Issue 30
*****************************************
