[arin-ppml] ARIN-prop-167 Removal of Renumbering Requirement for Small Multihomers

Alexander, Daniel Daniel_Alexander at Cable.Comcast.com
Wed May 2 10:48:38 EDT 2012


Kevin, 

I think your last point is very relevant to this proposal. If
organizations can obtain /24's through section 8.3 without any renumbering
requirement, it seems like the goal of aggregation is greatly diminished.
There is a subtle lever applied here, where it forces those who do not
want to renumber through section 4.3.6.2 to the transfer market where they
have to pay for that pass, but it would be interesting to hear if people
think whether that should be the intended behavior.

If aggregation is so important to require renumbering in section 4.3.6.2,
why is it not a big deal in section 8.3 which will shortly become the more
frequently used option?

-Dan Alexander


On 4/30/12 9:13 PM, "Kevin Blumberg" <kevinb at thewire.ca> wrote:

>Jimmy,
>
>At the last ARIN meeting in Vancouver and prior to that in Philadelphia
>staff pointed out that almost no one was coming
>back to ARIN for additional small end user assignment. I believe the
>number quoted was 1 in Philadelphia and 5 in Vancouver
>of which many hundreds of people had taken advantage of getting /23 and
>/24 initial allocations.
>
>While I understand the concern with the routing table, this policy has
>erred too far to one side.
>
>There is also the issue of compatibility with 8.3 transfers. If an end
>user were to go to the market for a /24 would they have
>to return the initial allocation and search for a /23 instead?
>
>Thanks,
>
>Kevin Blumberg
>
>
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Jimmy Hess
>> Sent: Monday, April 30, 2012 7:49 PM
>> To: ARIN
>> Cc: arin-ppml at arin.net
>> Subject: Re: [arin-ppml] ARIN-prop-167 Removal of Renumbering
>> Requirement for Small Multihomers
>> 
>> On 4/30/12, ARIN <info at arin.net> wrote:
>> 
>> I am opposed to the proposal  that  removes the requirement to renumber,
>> without also changing the minimum allocation size for small multi-homers
>> back to /22.
>> 
>> The "freezing" of ARIN additional assignments is not  an unintended
>>effect, it
>> is the express intent of the policy that changed the minimum allocation
>>from
>> /22 to /24; those organizations who obtained a
>> /24 under this policy were aware, or should have been aware of the
>> restriction,  and had  the option of obtaining address space from an
>> upstream provider, if renumbering  out of a /24   within a 1 year
>> period  would be an undue burden for that provider.
>> 
>> The requirement to renumber  should not be removed from existing /24s
>> allocated under this policy;   it is a provision that is relevant to
>> serious concerns about routing table prefix count growth.
>> 
>> 
>> 
>> 
>> > Rationale:
>> >
>> > The policy has had the unintended effect of freezing small multi homed
>> > end users from being able to return to ARIN for additional
>>assignments.
>> > The requirement to renumber out of space is unique and is applying an
>> > undue burden of renumbering what would be an organization's core
>> > infrastructure.
>> 
>> 
>> --
>> -JH
>> _______________________________________________
>> 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.
>_______________________________________________
>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.




More information about the ARIN-PPML mailing list