Proposal for review
Cathy Wittbrodt
cjw at remarque.org
Wed Jul 25 11:38:29 EDT 2001
Yup. It is a challenge and we'd welcome your input.
Thanks Lee!
---CJ
From: Lee Howard <lhoward at UU.NET>
Subject: Re: Proposal for review
I've been trying to write a policy on how to consider routing. My
trouble is that I think routing table bloat is a more dire problem at
the moment than address depletion. Therefore, it should be considered.
However, it's entirely likely that in a year or two, the size of
routing tables will no longer be a significant problem, and the balance
of the two issues will swing back. Crafting a policy that can manage
changing priorities is challenging.
Lee
On Tue, 24 Jul 2001, Cathy Wittbrodt wrote:
> Date: Tue, 24 Jul 2001 16:57:18 -0700
> From: Cathy Wittbrodt <cjw at remarque.org>
> To: Lee Howard <lhoward at UU.NET>
> Cc: ppml at arin.net
> Subject: Re: Proposal for review
>
>
> 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 their
> > networks in this manner for a number of reasons including regulatory
> > restrictions (Federal FCC mandated inter-lata restrictions), geographic
> > diversity/distance between networks, and routing policy.
> >
> > Current RIR allocation policy requires that before a single organization
> > 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 networks a
>>s
> > though they were separate organizations. This practice creates both
> > practical and financial concerns for ARIN. In practice it appears that
> > organizations can just 'buy' additional address space without regard to
> > utilization on other networks and this in turn increases ARIN's revenue
> > dependence on a small number of organizations.
> >
> > Current allocation requirements can become unreasonable when operating a
> > set
> > of discrete networks for organizations which intend on following the
> > current
> > allocations policy. Discrete networks must often have separate unique
> > globally routable address space and will often grow at different rates.
> > 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 grant
> > additional address space to the organization, due to the 80% utilization
> > 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 utilization
> > grows considerably faster than Network B. Network A is currently showing
> > 90% utilization and needs additional address space for new customers bein
>>g
> > added to this network. Network B's address space is being utilized but
> > currently only shows 40% utilization. This would produce an allocation
> > 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 discrete
> > networks.
> > Examples: 1) regulatory restrictions for data transmission
> > 2) geographic distance and diversity between networks
> > 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, and
> > 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 then us
>>e
> > 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 allocated,
> > any reserved blocks, and date of allocation. The allocation information
> > 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 utilization
> > greater than 80% individually and as a whole.
> >
> > * 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.
> >
> > * The organization must not allocate an additional CIDR block larger than
> > the current minimum assignment size of the RIR (currently /20 for ARIN) t
>>o
> > an existing network, unless previous growth rates for that network indica
>>te
> > that it is likely to utilize a larger CIDR block before the time the
> > organization will be requesting an additional block from the RIR. The
> > suggested minimum allocation size for an additional block for a network i
>>s
> > 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 reduce
> > the number of routes the organization will announce from that autonomous
> > system. Example: A fast growing network is allocated a /20 out of a
> > reserved /19, when the /20 is 80% utilized the announcement is expanded t
>>o
> > 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 must
> > show greater than 50% utilization for the last block granted by the RIR
> > and their allocations as a whole.
> >
> > * The organization must follow guidelines of RFC 2050 (or its replacement
>>)
> > 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 the
> > RIR.
> >
> >
> > ------- End of Forwarded Message
> >
>
>
More information about the ARIN-PPML
mailing list