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

Andrew Dul andrew.dul at quark.net
Sat Apr 6 14:51:00 EDT 2013


On 3/27/2013 11:32 AM, Scott Leibrand wrote:
> As one of the AC shepherds for the policy, I am hoping to have a
> discussion, both here on PPML at at the upcoming ARIN meeting, to
> cover a few key points:
>  - Is the problem statement clear to the community?  Do you have any
> questions on the problem the proposal is attempting to solve?

My read of the problem is that wireless operators have been using space
beyond RFC 1918 (such as to solve their addressing needs and
now that this is becoming part of the "Internet" they need to move off
of that space. 

>  - 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?
With ARIN's /8 inventory currently at approximately 2.5, I'm skeptical
that any policy using global IPv4 unicast space can actually solve this
problem.    Even if we were to give a whole /8 to this problem, I'm
doubtful that is enough address space to solve this problem.

Class E space is available...and so is IPv6  :)

One could also use

>  - 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.
> So if you have any input now, please speak up.  We'll be locking down
> the version of the Draft Policy that will be printed in the ARIN 31
> discussion guides by April 5th, so please provide any input you can
> before then.

I currently don't see any "policy text" as we've normally come to
expect.  I'm certainly open to a discussion, but at this point we seem
to be discussing concepts and a method to work the problem rather than
specifically policy to solve the problem.  It would be good to have some
strawman text to discuss rather than just the concepts.

> Thanks,
> Scott
> 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.
> _______________________________________________
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (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 if you experience any issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20130406/9fcb66d4/attachment.html>

More information about the ARIN-PPML mailing list