Proposal for review
CJW
cjw at remarque.org
Tue Jul 24 20:03:33 EDT 2001
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
seperate maintainer IDs, although a somewhat workable solution,
is not acceptable. There was quite a bit of discussion about
this at the last meeting such that this proposal was written.
Thanks for your feedback Lee! I'd be interested in your input on
how ARIN, in practice, should consider routing when making allocations.
Thanks!
---CJ
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.
The second is a problem, but it isn't ARIN's problem.
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.
If I'm misstating the problem or missing some part of it, please try to
explain it to me again.
Lee Howard
On Mon, 23 Jul 2001, CJW wrote:
> Date: Mon, 23 Jul 2001 13:13:55 -0700
> From: CJW <cjw at remarque.org>
> To: ppml at arin.net
> Subject: Proposal for review
>
>
> I sent this a while back and have gotten no comments. Please send me
> your comments on this. This topic generated quite a bit of discussion
> at the last policy meeting and I can't believe that no one on this list
> has an opinion or comment
>
> Thanks bunches!
> ---CJ
>
>
> - ------- Forwarded Message
>
> Date: Wed, 04 Jul 2001 13:00:22 -0700
> From: "CJW" <cjw at groovy.com>
> To: ppml at arin.net
> Subject: Proposal for discussion
>
> This was written by some folks at Internap. The address council has
> been discussing it and your input is an integral part of the process.
> Please review and send your comments to the list.
>
> Thanks so much!
> ---CJ
>
> --------------------------------------------------------------------
>
>
> Proposed Allocation Policy for:
> Single organizations with large multi-homed discrete networks
>
> ARIN currently has an allocation policy that is 'blind' to route
> filtering
> and global routablity, yet in order for address space to be usable it
> must be accepted and routed by the community at large.
>
> This fact can create allocation concerns for organizations that have
> multiple discrete multi-homed networks. Organizations may design the
ir
> networks in this manner for a number of reasons including regulatory
> restrictions (Federal FCC mandated inter-lata restrictions), geograph
ic
> diversity/distance between networks, and routing policy.
>
> Current RIR allocation policy requires that before a single organizat
ion
> can obtain additional address space it must show 80% utilization
> (through
> SWIP or rWhois) per RFC 2050.
>
> Currently, some organizations have circumvented this requirement by
> creating
> "multiple maintainers" with ARIN and request address space for networ
ks as
> though they were separate organizations. This practice creates both
> practical and financial concerns for ARIN. In practice it appears th
at
> organizations can just 'buy' additional address space without regard
to
> utilization on other networks and this in turn increases ARIN's reven
ue
> dependence on a small number of organizations.
>
> Current allocation requirements can become unreasonable when operatin
g a
> set
> of discrete networks for organizations which intend on following the
> current
> allocations policy. Discrete networks must often have separate uniqu
e
> globally routable address space and will often grow at different rate
s.
> This growth differential can lead to a situation where one discrete
> network
> is completely allocated but another network has not yet been fully
> utilized.
> Under the current allocation policy the organization would need to
> request
> additional address space from the RIR; however, given a strict
> interpretation of the existing policy, the RIR may not be able to gra
nt
> additional address space to the organization, due to the 80% utilizat
ion
> requirement.
>
> This constraint can easily be seen when you consider an organization
with
> two geographically discrete autonomous networks. The organization
> initially requested a /19 from the RIR for its two networks with the
> intent to route a single /20 from each network. Network A's utilizat
ion
> grows considerably faster than Network B. Network A is currently sho
wing
> 90% utilization and needs additional address space for new customers
being
> added to this network. Network B's address space is being utilized b
ut
> currently only shows 40% utilization. This would produce an allocati
on
> utilization percentage of 65% which is below the requirement for
> additional address space by a RIR.
>
> We propose for organizations which meet the following criteria to be
> granted the opportunity to request additional address space under the
> requirements listed below.
>
> Criteria for the application of this policy:
>
> * The organization should be a single entity, and not a consortium of
> smaller independent entities. (Example: Not a group of independent
> network operators who form a group specifically for this policy)
>
> * This policy applies only to organizations that have been previously
> granted address space by an RIR. This policy does not apply to
> organizations with only legacy address space.
>
> * The organization must have multiple (at least two) discrete
> multi-homed networks.
>
> * The organization must have a compelling criteria for creating discr
ete
> networks.
> Examples: 1) regulatory restrictions for data transmission
> 2) geographic distance and diversity between networ
ks
> 3) autonomous multi-homed discrete networks
>
> * The organization must apply for this policy to be applied to their
> account.
>
> * Organizations with 'multiple maintainers' should request that this
> policy apply to their accounts, their existing allocations merged, an
d
> additional allocations will fall under this policy.
>
> * Upon adoption the use of 'multiple maintainers' for a single
> organization should not be permitted. These organizations should the
n use
> this policy to govern additional allocations.
>
> Requirements for additional allocations from RIR:
>
> * The organization must record allocations or assignments down to the
/29
> level for all downstream networks via rWhois, SWIP, or approved RIR
> public database.
>
> * The organization must keep detailed records of how it has allocated
> space to each discrete network. This should include the block alloca
ted,
> any reserved blocks, and date of allocation. The allocation informat
ion
> should also be present in a public database via a routing registry,
> rWhois, or via SWIP.
>
> * The organization must not allocate additional space to a discrete
> network unless all the blocks allocated to that network show utilizat
ion
> greater than 80% individually and as a whole.
>
> * The organization must not allocate a CIDR block larger than the cur
rent
> minimum assignment size of the RIR (currently /20 for ARIN) to a new
> network.
>
> * The organization must not allocate an additional CIDR block larger
than
> the current minimum assignment size of the RIR (currently /20 for ARI
N) to
> an existing network, unless previous growth rates for that network in
dicate
> that it is likely to utilize a larger CIDR block before the time the
> organization will be requesting an additional block from the RIR. Th
e
> suggested minimum allocation size for an additional block for a netwo
rk is
> the current minimum assignment size of the RIR.
>
> * When allocating a block larger than the minimum assignment size to
an
> existing network the organization should use the smallest allocation
> possible out of a larger reserved block. This requirement is to redu
ce
> the number of routes the organization will announce from that autonom
ous
> system. Example: A fast growing network is allocated a /20 out of a
> reserved /19, when the /20 is 80% utilized the announcement is expand
ed to
> a /19 and the /20 announcement is removed. This practice also allows
the
> reserved /20 to be used by another discrete network should the 'fast
> growing network' not use the address space as anticipated.
>
> * When applying for additional address space, from an RIR, for new
> networks or additional space for existing networks the organization m
ust
> show greater than 50% utilization for the last block granted by the R
IR
> and their allocations as a whole.
>
> * The organization must follow guidelines of RFC 2050 (or its replace
ment)
> and the policy of the granting RIR for allocations that are assigned
or
> allocated to downstream networks. This includes record keeping of
> allocation requests and network utilization documents for audits by t
he
> RIR.
>
>
> ------- End of Forwarded Message
>
More information about the ARIN-PPML
mailing list