[arin-ppml] [Remco.vanMook at eu.equinix.com:[address-policy-wg]newpolicyidea for PA allocations]

[John Santos]

(Not sure if I should top-post or bottom-post as this thread seems to
be a mixture!)

There may be other ways of fullfilling the same goal (which, as I understand
it, is preventing one large allocation from consuming all the remaining
address space.)

As the bigger chunks get allocated, requests start getting filled by
allocating/assigning multiple smaller chunks.  (Someone reported this
has already happened, but in that case, one of the smaller chunks was
contiguous with one of their existing allocations.  That shouldn't
count in this scenario.)

My suggestion is putting an upper limit on the number of "chunks" that
will be issued to satisfy a request.  The requests would be filled on
a first-come/first-served on a best effort basis, but no more than X
"chunks".  I think X=4 would probably be appropriate, but that's just a 
gut feeling.

Say there are 1 /8, 3 /12's, 15 /16's and 240 /20's left.  Some one
requests a /14, they get a 1/4 of 1 of the /12's, or however the staff
would handle this now.   Someone asks for a /16, they just get it.

Sometime later, the last /8 is gone, or split up, and someone needs
a /10.  They get the last 3 /12's and one /16.   (If someone asked for
a /8, instead they get the same thing.)  Now ARIN's down to a handful
of /16's and loads of smaller blocks.  If someone requests a /10, they
get 4 /16's, not everything that's left.

It seems to me this might be easier for the staff to handle; they
just go through their normal allocation procedure, but after hitting
the 4th time through the loop trying to satisfy the request, they
stop.


It seems to me this is a policy, not an operational matter, since it
answers the question "What do we do when someone requests an allocation
larger than (or of the same order of magnitude) as the remaining
available address space?"

Do we want pure first-come/first-served, or do we want some kind of
"everybody gets a little bit" policy?



Whether any of these schemes actually work depends on the latency
and queue depth.  If the latency and queue depth are 0, the requester
just keeps filing requests until they got all the space they need
or ARIN runs out completely.  If they have to wait some period
(either a few days or weeks while the allocation procedure executes,
or several months to a year if a minumum "can't request more"
period expires, then others will get a chance to put in their
requests.  If the queue depth is non-zero, then at least those
others in queue, even with a minimal request interval, will get
their (partial) allocations.  I don't understand how the rules about
requesting more space apply in this circumstance (I though you had
to wait at least 6 months, but maybe you just have to wait until
you can demonstrate usage of your supposed 6-month supply.)  And
I have no idea what the queue depth is (how many people/organizations
have filed requests for allocations that have not yet been fulfilled)
at any given moment.

I hope this suggestion doesn't just muddy the waters.

-- John




On Fri, 8 Aug 2008, Matthew Wilder wrote:

> As the last email here mentions, this is really a matter of spreading out truly the last of the IP Address wealth.  If there is enough for the banker to get his fill and everyone else before the banker comes back again, any change in policy will probably 
> be nothing more than a wasteful exercise in
> itself.  If people agree that it is the scenario in question that raises concern (banker getting the last of the gas) then maybe there is a place for a policy given the following condition.
> 
> Condition:
> Projections show that a RIR's available pool of addresses is due to 
exhaust in approximately 12 months or less.
> 
> Policy that activates upon this condition:
> The RIR begins to satisfy each ISP's 3 month requirement of IP Addresses,
as opposed to their 6 or 12 month projections.  
> 
> Implications:
> In theory, as long as requests do not irrationally accelerate (which
can itself be encouraged) then the last of the IP Addresses won't be
entirely consumed by as large allocations.  This policy would result in
a somewhat greater level of fragmentation dur
> ing the final allocations, but delays the
> timing of the increased fragmentation from other suggestions.
> 
> -MW
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Kargel
> Sent: Friday, August 08, 2008 12:00 PM
> To: ppml at arin.net
> Subject: Re: [arin-ppml][Remco.vanMook at eu.equinix.com:[address-policy-wg]newpolicyidea for PA allocations]
> 
> Yeah, but let's say you are the local small town gas station..  You are running close to empty so your pumps only put out 3 gallons at a time and you have 60 gallons left.  There is a line of cars at the pump, some boy scouts who need to make money for ca
> mp with their lawn mower are waiting
> patiently and washing windows, your mom is at the back of the line.  On top of all this you remember you didn't fill your suburban this morning..  Do you let the banker who is at the head of the line buy all 60 gallons for an exhorbitant fee or do you spr
> ead it out around town??
> 
> I'm not saying one is better than the other, but you do have choices to make.. 
> 
> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Alexander, Daniel
> Sent: Friday, August 08, 2008 10:20 AM
> To: Howard, W. Lee; ppml at arin.net
> Subject: Re: [arin-ppml]
> [Remco.vanMook at eu.equinix.com:[address-policy-wg]newpolicy idea for PA allocations]
> 
> 
> Don't get me wrong, I wasn't trying to dismiss the thought, but was playing a little devil's advocate myself. Back in May I offered up some thoughts along a similar line. 
> 
> What you say is true, provided the "best fit" allocation made to organization X provides an adequate window of time for other organizations to get to the remaining reserves. This would leave little or nothing left by the time org X comes back, as you ment
> ion. 
> 
> The problem comes in when you have an org that can justify a /12, and is only given a /17. This scenario is where you would need a time requirement restricting future allocations for some number of months.
> Without a time restriction, there is nothing to prevent that org from submitting applications every other day and depleting what's left before anyone else can get to it. 
> 
> -Dan 
> 
> -----Original Message-----
> From: Howard, W. Lee [mailto:Lee.Howard at stanleyassociates.com]
> Sent: Thursday, August 07, 2008 5:08 PM
> To: Alexander, Daniel; ppml at arin.net
> Subject: RE: [arin-ppml] [Remco.vanMook at eu.equinix.com:
> [address-policy-wg]newpolicy idea for PA allocations]
> 
> 
> > To use the example below, an organization needs a /15, but the only 
> > blocks left are 2 /17s, 1 /18, 5 /19s and 2 /20s. If the idea became 
> > policy, an organization shows it needs a /15 for the next 12 months.
> > ARIN would allocate the /17. That would accommodate the org for an 
> > average of three months. Three months later, all things the same, they
> 
> > would apply again for a /15 for the next 12 months. They would get a 
> > /17, and so the loop continues. 12 months later, they would have a 
> > /15, but through submitting ten applications instead of one.
> 
> I don't know if this potential proposal is a good idea or not, but isn't the point of it that by the time the org uses half of their qualification (three months later), ARIN would be completely out?
> 
> Org qualifies for /15 but gets /17.  During that three months, the other /17, /18, and many of the /19s are assigned to others.
> Org qualifies for a /15 or /16 but gets a /19.  Maybe a month later they can get a /22, but by that point IPv4 is gone.  The goal (I think) would be to distribute the last assignments among more organizations, so that one well-timed mammoth application do
> es deplete the remaining pool, meaning
> Mammoth ISP is the only one who growsv4 that year/ever again.
>  
> Mostly playing devil's advocate.
> 
> Lee

-- 
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539