Proposal for review

[vipar at verio.net]

On Tue, 24 Jul 2001, Lee Howard wrote:

> 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.

FYI - I know there was discussion about Verio as one of those ISPs. 
Verio's routing policy has since been changed some what. see

http://info.us.bb.verio.net/routing.html#PeerFilter

"BGP peer filter policy

The following is Verio's filtering policy with its peers. It is based on
the allocation boundaries of the regional Internet registries (RIRs). 

inbound: 

 In the traditional Class A space (i.e., 0/1), we accept /20 and shorter. 
 In the traditional Class B space (i.e., 128/2), we accept /20 and shorter. 
 In the traditional Class C space (i.e., 192/3), we accept /24 and shorter. 

outbound: 

 All our announcements are registered in one of the routing registries. see 
  as-set AS-VERIO. 
 We do not announce prefixes longer than /24. 

We reserve the right to modify this policy without prior notice."

> 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.
>
and i tend to agree with you here Lee.  the same holds true in RIPE, if
you want seperate allocations, you open seperate LIR's and pay the fee for
each.  it seems the best way to deal with this issue to me.

thanks,
lyric 

------------------------------
lyric apted							
ip engineering manager, vipar

verio, inc.
------------------------------

> 
> 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
> > 
> 





---------------------------
lyric apted							
ip engineering manager, vipar
vipar at verio.net							

verio, inc.
---------------------------