[arin-ppml] Multi-homing justification removed?
Owen DeLong
owen at delong.com
Mon Dec 1 19:04:21 EST 2014
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: <https://lists.arin.net/pipermail/arin-ppml/attachments/20141201/28186cf1/attachment.htm>
More information about the ARIN-PPML
mailing list