Send ARIN-PPML mailing list submissions to
[email protected]
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
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of ARIN-PPML digest..."
Today's Topics:
1. Re: Utilization policy is not aggregate (Larry Ash)
2. Re: Utilization policy is not aggregate (Jeffrey Lyon)
3. Re: Utilization policy is not aggregate (Brett Frankenberger)
4. Re: Utilization policy is not aggregate ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Fri, 16 Nov 2012 18:05:48 -0700
From: "Larry Ash" <[email protected]>
To: "Jimmy Hess" <[email protected]>, "Scott Leibrand"
<[email protected]>
Cc: Jeffrey Lyon <[email protected]>, "[email protected]
List" <[email protected]>
Subject: Re: [arin-ppml] Utilization policy is not aggregate
Message-ID: <[email protected]>
Content-Type: text/plain;charset=iso-8859-1; format="flowed"
On Fri, 16 Nov 2012 18:22:53 -0600
Jimmy Hess <[email protected]> wrote:
> On 11/15/12, Scott Leibrand <[email protected]> wrote:
>> Not necessarily opposed, but one reason for the existing language is: if you
>> are at 90% of a /16, and your 3 month need is only for a /20, then you would
>> still be at >80% immediately after getting your /20, without using a bit of
>
> exactly.... and It would not be favorable to have a measure of
> utilization that allowed an organization to fail to efficiently
> utilize each of the allocations they obtain, before requesting
> another.
>
> It's essentially like saying "You used your previous allocation _SO_
> efficiently, that we will give you a bonus, and let you not use the
> next allocation so efficiently, and still obtain more resources."
>
> Instead it should just be "lesson learned" for the applicant; if
> you ever actually exceed 80% utilization, stop allocating from that
> block, start allocating from the new one, and there is no need to
> change policy.
Reaching 80% on a smaller allocation is a lot
harder than a /18. Over time holes develop in the utilization.
You will reuse them but at any given time it's difficult if not
impossible.
How about 80% overall with no single allocation under 70% (whatever).
The 80% policy has always greatly favored the big guys. It's much
easier to reach 80% on a /18 than a /20. Natural holes that occur
always seem to amount to almost 10-25% in a /20 unless much of it
has been delegated as /23's or /24's.
I have turned away customers on a number of occasions over the years
because they needed /24's or larger and I didn't have any open and no
hope of getting more. For several years my utilization was only in the
lower 70's but the largest contiguous blocks were frequently /26's.
We constantly worked at closing the gaps but you can only ask customers
to do so much.
>
> (Except to increase the utilization requirement to a higher value);
> E.g. 80% utilization on the preceding allocation, and 99%
> utilization on allocations that preceded it..
>
>
> The applicant who got the larger allocation and achieved the same
> overall percentage of utilization, had to meet a larger need
> requirement to obtain that allocation. And they also had to
> allocate more number resources after actually obtaining the
> allocation, to be allocated the next one.
>
>> Scott
> --
> -JH
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.
Larry Ash
------------------------------
Message: 2
Date: Fri, 16 Nov 2012 20:40:08 -0500
From: Jeffrey Lyon <[email protected]>
To: Larry Ash <[email protected]>
Cc: "[email protected] List" <[email protected]>
Subject: Re: [arin-ppml] Utilization policy is not aggregate
Message-ID:
<CACrmG8dcZ4ykCFcjarq0nLp3g=wop=ZjKKEEaG8ABmga=4v...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Nov 16, 2012 at 8:05 PM, Larry Ash <[email protected]> wrote:
> On Fri, 16 Nov 2012 18:22:53 -0600
> Jimmy Hess <[email protected]> wrote:
>>
>> On 11/15/12, Scott Leibrand <[email protected]> wrote:
>>>
>>> Not necessarily opposed, but one reason for the existing language is: if
>>> you
>>> are at 90% of a /16, and your 3 month need is only for a /20, then you
>>> would
>>> still be at >80% immediately after getting your /20, without using a bit
>>> of
>>
>>
>> exactly.... and It would not be favorable to have a measure of
>> utilization that allowed an organization to fail to efficiently
>> utilize each of the allocations they obtain, before requesting
>> another.
>>
>> It's essentially like saying "You used your previous allocation _SO_
>> efficiently, that we will give you a bonus, and let you not use the
>> next allocation so efficiently, and still obtain more resources."
>>
>> Instead it should just be "lesson learned" for the applicant; if
>> you ever actually exceed 80% utilization, stop allocating from that
>> block, start allocating from the new one, and there is no need to
>> change policy.
>
>
> Reaching 80% on a smaller allocation is a lot
> harder than a /18. Over time holes develop in the utilization.
> You will reuse them but at any given time it's difficult if not
> impossible.
>
> How about 80% overall with no single allocation under 70% (whatever).
>
> The 80% policy has always greatly favored the big guys. It's much
> easier to reach 80% on a /18 than a /20. Natural holes that occur
> always seem to amount to almost 10-25% in a /20 unless much of it
> has been delegated as /23's or /24's.
>
> I have turned away customers on a number of occasions over the years
> because they needed /24's or larger and I didn't have any open and no
> hope of getting more. For several years my utilization was only in the
> lower 70's but the largest contiguous blocks were frequently /26's.
>
> We constantly worked at closing the gaps but you can only ask customers
> to do so much.
>
>>
>> (Except to increase the utilization requirement to a higher value);
>> E.g. 80% utilization on the preceding allocation, and 99%
>> utilization on allocations that preceded it..
>>
>>
>> The applicant who got the larger allocation and achieved the same
>> overall percentage of utilization, had to meet a larger need
>> requirement to obtain that allocation. And they also had to
>> allocate more number resources after actually obtaining the
>> allocation, to be allocated the next one.
>>
>>> Scott
>>
>> --
>> -JH
>> _______________________________________________
>> PPML
>> You are receiving this message because you are subscribed to
>> the ARIN Public Policy Mailing List ([email protected]).
>> Unsubscribe or manage your mailing list subscription at:
>> http://lists.arin.net/mailman/listinfo/arin-ppml
>> Please contact [email protected] if you experience any issues.
>
>
> Larry Ash
Larry,
Ditto. My largest contiguous is probably a /28 right now, but I still
did not (until yesterday) qualify for more space with ARIN.
--
Jeffrey A. Lyon, CISSP
President, Black Lotus Communications
mobile: (757) 304-0668 | gtalk: [email protected] | skype: blacklotus.net
------------------------------
Message: 3
Date: Sat, 17 Nov 2012 10:15:01 -0600
From: Brett Frankenberger <[email protected]>
To: Jimmy Hess <[email protected]>
Cc: Jeffrey Lyon <[email protected]>, "[email protected]
List" <[email protected]>
Subject: Re: [arin-ppml] Utilization policy is not aggregate
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
On Fri, Nov 16, 2012 at 06:22:53PM -0600, Jimmy Hess wrote:
>
> It's essentially like saying "You used your previous allocation _SO_
> efficiently, that we will give you a bonus, and let you not use the
> next allocation so efficiently, and still obtain more resources."
Or it's like saying "because we value form over function, you can't
have any more addresses now, unless you waste time reassigning some of
your customers from your previous allocation to your next allocation".
> Instead it should just be "lesson learned" for the applicant; if
> you ever actually exceed 80% utilization, stop allocating from that
> block, start allocating from the new one, and there is no need to
> change policy.
So you believe that we should encode in policy a preference for making
assignments from newer allocations over older allocations, and reward
providers who do that?
An applicant who has used 95% of his first /16 and 75% of his second
/16 has more efficiently utilized his space than an applicate who has
used 81% of his first /16 and 81% of his second /16. Yet we are
willing to give more addresses to the second, less efficient,
application, but we will not give more addresses to the first
applicant.
Moreover, the first applicant *can* get more space without any
increase in utilization, simply by renumbering customers equivalent to
5% of a /16 from the his first /16 to his second /16. Should policy
really be motivating/rewarding this sort of behavior?
A counterargument is the repetitive assignment possibility. Someone who
is at 95% of a /16 justifies and receives a /20. Without any
utilization of it whatsoever, they are at 89% and can essentially
submit the same paperwork and get another /20 the next day. However:
(a) even under current policy, they can do that, as long as they move
80% of a /20 of customers from their original /16 to their new
/20, and (b) in the situation I describe, the real cause of the
potential for repetitive assignment is the applicant's voluntary delay of
their request: they could have requested when they got to 80% of their
first /16, and then their /20 would have placed them below 80% in
aggregate.
The goal is efficient utilization of a limited resource. But current
policy treats entites who are equally situated in terms of existing
space, utilization of existing space, and projected need going forward,
differently, based on *which* of their existing addresses they have
used.
If the government started taxing purchases paid for with a $20 bill
differently from purchases paid for with two $10 bills, we'd all think
that's silly. But we are treating providers who made allocations from
their older assignment differently from providers who make those same
allocations from their newer assignments.
-- Brett
------------------------------
Message: 4
Date: Sat, 17 Nov 2012 16:25:57 +0000
From: [email protected]
To: "Milton L Mueller" <[email protected]>, [email protected],
"'Ron Grant'" <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [arin-ppml] Utilization policy is not aggregate
Message-ID:
<864088986-1353169540-cardhu_decombobulator_blackberry.rim.net-524803274-@b15.c9.bise6.blackberry>
Content-Type: text/plain; charset="Windows-1252"
I concur with you Milton.
Sent from my BlackBerry? device from Digicel
-----Original Message-----
From: Milton L Mueller <[email protected]>
Sender: [email protected]
Date: Fri, 16 Nov 2012 14:17:48
To: 'Ron Grant'<[email protected]>; [email protected]<[email protected]>
Subject: Re: [arin-ppml] Utilization policy is not aggregate
I agree with this framing of the problem and as a new AC member will be willing
to work on getting a new, well-thought-out policy through.
--MM
> -----Original Message-----
>
> We're very near exhaustion so any new policy should be framed with the
> transfer market in mind.
>
> If somebody's willing to sell, and somebody else is willing to buy, but
> they can't justify it because of a math problem - well, I'd be in favour
> of changing it.
>
> So the example is really this:
>
> "if you are at 90% of a /16, and all that's available for purchase is a
> /20, is it really a problem if after purchase you'd be able to buy more?"
>
issues.
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.
------------------------------
_______________________________________________
ARIN-PPML mailing list
[email protected]
http://lists.arin.net/mailman/listinfo/arin-ppml
End of ARIN-PPML Digest, Vol 89, Issue 10
*****************************************
