Proposal for review

Lee Howard lhoward at UU.NET
Wed Jul 25 09:29:17 EDT 2001


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 as
>     >     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 being
>     >     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 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 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) to
>     >     an existing network, unless previous growth rates for that network indicate
>     >     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 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 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 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 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