Proposal for review

[Lee Howard]

On Wed, 25 Jul 2001, Andrew Dul wrote:

> Date: Wed, 25 Jul 2001 08:27:18 -0700 (PDT)
> From: Andrew Dul <andrew at internap.com>
> To: Cathy Wittbrodt <cjw at remarque.org>
> Cc: Lee Howard <lhoward at UU.NET>, ppml at arin.net
> Subject: Re: Proposal for review 
> 
> Hello All,
> 
> On Tue, 24 Jul 2001, Cathy Wittbrodt wrote:
> 
> >
> > I think you have summed it up quite well.  The issue here is
> > that the folks who wrote the proposal (not me) feel that having
> > separate maintainer IDs, although a somewhat workable solution,
> > is not acceptable.
> 
> There are two reason why I believe that separate maintainer IDs are not
> really workable.  1) Administrative: Multiple maintainers would greatly
> increase ARIN and our administrative load due to the increase in number of
> address requests that would need to be processed.  

I'm not worried about ARIN's administrative load.  Fees are currently
sufficient to cover their costs, and it looks like they can scale. 

 

> 2) Cost:  Why should
> some organizations pay multiples for the same amount of address space?
> $40,000 for 16 /20s vs. $10,000 for 1 /16.

Because, as you point out, it's more work to allocate 16 /20s than a single
/16.  The currently policy and setup (pricing, maintainers, etc.) is set up
so that you pay roughly in accordance with how much work you generate.  To
me, this seems only fair:  fees should be based on services provided (hours
worked) not on number of IPs allocated.  Otherwise you end up figuring 
$0.63 per IP.


> >     From: Lee Howard <lhoward at UU.NET>
> >     Subject: Re: Proposal for review
> >     I was drafting a long response, because it's a long proposal.  Then I got
> >     distracted by work.
> >
> >     Here's my perspective:  On general principle,
> >
> >     	ARIN should consider routing when making allocations.
> >
> >     However, a lot of your proposal seems to affect any organization with
> >     multiple regions or maintainers.  I don't think it needs to--let's just
> >     address the ones that have problems.
> >
> >     There are three problems:
> >     1.  Organizations which have separate routing domains, which combined
> >     justify an initial allocation from ARIN, but separately do not.
> >     2.  Two or three ISPs will not accept routes more specific than ARIN
> >     allocates.
> >     3.  Organizations with separate routing domains may not be able to show
> >     80% usage overall, even if several routing domains are full.
> >
> >     I don't think the first is a problem:  each routing domain gets address
> >     space from its upstream until it can justify its own allocation.  Each
> >     area gets its own maintainer ID, the fee for which is based on its size.
> 
> This is workable alternative for smaller organizations, but under the
> current fee schedule there still is a cost issue.  This also wouldn't
> apply to some since in most cases they would be able to justify an initial
> /20 from ARIN for each routing domain and we are back to where we are now.

If you can justify a /20, then you have no problem, except cost.  You can
still go to an upstream for address space, if cost is that big a problem.


> >     The second is a problem, but it isn't ARIN's problem.
> 
> I totally agree this isn't ARIN's problem, but as long as some ISPs choose
> to limit their route-table size by using a RIRs allocation policy as a
> filter we will have to deal with the issue.  What good is an allocation
> that isn't routable?  Perhaps time is better spent on making
> proxy-aggregation workable to help alleviate route-table growth.

That's one solution worth exploring.

 
 
> >     The third is a problem with which I am familiar.  There are several
> >     alternatives, within current ARIN policy:
> >     - get multiple maintainer accounts,
> >     - allocate small enough blocks to each routing domain that by the time
> >     the first area is out of space, the total usage is 80%.  This option
> >     doesn't work if you have discrete networks and no backbone, and isn't
> >     worthwhile if you don't have an extra-large allocation.  I still argue that
> >     having separate maintainers is a better idea, for a variety of reasons.
> 
> While this would work with networks with a backbone, I fear it may cause
> more additional routes to be injected into the table.

You're right, getting a /16 and assigning /24s one by one to various 
non-interactive networks will result in noncontiguous, therefore 
unaggregated /24s.  I did say it wouldn't work if you have discrete 
networks and no backbone.

What is a network without a backbone?
By definition, if there's no connection between sites, it isn't a network.  
I don't see how aggregation of "nodes" or "hubs" or whatever you choose to 
call them can be accomplished unless there is a common routing point.  For a 
traditional backbone provider, this may be the core of the network, or the 
edge.  But if an organization has 30 discrete networks, and if we agree that 
each network's utilization must be separately evaluated, then the organization
should have to pay ARIN for the additional work generated.  ARIN has a 
system that allows for separate evaluation and billing of separate networks.


Lee


> 
> Andrew
>