[arin-ppml] Recommended Draft Policy ARIN-2013-8: SubsequentAllocations for New Multiple Discrete Networks - Revised

Steven Ryerse SRyerse at eclipse-networks.com
Wed Mar 5 14:20:26 EST 2014


Jeffrey's comment below is an example of real life that frequently is ignored in existing ARIN policies, as signing contracts with Internet providers and even construction of data centers or smaller spaces take lots of money - and it is difficult to be absolutely certain that an allocation from ARIN will be available after the money is spent and contracts are signed.  If you are a big org would you spend a billion dollars on a data center only to have ARIN refuse to allocate any resources because the brand new data center doesn't have any business yet?  The equivalent goes for a smaller org.  Real life says that orgs should be able to count on securing right sized allocations of resources if ARIN has them to allocate.  

I believe this is an unreasonable situation to force new organizations to go thru solely because they are asking for an allocation in 2014 instead of 1994, or 1997, or 2005 or whatever date in the past.  Other than making sure that ARIN can pay its bills and that they can reasonably administrate allocation requests, why should new applicants be discriminated against because of the date they request allocations.  Is it because the haves don't want the have nots to set up shop and compete with them?  Might there be other unreasonable reasons as well?  As I've said many many times before, every organization should at least be able to get a minimum size (/22 or /24 or whatever) no matter what - as long as ARIN has resources to allocate.  

There are thousands of organizations that have received allocations over the years including Legacy holders.   For the most part they weren't subject to these kind of needs policies and can pretty much reasonably use their allocation as they wish,  but some think that only new requests for allocations should be forced to comply with the many arbitrary policies that are now on the books, even though some of the existing allocation holders may not have had to comply with these policies when they got their allocations.  Fair is fair and I strongly believe that we as a community need to be just as fair to new requests as older request.  I would paraphrase that by saying do unto others what you would have done to you - is a good guide to follow.  

Given the definition of Ethernet routing, certainly multiple locations should be enough to justify a right sized allocation.  Thus, I am against the change in policy as it makes it harder to get an allocation rather than easier.  Instead, we ought to fix the underlying policy(s) to make it easier to get an allocation and not harder.  -1

Steven Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA  30338
770.656.1460 - Cell
770.399.9099- Office

℠ Eclipse Networks, Inc.
                     Conquering Complex Networks℠


-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Martin Hannigan
Sent: Wednesday, March 05, 2014 9:00 AM
To: Jeffrey Lyon
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2013-8: SubsequentAllocations for New Multiple Discrete Networks - Revised

Do explain. So a network operator should enter into a bandwidth contract anticipating that it might get addresses from ARIN and if it doesnt or doesn't get an adequate amount to fully utilize their capacity they should eat that cost or loss so that it's "good for ARIN"?

Not sure how that's good for anyone.


Best,

-M<


