<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Inline<br>
      <br>
      On 3/27/2013 11:32 AM, Scott Leibrand wrote:<br>
    </div>
    <blockquote
cite="mid:CAGkMwz5GUW2LZtnN+r3Ete6uepgTE1BLQnOaNJJRV5YWaificw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>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:</div>
        <div><br>
        </div>
        <div> - Is the problem statement clear to the community?  Do you
          have any questions on the problem the proposal is attempting
          to solve?</div>
      </div>
    </blockquote>
    <br>
    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.  <br>
    <br>
    <blockquote
cite="mid:CAGkMwz5GUW2LZtnN+r3Ete6uepgTE1BLQnOaNJJRV5YWaificw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div><br>
        </div>
        <div> - 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?</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    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.<br>
    <br>
    Class E space is available...and so is IPv6  :)<br>
    <br>
    One could also use 100.64.0.0/10<br>
    <br>
    <br>
    <blockquote
cite="mid:CAGkMwz5GUW2LZtnN+r3Ete6uepgTE1BLQnOaNJJRV5YWaificw@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div> - 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.</div>
        <div><br>
        </div>
        <div>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.</div>
      </div>
    </blockquote>
    <br>
    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.<br>
    <br>
    <br>
    <blockquote
cite="mid:CAGkMwz5GUW2LZtnN+r3Ete6uepgTE1BLQnOaNJJRV5YWaificw@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div>Thanks,</div>
        <div>Scott</div>
      </div>
      <div class="gmail_extra"><br>
        <br>
        <div class="gmail_quote">On Wed, Mar 27, 2013 at 11:20 AM, ARIN
          <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:info@arin.net" target="_blank">info@arin.net</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">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 moz-do-not-send="true"
              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 moz-do-not-send="true"
              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 moz-do-not-send="true"
              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
              moz-do-not-send="true" href="mailto:ARIN-PPML@arin.net"
              target="_blank">ARIN-PPML@arin.net</a>).<br>
            Unsubscribe or manage your mailing list subscription at:<br>
            <a moz-do-not-send="true"
              href="http://lists.arin.net/mailman/listinfo/arin-ppml"
              target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
            Please contact <a moz-do-not-send="true"
              href="mailto:info@arin.net" target="_blank">info@arin.net</a>
            if you experience any issues.<br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (<a class="moz-txt-link-abbreviated" href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).
Unsubscribe or manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/arin-ppml">http://lists.arin.net/mailman/listinfo/arin-ppml</a>
Please contact <a class="moz-txt-link-abbreviated" href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</pre>
    </blockquote>
    <br>
  </body>
</html>