[arin-ppml] 2014:21.CI pool size

Rudolph Daniel rudi.daniel at gmail.com
Tue Dec 2 07:02:40 EST 2014


I Support this CI pool size increase.

Rudi Daniel
784 430 9235
On Dec 1, 2014 8:09 PM, <arin-ppml-request at arin.net> wrote:

> Send ARIN-PPML mailing list submissions to
>         arin-ppml at arin.net
>
> 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
>         arin-ppml-request at arin.net
>
> You can reach the person managing the list at
>         arin-ppml-owner at arin.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of ARIN-PPML digest..."
>
>
> Today's Topics:
>
>    1. Advisory Council Meeting Results - November 2014 (ARIN)
>    2. Draft Policy ARIN-2014-21: Modification to CI Pool Size per
>       Section 4.4 (ARIN)
>    3. Draft Policy ARIN-2014-22: Removal of Minimum in  Section 4.10
>       (ARIN)
>    4. Weekly posting summary for ppml at arin.net (Thomas Narten)
>    5. Re: Multi-homing justification removed? (Owen DeLong)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 25 Nov 2014 15:34:58 -0500
> From: ARIN <info at arin.net>
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Advisory Council Meeting Results - November 2014
> Message-ID: <5474E7F2.60606 at arin.net>
> Content-Type: text/plain; charset=gbk; format=flowed
>
> In accordance with the ARIN Policy Development Process (PDP), the ARIN
> Advisory Council (AC) met on 20 November 2014.
>
> The AC recommended the following to the ARIN Board for adoption:
>
>    Recommended Draft Policy ARIN-2014-9: Resolve Conflict Between RSA
> and 8.2 Utilization Requirements
>
> The AC accepted the following Proposals as a Draft Policies:
>
>    ARIN-prop-213 Modification to CI Pool Size per Section 4.4
>    ARIN-prop-214 Removal of Minimum in Section 4.10
>
> The AC is continuing to work on the following:
>
>    Draft Policy ARIN-2014-1: Out of Region Use
>    Draft Policy ARIN-2014-6: Remove 7.1 [Maintaining IN-ADDRs]
>    Draft Policy ARIN-2014-14: Removing Needs Test from Small IPv4 Transfers
>    Draft Policy ARIN-2014-17: Change Utilization Requirements from
> last-allocation to total-aggregate
>    Draft Policy ARIN-2014-19: New MDN Allocation Based on Past Utilization
>
> Draft Policy and Proposal texts are available at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ------------------------------
>
> Message: 2
> Date: Tue, 25 Nov 2014 15:35:15 -0500
> From: ARIN <info at arin.net>
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy ARIN-2014-21: Modification to CI
>         Pool Size per Section 4.4
> Message-ID: <5474E803.9020504 at arin.net>
> Content-Type: text/plain; charset=gbk; format=flowed
>
> On 20 November 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-213 Modification to CI Pool Size per Section 4.4" as a Draft
> Policy.
>
> Draft Policy ARIN-2014-21 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_21.html
>
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-21 on the Public Policy Mailing List.
>
> 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-2014-21
> Modification to CI Pool Size per Section 4.4
>
> Date: 25 November 2014
>
> Problem Statement:
>
> At the time that this section of policy was written, IXP growth in North
> America was stagnant. Efforts of late have increased significantly
> within the IXP standards and other communities to improve critical
> infrastructure in North America. This effort is paying dividends and we
> project that a /16 will not be enough to continue to improve global
> interconnect conditions and support needed IXP CI infrastructure.
>
> Policy statement:
>
> Change to text in section 4.4 Micro Allocations:
>
> Current text:
>
> ARIN will place an equivalent of a /16 of IPv4 address space in a
> reserve for Critical Infrastructure, as defined in section 4.4. If at
> the end of the policy term there is unused address space remaining in
> this pool, ARIN staff is authorized to utilize this space in a manner
> consistent with community expectations.
>
> Proposed text to replace current text entirely:
>
> ARIN will place an equivalent of a /15 of IPv4 address space in a
> reserve for Critical Infrastructure, as defined in section 4.4.
>
> Timetable for implementation: Immediate
>
>
> ------------------------------
>
> Message: 3
> Date: Tue, 25 Nov 2014 15:35:29 -0500
> From: ARIN <info at arin.net>
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Draft Policy ARIN-2014-22: Removal of Minimum in
>         Section 4.10
> Message-ID: <5474E811.40500 at arin.net>
> Content-Type: text/plain; charset=gbk; format=flowed
>
> On 20 November 2014 the ARIN Advisory Council (AC) accepted
> "ARIN-prop-214 Removal of Minimum in Section 4.10" as a Draft Policy.
>
> Draft Policy ARIN-2014-22 is below and can be found at:
> https://www.arin.net/policy/proposals/2014_22.html
>
> You are encouraged to discuss the merits and your concerns of Draft
> Policy 2014-22 on the Public Policy Mailing List.
>
> 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-2014-22
> Removal of Minimum in Section 4.10
>
> Date: 25 November 2014
>
> Problem Statement:
>
> The current section 4.10 Dedicated IPv4 block to facilitate IPv6
> Deployment creates an issue where a small new organization that requires
> an IPv4 allocation or assignment would potentially receive a block that
> today would be unroutable and therefore unusable for it intended purposes.
>
> Policy statement:
>
> Change
>
> "This block will be subject to a minimum size allocation of /28 and a
> maximum size allocation of /24. ARIN should use sparse allocation when
> possible within that /10 block."
>
> To
>
> "This block will be subject to an allocation of /24. ARIN should use
> sparse allocation when possible within that /10 block."
>
> Timetable for implementation: Immediate
>
>
> ------------------------------
>
> Message: 4
> Date: Fri, 28 Nov 2014 00:53:04 -0500
> From: Thomas Narten <narten at us.ibm.com>
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Weekly posting summary for ppml at arin.net
> Message-ID: <201411280553.sAS5r4he009466 at rotala.raleigh.ibm.com>
> Content-Type: text/plain; charset=us-ascii
>
> Total of 5 messages in the last 7 days.
>
> script run at: Fri Nov 28 00:53:03 EST 2014
>
>     Messages   |      Bytes        | Who
> --------+------+--------+----------+------------------------
>  60.00% |    3 | 55.51% |    18354 | info at arin.net
>  20.00% |    1 | 22.60% |     7473 | athompso at athompso.net
>  20.00% |    1 | 21.89% |     7240 | narten at us.ibm.com
> --------+------+--------+----------+------------------------
> 100.00% |    5 |100.00% |    33067 | Total
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 1 Dec 2014 16:04:21 -0800
> From: Owen DeLong <owen at delong.com>
> To: Scott Leibrand <scottleibrand at gmail.com>
> Cc: "arin-ppml at arin.net" <arin-ppml at arin.net>
> Subject: Re: [arin-ppml] Multi-homing justification removed?
> Message-ID: <E2740FF8-B6A5-4891-A251-BD142F8A39F8 at delong.com>
> Content-Type: text/plain; charset="utf-8"
>
> FWIW, Scott, your interpretation agrees with my recollection and my
> intents along the way.
>
> I am not convinced that such a policy applied to the transfer market is a
> good idea. I believe that portable blocks place sufficient demand on
> internet resources that having a some number of hosts behind them (50%+) is
> not an unreasonable requirement regardless of whether the block is freshly
> minted from the RIR or recycled.
>
> Owen
>
> > On Nov 20, 2014, at 9:42 AM, Scott Leibrand <scottleibrand at gmail.com>
> wrote:
> >
> > Steve,
> >
> > I think your interpretation of 4.3.2.2 is incorrect.  That policy
> section was not the one that authorized the receipt of a (PA) /24 for
> multihoming.  That was, and still is, 4.2.3.6 <http://4.2.3.6/>:
> > https://www.arin.net/policy/nrpm.html#four236 <
> https://www.arin.net/policy/nrpm.html#four236>, which states that "The
> ISP will then verify the customer's multihoming requirement and may assign
> the customer a /24, based on this policy."
> >
> > 4.3.2.2 states that the minimum allocation size (from ARIN) for
> multihomed end users was a /24.  However, that did not allow you to get a
> /24 from ARIN just by becoming multihomed. If you were/are in that
> situation, you always had to (and still have to) get your /24 from your
> upstream if you don't meet ARIN's /24 utilizatinon criteria, and
> demonstrate efficient utilization before getting one from ARIN.
> >
> > If my understanding does not match how policy was implemented by staff
> prior to implementation of ARIN-2014-13 on 17 September 2014, someone
> please correct me, but that was the intent of the policy as I understand it.
> >
> > When discussing 2014-13, my sense of the community was that we did not
> want to authorize receipt of a /24 from ARIN solely based on multihoming,
> because that could possibly open up a land rush of organizations spun up
> solely for the purpose of getting a /24 from the free pool, holding it for
> the requisite time, and then selling it on the transfer market.  I
> personally would be more amenable to considering a policy change to
> liberalize the requirements for getting a /24 if/when they're available
> from the transfer market only.
> >
> > -Scott
> >
> > On Thu, Nov 20, 2014 at 9:26 AM, Steve King <steve.king at iconaircraft.com
> <mailto:steve.king at iconaircraft.com>> wrote:
> > Multi-homing was not a requirement.   It was an alternate
> justification.  I can?t honestly meet the 50% utilization requirement for a
> /24, but under the pre-September rules I qualified for a /24 under 4.3.2.2
> because I contract with multiple carriers and want to participate in BGP
> for failover.
> >
> >
> >
> > Now that the language in 4.3.2.2 is gone, my reading is I have to either:
> >
> >
> >
> > a)      Lie about my utilization.  Not willing to do that.
> >
> > b)      Beg for a BGP-transferrable block from a carrier, and even then,
> deal with the fact that other ISPs are far more likely to aggregate and
> filter specific routes to large carrier-assigned blocks.  I end up with a
> less reliable failover solution.
> >
> >
> >
> > The policy revision is a significant step backward for me.  Maybe I?m
> enough of an edge case to not matter.  But ARIN-2014-13 stated 4.3.2.2 was
> redundant given the lowered minimum allocation in 4.3.2.1.  It was not
> redundant.  It covered a case that I think matters.
> >
> >
> >
> > The worst part is, I?m probably going to end up with two non-BGP
> transferrable /24s from two carriers (we all know they hand them out like
> candy with big circuits), so I?ll end up burning more IPV4 space than I
> otherwise would.
> >
> >
> >
> >
> >
> >
> >
> > Steve King
> >
> > ICON Aircraft
> >
> >
> >
> > From: John Von Stein [mailto:John at qxccommunications.com <mailto:
> John at qxccommunications.com>]
> > Sent: Wednesday, November 19, 2014 9:18 PM
> > To: Richard J. Letts; Steve King; arin-ppml at arin.net <mailto:
> arin-ppml at arin.net>
> > Subject: RE: Multi-homing justification removed?
> >
> >
> >
> > Speaking from recent / current experience, the multi-homing requirement
> is a bit of a challenge for tweener-sized organizations like QxC.  We are
> too big for underlying fiber carriers to comfortably continue to supply our
> need for IP addresses but not in the position to carry the financial,
> technical or operational challenges of multi-homing.  This was a very
> significant cost commitment for QxC and I can imagine this is not
> achievable for other like-sized ISPs.  Granted, we are better off for it
> now but had I known how much of a financial and technical hurdle this
> really was then I probably would not have done it.  I just needed more IP
> addresses to continue to grow my biz and would have much rather spent the
> money and manpower on marketing/sales/customer acquisition.  Multi-homing
> is a nice-to-have luxury that none of my customers are willing to pay for
> so it is simply a cost of entry to get the IP addresses we need to continue
> to grow our customer base.
> >
> >
> >
> > As such, I support dropping multi-homing as a prerequisite for an IP
> allocation.
> >
> >
> >
> > Thank you,
> >
> > John W. Von Stein
> >
> > CEO
> >
> >
> >
> > <image001.jpg>
> >
> >
> >
> > 102 NE 2nd Street
> >
> > Suite 136
> >
> > Boca Raton, FL 33432
> >
> > Office: 561-288-6989 <tel:561-288-6989>
> > www.QxCcommunications.com <http://www.qxccommunications.com/>
> >
> >
> > This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed.
> >
> >
> >
> > From: arin-ppml-bounces at arin.net <mailto:arin-ppml-bounces at arin.net>
> [mailto:arin-ppml-bounces at arin.net <mailto:arin-ppml-bounces at arin.net>]
> On Behalf Of Richard J. Letts
> > Sent: Wednesday, November 19, 2014 1:24 PM
> > To: Steve King; arin-ppml at arin.net <mailto:arin-ppml at arin.net>
> > Subject: Re: [arin-ppml] Multi-homing justification removed?
> >
> >
> >
> > I believe the intent was there.
> >
> >
> >
> > orgs that have a justifiable/provable need for a /24 were been
> restricted by their current/lone provider being unwilling to give them
> enough address space. Not everyone has the ability to change providers, and
> if you can?t change providers then you certainly would not be able to
> multihome..
> >
> >
> >
> > Richard Letts
> >
> >
> >
> > From: arin-ppml-bounces at arin.net <mailto:arin-ppml-bounces at arin.net>
> [mailto:arin-ppml-bounces at arin.net <mailto:arin-ppml-bounces at arin.net>]
> On Behalf Of Steve King
> > Sent: Wednesday, November 19, 2014 9:47 AM
> > To: arin-ppml at arin.net <mailto:arin-ppml at arin.net>
> > Subject: [arin-ppml] Multi-homing justification removed?
> >
> >
> >
> > The changes implemented in ARIN-2014-13, specifically the removal of
> 4.3.2.2, appear to have removed the multi-homing justification for a /24
> for end users.  Previously, the need to multi-home, and proof of contracts
> with multiple upstream providers, was sufficient to justify a /24 to
> participate in BGP.
> >
> >
> >
> > For reassignments from ISPs, the language remains in 4.2.3.6.  Users can
> justify a /24 via a requirement to multi-home rather than utilization
> rate.  However this revision appears to leave utilization rate as the only
> criterion for direct end-user assignments.
> >
> >
> >
> > Was this the intent or possibly an overlooked side effect of the change?
> >
> >
> >
> >
> >
> >
> >
> > Steve King
> >
> > ICON Aircraft
> >
> >
> >
> >
> > _______________________________________________
> > 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 <
> 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: <
> http://lists.arin.net/pipermail/arin-ppml/attachments/20141201/28186cf1/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> ARIN-PPML mailing list
> ARIN-PPML at arin.net
> http://lists.arin.net/mailman/listinfo/arin-ppml
>
> End of ARIN-PPML Digest, Vol 114, Issue 1
> *****************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20141202/04380079/attachment.htm>


More information about the ARIN-PPML mailing list