On Wed, Mar 5, 2014 at 8:45 AM, Jeffrey Lyon <jeffrey.lyon at blacklotus.net> wrote:
> Cathy,
>
> I actually find it reasonable that the live connectivity be the 
> prerequisite for requesting space under 4.5.
>
> Thanks, Jeff
>
> On Wed, Mar 5, 2014 at 10:42 PM, CJ Aronson <cja at daydream.com> wrote:
>> Jeffrey,
>>
>> The text was changed from "Upon verification that the organization 
>> has already obtained connectivity at its new discrete network site"  
>> because folks felt that this meant the connection had to be up and running, not just
>> under contract.   I believe there is more justification required than just
>> "having a new site".   I see nothing in the current policy that states an
>> automatic /24.  Here is the policy text as it stands today from NRPM 
>> (see
>> below)
>>
>> Thanks!
>> ----Cathy
>>
>> 4.5. Multiple Discrete Networks
>>
>> Organizations with multiple discrete networks desiring to request new 
>> or additional address space under a single Organization ID must meet 
>> the following criteria:
>>
>> The organization shall be a single entity and not a consortium of 
>> smaller independent entities.
>> The organization must have compelling criteria for creating discrete 
>> networks. Examples of a discrete network might include:
>>
>> Regulatory restrictions for data transmission, Geographic distance 
>> and diversity between networks, Autonomous multihomed discrete 
>> networks.
>>
>> The organization must keep detailed records on how it has allocated 
>> space to each location, including the date of each allocation.
>> When applying for additional internet address registrations from 
>> ARIN, the organization must demonstrate utilization greater than 50% 
>> of both the last block allocated and the aggregate sum of all blocks 
>> allocated from ARIN to that organization. If an organization is 
>> unable to satisfy this 50% minimum utilization criteria, the 
>> organization may alternatively qualify for additional internet 
>> address registrations by having all unallocated blocks of addresses smaller than ARIN's current minimum allocation size.
>> The organization may not allocate additional address space to a 
>> location until each of that location's address blocks are 80% utilized.
>> The organization should notify ARIN at the time of the request their 
>> desire to apply this policy to their account.
>>
>>
>>
>> On Wed, Mar 5, 2014 at 1:12 PM, Jeffrey Lyon 
>> <jeffrey.lyon at blacklotus.net>
>> wrote:
>>>
>>> I am opposed to the rewording as the new discrete site is in itself 
>>> demonstration of need. There is a technical requirement to provide 
>>> at least a /24 of space at any discrete site.
>>>
>>> Thanks, Jeff
>>>
>>> On Wed, Mar 5, 2014 at 6:16 PM, CJ Aronson <cja at daydream.com> wrote:
>>> > Does anyone else have comments about this proposal?  The text has 
>>> > been changed slightly based on feedback from the PPC at NANOG.  
>>> > The change was
>>> >
>>> > from
>>> >
>>> > Upon verification that the organization has already obtained 
>>> > connectivity at its new discrete network site
>>> >
>>> > to
>>> >
>>> >
>>> > Upon verification that the organization has demonstrated need at 
>>> > its new discrete network site
>>> >
>>> > Please send your comments on this change and on the proposal.
>>> >
>>> > Thanks!
>>> > -----Cathy
>>> >
>>> >
>>> > On Wed, Mar 5, 2014 at 2:18 AM, Andrew Dul <andrew.dul at quark.net> wrote:
>>> >>
>>> >> I support this new version of the policy.  I believe the new text 
>>> >> successfully deals with the issues raised and discussed at the 
>>> >> Atlanta nanog PPC.
>>> >>
>>> >> Andrew
>>> >>
>>> >> On 3/4/2014 12:13 PM, ARIN wrote:
>>> >> > ## * ##
>>> >> >
>>> >> >
>>> >> > Recommended Draft Policy ARIN-2013-8 Subsequent Allocations for 
>>> >> > New Multiple Discrete Networks
>>> >> >
>>> >> > Date: 4 March 2014
>>> >> >
>>> >> > AC's assessment of conformance with the Principles of Internet 
>>> >> > Number Resource Policy:
>>> >> >
>>> >> > "Subsequent Allocations for Additional Discrete Network Sites 
>>> >> > This policy enables fair and impartial number resource 
>>> >> > administration by documenting the current practice regarding 
>>> >> > allocations for additional discrete network sites. The ARIN 
>>> >> > staff has been following a procedure that has not been 
>>> >> > documented until now. By documenting this process the community 
>>> >> > has clear understanding of how to get address space for additional network sites.
>>> >> >
>>> >> > This is a technically sound proposal that has been in practice 
>>> >> > for some time. It had just not been documented.
>>> >> >
>>> >> > This proposal has received several notes of support on the PPML 
>>> >> > and to date has received no negative feedback."
>>> >> >
>>> >> > Policy Statement:
>>> >> >
>>> >> > IPv4:
>>> >> >
>>> >> > Add the following statement to section 4.5.4.
>>> >> >
>>> >> > Upon verification that the organization has demonstrated need 
>>> >> > at its new discrete network site, the new networks shall be 
>>> >> > allocated the minimum allocation size under section 4.2.1.5 
>>> >> > unless the organization can demonstrate additional need using 
>>> >> > the immediate need criteria (4.2.1.6).
>>> >> >
>>> >> > IPv6:
>>> >> >
>>> >> > Add an additional reference to section 6.11.5.b such that it 
>>> >> > references both the initial allocation and subsequent 
>>> >> > allocation sections of the IPv6 LIR policy.
>>> >> >
>>> >> > "Each network will be judged against the existing utilization 
>>> >> > criteria specified in 6.5.2 and 6.5.3 as if it were a separate 
>>> >> > organization..."
>>> >> >
>>> >> >
>>> >> >
>>> >> > Comments:
>>> >> >
>>> >> > a. Timetable for implementation: immediate
>>> >> >
>>> >> > b. This policy is being proposed based upon the Policy 
>>> >> > Implementation & Experience Report from ARIN 32.
>>> >> >
>>> >> >
>>> >> >
>>> >> > https://www.arin.net/participate/meetings/reports/ARIN_32/PDF/t
>>> >> > hursday/nobile-policy.pdf
>>> >> >
>>> >> >
>>> >> > c: Older versions of the MDN policy did contain new network criteria.
>>> >> > This criteria appears to have been dropped during subsequent 
>>> >> > rewrites of the MDN policy. "The organization must not allocate 
>>> >> > a CIDR block larger than the current minimum assignment size of 
>>> >> > the RIR (currently
>>> >> > /20 for ARIN) to a new network."
>>> >> > (https://www.arin.net/policy/archive/nrpm_20041015.pdf)
>>> >> > _______________________________________________
>>> >> > 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.
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > 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.
>>>
>>>
>>>
>>> --
>>> Jeffrey A. Lyon, CISSP-ISSMP
>>> Fellow, Black Lotus Communications
>>> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype:
>>> blacklotus.net
>>
>>
>
>
>
> --
> Jeffrey A. Lyon, CISSP-ISSMP
> Fellow, Black Lotus Communications
> mobile: (757) 304-0668 | gtalk: jeffrey.lyon at gmail.com | skype: 
> blacklotus.net _______________________________________________
> 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