[arin-ppml] IP Address Policy

[Paul Vinciguerra]

Hi John,

We met at NANOG in Vancouver.  We were talking about how LISP is being deployed and how it impacts service providers.


We too are a small organization and had challenges this year getting our own addressing.  I will say that the ARIN analysts went out of their way to guide us through the process.  It was apparent that their goal was to find out how they could apply policy to  issue the resources as opposed to keeping them.



The difficulty for us is what you refer to as a bona fide need.   The policy's inconsistent application towards technology as a smaller provider is difficult to meet.  The analysts were clear that how you were going to use the addresses was not important as far as policy is concerned.  What we found out was that Anycast networks are the bastard child in terms of policy, and BGP multihoming is king.



We have a need for an anycast block for our services and have used one of our /24's for that purpose.  Because of that sparsely filled network, we will not be able to qualify for future addresses due never being able to meet the 80% utilization requirement.



The BGP Multihoming policy is what needs to change.  As long as someone can purchase two circuits, they can get a /24.  Technology has evolved where multihoming no longer needs to be constrained by the limitations of how BGP is deployed across the Internet.

I can think of way too many organizations with /24's allocated due to multihoming via BGP where only 5 or so addresses are in use.   With LISP, we multihome all the way down to single /32's.  Is there a bona fide need for organizations to multihome via BGP when there are other multihoming solutions available?

We can provide 30 or more multihomed sites in a single /24. The policy doesn't address value of address preservation.  I learned that.   The need is multihoming.  Is the deployment choice of achieving multihoming by BGP over LISP any more valid?  Is a sparsely populated multihomed network more valid  than our need for a sparsely populated anycast network?  Policy makes a technological exception for multihoming via BGP.

Anyone who is willing to pay the entry fee of a pair of circuits can get a /24.  As a small provider, catering to enterprises that expect no single points of failure, it's nearly impossible to build a distributed, highly available solution with a /22, but necessity IS the mother of invention....

I am glad to have the opportunity to participate of the discussion.

Regards,

Paul

Paul Vinciguerra
PRESIDENT
[Description: Description: cid:A37A812F-9283-4165-9459-FA9025300523]
120 W Park Avenue, Suite 308
Long Beach, NY 11561
P: 516-977-2095  *  F: 516-977-2482  *  TF: 866-998-4624
vinciconsulting.com/vxnet



From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran
Sent: Thursday, August 09, 2012 9:14 PM
To: Steven Ryerse
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] IP Address Policy

On Aug 9, 2012, at 6:10 PM, Steven Ryerse <SRyerse at eclipse-networks.com<mailto:SRyerse at eclipse-networks.com>> wrote:


... I do stand by my original point that it is not reasonable to deny resources solely because of organization size.

Steve -

  May I ask a question about the above point?  If ARIN assigns address space
  in this region to end-users, and an end-user comes to ARIN and requests a /30
  of IPv4 space (based on their actual need), on what basis does ARIN have to
  deny the end-user request if we have the space available and they have a
  bona fide need?

  Is it valid to deny the request because we have community developed and Board
  adopted policy that requires sufficient need to warrant a /24 assignment due to a
  minimum block size in the policy?

Thanks!
/John

John Curran
President and CEO
ARIN

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20120810/8d270ef0/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 14315 bytes
Desc: image001.png
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20120810/8d270ef0/attachment.png>