Proposal for review
cjw at remarque.org
cjw at remarque.org
Tue Jul 24 15:57:28 EDT 2001
Scott,
The proposal is from an ISP who has multiple non connected POPs.
Right now that organization gets an allocation for each of the POPs
independently. This costs them more money, etc. It is difficult
for those providers to have the utilization that they need across
the multiple POPs to have one allocation. They cannot borrow from
one POP to address another because of how they have to route. This
is pretty well spelled out in the beginning of the document.
The issue is that if such an organization is allowed to get a /19
(let's say for example) for each POP and incrementally a /19 for
each new allocation per POP, they could very well have a virtually
unused /19 in one POP while the other is full and still be able to
get more space. Other registries who have tried to have all these
entities under one allocation have had this problem allocating more
space. This document is one ISP's proposal for how it might be solved.
I hope this helps. Note also that it would be good to send your
replies to the list and not just to me
Thanks!
---CJ
From: "Scott Richard Slater" <scottslater77 at hotmail.com>
Subject: Re: Proposal for review
I would like to think that our first acknowledgement and concern is that
IPv4 address space is limited and that users(organizations) are responsible
for preserving address space and making absolutely sure that their space is
utilized to MAXIMUM efficienciency.
I then ask, "Does every user create completely efficient networks?" Does
every user know that hardware behind firewalls does not require distinctive
IPv4 addresses? The conservation of IPv4 address space is critical and the
use of network address translation should be encouraged.
In regards to "Single organizations with large multi-homed discrete
networks" I first assume that these organizations are using BGP or planning
to use BGP. Now, if these single organizations are complaining that ...
"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 ." It is stated below
that the proposal has been written by folks at Internap. I am assuming that
the "Single organizations with large multi-homed discrete networks" are
customers/clients of Internap. I always thought that Internap was a
'transit' based service provider. I am not absolutely certain. Although,
organizations that are connected to the Internet through service providers
that don't belong to the elite peering group of large backbones will become
secondary with substandard access to the Internet.
So, is the proposal an IPv4 allocation question from a service provider OR
an IPv4 routing question from an single organization connected to the
Internet through a service provider ?
----- Original Message -----
From: "CJW" <cjw at remarque.org>
To: <ppml at arin.net>
Sent: Monday, July 23, 2001 4:13 PM
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