[arin-ppml] Initial ISP Allocation Policy
Steven Ryerse
SRyerse at eclipse-networks.com
Mon Jul 22 15:47:18 EDT 2013
I'm contrasting this: " The utilization requirements on an initial end-user assignment changes from 25% immediate, 50% within one year to 80% within three months" with this "The timeframe for additional ISP allocations is changed from three months back to one year". Since I'm just looking at your bullet points I might be missing something. As I said overall I support what you are trying to accomplish.
Steven L Ryerse
President
100 Ashford Center North, Suite 110, Atlanta, GA 30338
770.656.1460 - Cell
770.399.9099 - Office
770.392-0076 - Fax
℠ Eclipse Networks, Inc.
Conquering Complex Networks℠
-----Original Message-----
From: Alexander, Daniel [mailto:Daniel_Alexander at Cable.Comcast.com]
Sent: Monday, July 22, 2013 3:42 PM
To: Steven Ryerse
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Initial ISP Allocation Policy
Hello Steven,
Can you help me understand where you interpret that someone would not be able to get another block for a year? My wording may be off.
The text, "an initial block would be 80% utilized within three months", applies to someone asking for an initial registration from ARIN. It is assumed that they should be able to qualify for what they are justifying through existing assignments from an upstream and would renumber into the new block. It was an attempt to retain the concept of slow start without drawing it out in language or an explicit section.
If the network operator uses this block in 3 months, or 30 days, there should be nothing preventing them from qualifying for an additional block given they meet the 80% utilization. There should be no language in the proposal restricting an operator from obtaining an approval ONLY ONCE within a year.
Sincerely,
Dan Alexander
Speaking only for myself.
On 7/22/13 2:16 PM, "Steven Ryerse" <SRyerse at eclipse-networks.com> wrote:
>I mostly would support. Maybe I don't quite understand your logic but
>it seems that changing utilization to be 80% after 3 months works at
>cross purposes of waiting a year for an additional allocation as that
>rate would use up the block in around 4 months with 8 months or so left
>in the year before eligible for another allocation. I could live with
>reducing the minimum sizes but I'm guessing some won't like the effect
>on the routing table to do that. I do think these changes would be
>positive a whole.
>
>Steven L Ryerse
>President
>100 Ashford Center North, Suite 110, Atlanta, GA 30338
>770.656.1460 - Cell
>770.399.9099 - Office
>770.392-0076 - Fax
>
>℠ 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 Alexander, Daniel
>Sent: Sunday, July 21, 2013 11:33 PM
>To: arin-ppml at arin.net
>Subject: Re: [arin-ppml] Initial ISP Allocation Policy
>
>Hello All,
>
>I have submitted proposal text to facilitate this discussion. I am sure
>there will be many comments and changes, but wanted to provide a
>starting point. This proposal is an attempt to simplify one part of the
>NRPM in a way that is easily understood even though it intentionally
>leaves other parts unresolved. This was done to keep the scope to
>something that could realistically be discussed.
>
>There is also a red-lined version of section four attached to this
>email that illustrates the proposed changes. The document strikes
>through the text suggested to be removed, and the suggested additions
>are in bold and italicized. Everything in a standard font is pre-existing text.
>
>Here is a summary of the suggested requirements that would change:
>
>* Minimum allocation for a single-homed ISP is reduced from a /20 to /22.
>* Minimum allocation for a multi-homed ISP is reduced from a /22 to a /24.
>* The distinction between subscriber members who are before or after a
>one year anniversary is removed.
>* Minimum assignments for a single-homed end user is reduced from a /20
>to a /22.
>* The requirement that multi-homed, end-user assignments smaller than a
>/20 be made from a block reserved for that purpose is removed.
>* The utilization requirements on an initial end-user assignment
>changes from 25% immediate, 50% within one year to 80% within three
>months. This is offset by the lowering of the minimum block size
>requirement for single-homed networks.
>* The timeframe for additional ISP allocations is changed from three
>months back to one year.
>* The special section for the Caribbean region is integrated into the
>same requirements as the rest of the region with the existing /22 and
>the addition of an option for a multi-homed /24.
>
>Sincerely,
>
>Dan Alexander
>Speaking only for myself.
>
>On 7/18/13 12:16 PM, "Matthew Wilder" <Matthew.Wilder at telus.com> wrote:
>
>>Hi David,
>>
>>I think this is a great way of looking at. NRPM could be so much
>>simpler, but in a multi-stakeholder world, we all see the tendency for
>>policy changes to complicate, not simplify NRPM. The only way to
>>simplify NRPM to a reasonable (sane) state is to start with a blank
>>sheet of paper, as you say. Our current NRPM is just shy of 15,000
>>words. The sections which really need to be updated to accomplish
>>your stated objective are section 4 and section 6, which combined
>>contain
>>8,356 words. In my mind a sane NRPM would have half that many words.
>>
>>If you constrain the efforts simply to merging any policy which
>>distinguishes between End Users and ISPs, you will have around 4,000
>>words in scope. I imagine the majority of challenge faced in this
>>activity will be merging section 4.2 with 4.3, with several topics
>>sure to create quite the discussion (3 month allocations for ISPs vs
>>12 months for End Users, Registration for downstream customers to name two).
>>
>>The way I could imagine finding some success in the overarching
>>ambitions is to define what sections of NRPM we are interested in
>>transforming, and by contrast those which we believe should stand. I
>>believe that the majority of content outside section 4 and section 6
>>is reasonable enough.
>> I also believe that your intent is primarily to simplify the NRPM as
>>it relates to allocation of IPv4 and IPv6 resources, so likely the
>>energy should naturally focus on those 2 sections.
>>
>>If the community is in support of re-writing those sections of NRPM,
>>the two following topics should be considered for discussion (and
>>possibly more I have not identified):
>>
>>1. Will three month allocations apply also to End-Users as it does to
>>ISPs? This is going to be the biggest bone of contention as I see it,
>>and the big reason why many would still see value in a distinction
>>between ISP and End-User, despite lines blurring as many have observed.
>>I work for an ISP, and I see the similarities of hotels, coffee shops,
>>CDNs, cloud providers and so on. To what set or subset of Orgs should
>>the three month allocation apply? Merging End-Users and ISPs in
>>policy will be challenging here.
>>
>>2. What reassignments need to be registered for the global community's
>>benefit in a paradigm which no longer distinguishes between ISP and
>>End-User? I would suggest that static assignments of a certain size
>>to entities outside the Organization specified as the resource holder
>>should be registered. This mean Starbucks and the Hyatt don't have to
>>register their DHCP pools used by their customers (although maybe a
>>record of that DHCP would be desirable). In any case, this needs to
>>be thought through at a higher level and then specifications laid out.
>>
>>I am certainly interested in seeing what other have to say. It may be
>>very difficult to parse what can be reasonably removed from
>>expectations of ISPs in order to align with End-Users, and conversely
>>how happy End-Users will be to share the 3-month allocation policy
>>with ISPs. If the majority of value is seen by many in simple
>>alignment of initial allocation and assignment (and to some degree
>>subsequent allocation / assignment), I believe the policy changes will
>>be much easier to manage and build consensus around.
>>
>>Cheers,
>>Matthew Wilder
>>
>>
>>-----Original Message-----
>>From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net]
>>On Behalf Of David Huberman
>>Sent: July 18, 2013 01:36 AM
>>To: arin-ppml at arin.net
>>Subject: Re: [arin-ppml] Initial ISP Allocation Policy
>>
>>Hello everyone,
>>
>>I would like to thank everyone for a very good discussion in this thread.
>>First I'll give a very brief summary of the discussion so far, and
>>then I have a solution to float to the list for feedback.
>>
>>Myself, Dan, Bill, and Steven have posted in favor of the high level
>>concept that the differentiation in ARIN policy between enterprise
>>networks and provider networks is no longer productive or relevant.
>>Owen may agree in principle, but cautions us to be very careful with
>>how we proceed. He is concerned that an effective "one size fits all"
>>solution may be very difficult to design. George offers us an
>>alternative nomenclature to consider (NSP v. ISP).
>>
>>I would like to now shift the discussion to how we approach
>>potentially collapsing the two categories into one so that future
>>interactions with ARIN are conducted under policy language which is
>>relevant in 2014 and beyond.
>>
>>I agree with Dan that a wholesale paradigm shift in ARIN policy can
>>only be accomplished with multiple proposals. There would be quite a
>>few sections to change (with each change requiring careful
>>consideration by the community). Moreover, I think we must be
>>sensitive to ARIN's need to react to the possible impacts to both the
>>financial and workflow modeling that would result from any changes we
>>propose.
>>
>>At the same time, incremental change in NRPM is actually really hard.
>>If this were 5 years ago, I would probably work very hard to help
>>effect incremental change. But I think ARIN and the community have
>>together failed to react to changes in the market over the last 15
>>years, and it is time to consider very big change. Let's get NRPM into
>>a sane state for
>>2014 and beyond.
>>
>>In an effort to roll up sleeves and be productive, please indulge me
>>while I lay out one potential vision for what a sane NRPM might look
>>like. I warn you, good reader, that some of what I propose is very
>>radical.
>>
>>- A section on obtaining initial IPv4 addresses from ARIN. No
>>distinction between end-users and ISPs. No distinction between
>>single-homed and multi-homed deployments (*if you don't understand why
>>the difference has no virtue, ping me on or off list and I will show
>>you the math as I see it). Text might look something like:
>>
>> "In order to receive an initial allocation from ARIN, an organization
>>must:
>>
>> - demonstrate they operate an IP network that requires
>> IPv4 addresses to deploy and/or grow; and
>>
>> - provide a numbering plan detailing how IPv4 addresses
>> will be used in the first 180 days upon receiving an allocation.
>>
>> ARIN will review and verify the data provided, and provide for the
>>organization's 6 month need."
>>
>>- A section on obtaining additional blocks, which still outlines the
>>80% rule. ("If you've efficiently used what you have, you can have
>>more" is a technically sound concept that does not need much fixing.)
>>Platform differences which are already fleshed out in NRPM (e.g.,
>>residential market area provider networks with their different metrics
>>than more common buildouts) can and should remain.
>>
>>- We would have to figure out what to do with the requirement to SWIP,
>>as the requirement is predicated on the classification of "ISP"
>>actually existing (which it would not). That might need a working
>>group to reconcile.
>>
>>- A section on obtaining initial IPv6 addresses from ARIN. Given that
>>IPv6 is still very much in its infancy, I really would like to see
>>very simple NRPM text which allows requestors to self-select what size
>>block they need. The only barrier to abuse or silliness would be the fee
>>schedule. It is arrogant and technically indefensible that ARIN policy
>>today tries to dictate what a network does, and does not, justify as
>>far as block size. IPv6 is much too immature for ARIN policy to
>>presume such wisdom.
>>
>>- A section on obtaining additional IPv6 addresses from ARIN.
>>Existing text in 6.5.3 is probably good enough for today, as there are
>>only a handful of networks in the world with any experience needing
>>additional
>>IPv6 addresses due to efficient use of an initial block. Obtaining
>>additional IPv6 addresses is a topic for many years from now, not today.
>>
>>Do you think any of this has value? Would it accomplish the
>>overarching goal of improving ARIN policy to make it relevant to
>>network operators in
>>2014 and beyond? What would your sane NRPM look like?
>>
>>With regards,
>>David
>>
>>
>>_______________________________________________
>>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