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

[Andrew Dul]

Inline

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 1.0.0.0/8) 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 100.64.0.0/10


>  - 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.
>
>
>
>
> _______________________________________________
> PPML
> 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.htm>