From memsvcs at arin.net  Mon Jul  2 11:25:35 2001
From: memsvcs at arin.net (Member Services)
Date: Mon, 2 Jul 2001 11:25:35 -0400 (EDT)
Subject: Virtual WebHosting Policy - Final Call for Comment
Message-ID: <Pine.SOL.4.05.10107021106120.2874-100000@ops.arin.net>


The ARIN Advisory Council recommended a Virtual WebHosting Policy to the
Board of Trustees during its June 12, 2001 teleconference meeting. As the
wording differs slightly from the April 16 version which was posted on the
website and sent to the Public Policy mailing list for last call for
comments, the following language will be posted for 10 working days in
order for the community to make final comment:

"When an ISP submits a request for IP address space to be used for
IP-based web hosting, they will supply (for informational purposes only)
their technical justification for this practice.  ARIN will analyze this
data continuously, evaluating the need for future policy change."

Please send your comments to the ppml at arin.net mailing list.  This last
call will expire on 23:59 EDT, July 16, 2001.

Ray Plzak
President




From memsvcs at arin.net  Fri Jul 20 15:30:17 2001
From: memsvcs at arin.net (Member Services)
Date: Fri, 20 Jul 2001 15:30:17 -0400 (EDT)
Subject: Last Call for Comment: IPv6 Allocation Policy
Message-ID: <200107201930.PAA26735@ops.arin.net>

On July 19, 2001, the ARIN Advisory Council voted to forward to 
the ARIN Board of Trustees the following policy:

"ARIN will allocate IPv6 addresses according to the Internet Draft
http://www.arin.net/library/draft-iesg-ipv6-addressing-recommendations-02.txt.
This policy will be regularly reviewed and modified subject to operational 
experience."

This a last call for community comment on this policy prior to the 
ARIN Board of Trustees review of the proposed policy.  This policy 
will be posted on the ARIN website and the ARIN Public Policy email 
list.  Please send your comments to ppml at arin.net.  This last call 
will expire on 23:59 EDT, August 3, 2001.

Ray Plzak
President
American Registry for Internet Numbers (ARIN)


From cjw at remarque.org  Mon Jul 23 16:13:55 2001
From: cjw at remarque.org (CJW)
Date: Mon, 23 Jul 2001 13:13:55 -0700
Subject: Proposal for review
Message-ID: <200107232013.NAA23262@pox.remarque.org>


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



From huberman at gblx.net  Mon Jul 23 16:52:42 2001
From: huberman at gblx.net (David R Huberman)
Date: Mon, 23 Jul 2001 13:52:42 -0700 (MST)
Subject: Proposal for review
In-Reply-To: <200107232013.NAA23262@pox.remarque.org>
Message-ID: <Pine.GSO.4.21.0107231338470.10117-100000@shell1.phx.gblx.net>


To preface my critical remarks below, let me say that I am totally for a
policy, generally speaking, which allows organizations to better aggregate
their ARIN allocations.
 
>     Criteria for the application of this policy:
 
>     * 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

We discussed this the last time this proposal hit ppml. I still contend,
and Andrew Dul seemed to somewhat agree, that it is not ARIN's place nor
business to be judging the worthiness of an organization's business plan.

It puts an undue burden on ARIN by forcing them to make value judgements.
It unnecessarily restricts ARIN from administering address space to 
otherwise-qualified applicants. There may even be legal issues. 

Please, can we remove this?

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

I again object to this strongly. 

Organizations which currently have multiple maintainer IDs and pay
registration fees for multiple accounts do so for more reasons than just
pure aggregation concerns. 

I think this is a great overall policy shift by the membership, but I
don't think any resulting policy should require previous arrangements
between ARIN and its individual members to be altered. At least, not in
this case.

 
>     Requirements for additional allocations from RIR:
 
>     * 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.

Either this isn't phrased well, I'm not understanding it at this moment in
time, or it says something I disagree with.

Organizations should only request additional address space from ARIN when
it can no longer assign a globally-routable (ick - sorry) address block to
one of its discrete networks or it meets the traditional 80% requirement.

If an org. has a /20 or more available, and is less than 80% utilized on
its previous blocks, it should not be eligible for additional address
space yet.
 
/david



From cjw at remarque.org  Tue Jul 24 15:57:28 2001
From: cjw at remarque.org (cjw at remarque.org)
Date: Tue, 24 Jul 2001 12:57:28 -0700
Subject: Proposal for review 
In-Reply-To: Message from "Scott Richard Slater" <scottslater77@hotmail.com> 
   of "Tue, 24 Jul 2001 15:43:23 EDT." <DAV26G5aYY61LEdyt3c00002f3d@hotmail.com> 
Message-ID: <200107241957.MAA06324@pox.remarque.org>


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


From huberman at gblx.net  Tue Jul 24 16:06:44 2001
From: huberman at gblx.net (David R Huberman)
Date: Tue, 24 Jul 2001 13:06:44 -0700 (MST)
Subject: Proposal for review
In-Reply-To: <20010724124238.D4402@x17.ripe.net>
Message-ID: <Pine.GSO.4.21.0107240749520.26275-100000@shell1.phx.gblx.net>

In my e-mail yesterday I wrote:

> > >     * 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.
> > 
> > Either this isn't phrased well, I'm not understanding it at this
> > moment in time, or it says something I disagree with.
> > 
> > Organizations should only request additional address space from ARIN
> > when it can no longer assign a globally-routable (ick - sorry) address
> > block to one of its discrete networks or it meets the traditional 80%
> > requirement.
> > 
> > If an org. has a /20 or more available, and is less than 80% utilized
> > on its previous blocks, it should not be eligible for additional
> > address space yet.

It's been pointed out to me that the last paragraph above basically
shows that I *dont* agree with the policy.

As I prefaced my comment, I didn't understand what this point was getting
at. After having time to think about it, it makes more sense to me now.

I retract my objection to the above criteria. The math works out fine.

/david



From lhoward at UU.NET  Tue Jul 24 16:43:04 2001
From: lhoward at UU.NET (Lee Howard)
Date: Tue, 24 Jul 2001 16:43:04 -0400 (EDT)
Subject: Proposal for review
In-Reply-To: <200107232013.NAA23262@pox.remarque.org>
Message-ID: <Pine.GSO.4.20.0107241600430.18046-100000@sun222-31.corp.us.uu.net>

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
> 



From cjw at remarque.org  Tue Jul 24 19:57:18 2001
From: cjw at remarque.org (Cathy Wittbrodt)
Date: Tue, 24 Jul 2001 16:57:18 -0700
Subject: Proposal for review 
In-Reply-To: Message from Lee Howard <lhoward@UU.NET> 
   of "Tue, 24 Jul 2001 16:43:04 EDT." <Pine.GSO.4.20.0107241600430.18046-100000@sun222-31.corp.us.uu.net> 
Message-ID: <200107242357.QAA07713@pox.remarque.org>


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
    > 
    


From cjw at remarque.org  Tue Jul 24 20:03:33 2001
From: cjw at remarque.org (CJW)
Date: Tue, 24 Jul 2001 17:03:33 -0700
Subject: Proposal for review
Message-ID: <200107250003.RAA07805@pox.remarque.org>

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
    > 
    




From lhoward at UU.NET  Wed Jul 25 09:29:17 2001
From: lhoward at UU.NET (Lee Howard)
Date: Wed, 25 Jul 2001 09:29:17 -0400 (EDT)
Subject: Proposal for review 
In-Reply-To: <200107242357.QAA07713@pox.remarque.org>
Message-ID: <Pine.GSO.4.20.0107250925260.2634-100000@sun222-31.corp.us.uu.net>

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



From andrew at internap.com  Wed Jul 25 11:27:18 2001
From: andrew at internap.com (Andrew Dul)
Date: Wed, 25 Jul 2001 08:27:18 -0700 (PDT)
Subject: Proposal for review 
In-Reply-To: <200107242357.QAA07713@pox.remarque.org>
Message-ID: <Pine.LNX.4.33.0107250739420.1081-100000@andrew.internap.com>

Hello All,

On Tue, 24 Jul 2001, Cathy Wittbrodt wrote:

>
> 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
> separate maintainer IDs, although a somewhat workable solution,
> is not acceptable.

There are two reason why I believe that separate maintainer IDs are not
really workable.  1) Administrative: Multiple maintainers would greatly
increase ARIN and our administrative load due to the increase in number of
address requests that would need to be processed.  2) Cost:  Why should
some organizations pay multiples for the same amount of address space?
$40,000 for 16 /20s vs. $10,000 for 1 /16.


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

This is workable alternative for smaller organizations, but under the
current fee schedule there still is a cost issue.  This also wouldn't
apply to some since in most cases they would be able to justify an initial
/20 from ARIN for each routing domain and we are back to where we are now.

>
>     The second is a problem, but it isn't ARIN's problem.
>

I totally agree this isn't ARIN's problem, but as long as some ISPs choose
to limit their route-table size by using a RIRs allocation policy as a
filter we will have to deal with the issue.  What good is an allocation
that isn't routable?  Perhaps time is better spent on making
proxy-aggregation workable to help alleviate route-table growth.


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

While this would work with networks with a backbone, I fear it may cause
more additional routes to be injected into the table.

Andrew



From cjw at remarque.org  Wed Jul 25 11:38:29 2001
From: cjw at remarque.org (Cathy Wittbrodt)
Date: Wed, 25 Jul 2001 08:38:29 -0700
Subject: Proposal for review 
In-Reply-To: Message from Lee Howard <lhoward@UU.NET> 
   of "Wed, 25 Jul 2001 09:29:17 EDT." <Pine.GSO.4.20.0107250925260.2634-100000@sun222-31.corp.us.uu.net> 
Message-ID: <200107251538.IAA20346@pox.remarque.org>


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


From lhoward at UU.NET  Wed Jul 25 16:02:29 2001
From: lhoward at UU.NET (Lee Howard)
Date: Wed, 25 Jul 2001 16:02:29 -0400 (EDT)
Subject: Proposal for review 
In-Reply-To: <Pine.LNX.4.33.0107250739420.1081-100000@andrew.internap.com>
Message-ID: <Pine.GSO.4.20.0107251526060.2873-100000@sun222-31.corp.us.uu.net>

On Wed, 25 Jul 2001, Andrew Dul wrote:

> Date: Wed, 25 Jul 2001 08:27:18 -0700 (PDT)
> From: Andrew Dul <andrew at internap.com>
> To: Cathy Wittbrodt <cjw at remarque.org>
> Cc: Lee Howard <lhoward at UU.NET>, ppml at arin.net
> Subject: Re: Proposal for review 
> 
> Hello All,
> 
> On Tue, 24 Jul 2001, Cathy Wittbrodt wrote:
> 
> >
> > 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
> > separate maintainer IDs, although a somewhat workable solution,
> > is not acceptable.
> 
> There are two reason why I believe that separate maintainer IDs are not
> really workable.  1) Administrative: Multiple maintainers would greatly
> increase ARIN and our administrative load due to the increase in number of
> address requests that would need to be processed.  

I'm not worried about ARIN's administrative load.  Fees are currently
sufficient to cover their costs, and it looks like they can scale. 

 

> 2) Cost:  Why should
> some organizations pay multiples for the same amount of address space?
> $40,000 for 16 /20s vs. $10,000 for 1 /16.

Because, as you point out, it's more work to allocate 16 /20s than a single
/16.  The currently policy and setup (pricing, maintainers, etc.) is set up
so that you pay roughly in accordance with how much work you generate.  To
me, this seems only fair:  fees should be based on services provided (hours
worked) not on number of IPs allocated.  Otherwise you end up figuring 
$0.63 per IP.


> >     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.
> 
> This is workable alternative for smaller organizations, but under the
> current fee schedule there still is a cost issue.  This also wouldn't
> apply to some since in most cases they would be able to justify an initial
> /20 from ARIN for each routing domain and we are back to where we are now.

If you can justify a /20, then you have no problem, except cost.  You can
still go to an upstream for address space, if cost is that big a problem.


> >     The second is a problem, but it isn't ARIN's problem.
> 
> I totally agree this isn't ARIN's problem, but as long as some ISPs choose
> to limit their route-table size by using a RIRs allocation policy as a
> filter we will have to deal with the issue.  What good is an allocation
> that isn't routable?  Perhaps time is better spent on making
> proxy-aggregation workable to help alleviate route-table growth.

That's one solution worth exploring.

 
 
> >     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.
> 
> While this would work with networks with a backbone, I fear it may cause
> more additional routes to be injected into the table.

You're right, getting a /16 and assigning /24s one by one to various 
non-interactive networks will result in noncontiguous, therefore 
unaggregated /24s.  I did say it wouldn't work if you have discrete 
networks and no backbone.

What is a network without a backbone?
By definition, if there's no connection between sites, it isn't a network.  
I don't see how aggregation of "nodes" or "hubs" or whatever you choose to 
call them can be accomplished unless there is a common routing point.  For a 
traditional backbone provider, this may be the core of the network, or the 
edge.  But if an organization has 30 discrete networks, and if we agree that 
each network's utilization must be separately evaluated, then the organization
should have to pay ARIN for the additional work generated.  ARIN has a 
system that allows for separate evaluation and billing of separate networks.


Lee


> 
> Andrew
> 



From vipar at verio.net  Wed Jul 25 20:38:47 2001
From: vipar at verio.net (vipar at verio.net)
Date: Thu, 26 Jul 2001 00:38:47 +0000 (GMT)
Subject: Proposal for review
In-Reply-To: <Pine.SOL.4.21.0107251522300.22500-100000@eng0.dfw.verio.net>
Message-ID: <Pine.SOL.4.21.0107260034320.24917-100000@eng0.dfw.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.
---------------------------



From memsvcs at arin.net  Tue Jul 31 10:25:55 2001
From: memsvcs at arin.net (Member Services)
Date: Tue, 31 Jul 2001 10:25:55 -0400 (EDT)
Subject: ARIN's New Virtual Web Hosting Policy
Message-ID: <Pine.SOL.4.05.10107310958200.7290-100000@ops.arin.net>


At its July 27, 2001 meeting, the ARIN Board of Trustees ratified the
following policy statement:

"When an ISP submits a request for IP address space to be used for
IP-based web hosting, they will supply (for informational purposes only)
their technical justification for this practice.  ARIN will analyze this
data continuously, evaluating the need for future policy change."

The Board of Trustees rescinded its previous suspension of the virtual web
hosting policy and replaces that policy with the one stated above.


Ray Plzak
President
ARIN





From martind at UU.NET  Tue Jul 31 10:59:27 2001
From: martind at UU.NET ( dawn martin)
Date: Tue, 31 Jul 2001 10:59:27 -0400
Subject: Question - ARIN's New Virtual Web Hosting Policy
Message-ID: <001901c119d1$657e9ba0$0a0a0a0a@lteng122>

Should we (ARIN's ISP members) be requesting this information
from our customers as well?

-Dawn Martin


>At its July 27, 2001 meeting, the ARIN Board of Trustees >ratified the
>following policy statement:
>
>"When an ISP submits a request for IP address space to >be used for
>IP-based web hosting, they will supply (for >informational purposes only)
>their technical justification for this practice.  ARIN >will analyze this
>data continuously, evaluating the need for future policy >change."
>
>The Board of Trustees rescinded its previous suspension >of the virtual web
>hosting policy and replaces that policy with the one >stated above.
>
>
>Ray Plzak
>President
>ARIN



From memsvcs at arin.net  Tue Jul 31 12:03:08 2001
From: memsvcs at arin.net (Member Services)
Date: Tue, 31 Jul 2001 12:03:08 -0400 (EDT)
Subject: ARIN VIII Meeting Registration Now Open
Message-ID: <Pine.SOL.4.05.10107310858570.7290-100000@ops.arin.net>


ARIN will hold its next Public Policy and Members Meeting in Miami, FL
beginning October 28 through October 31, 2001.

Meeting registration is now available at:

http://www.arin.net/meetings/ARIN_VIII/index.html

Please note the link explaining our new sponsorship format.
There are opportunities available at many levels!

Agendas and tutorial information will be added 
from time to time so please check back for the latest updates.

A special note : this meeting provides an opportunity for you to meet
candidates running for open seats on the ARIN Board of Trustees and ARIN
Advisory Council.  In addition, the election to fill one seat on the ASO
Advisory Council from the ARIN region will take place on Monday, October
29.

Questions concerning the meeting or registration for it may be 
directed to memsvcs at arin.net or Stevi Hubbard at 703-227-9878.

We look forward to seeing you in Miami.

Susan Hamlin
Director, Member Services








From richardj at arin.net  Tue Jul 31 13:23:10 2001
From: richardj at arin.net (Richard Jimmerson)
Date: Tue, 31 Jul 2001 13:23:10 -0400
Subject: Question - ARIN's New Virtual Web Hosting Policy
In-Reply-To: <001901c119d1$657e9ba0$0a0a0a0a@lteng122>
Message-ID: <000001c119e5$79968f80$e8fc95c0@arin.net>

This policy applies to requests that are submitted to ARIN
for review.  ARIN's ISP members are not required to collect
this information from their customers.  If an ISP elects to
collect this information, however, it would be helpful in
future discussions about web hosting policies.

Richard Jimmerson
Director of Operations
American Registry for Internet Numbers (ARIN)

> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net]On 
> Behalf Of dawn
> martin
> Sent: Tuesday, July 31, 2001 10:59 AM
> To: ppml at arin.net
> Subject: Question - ARIN's New Virtual Web Hosting Policy
> 
> 
> Should we (ARIN's ISP members) be requesting this information
> from our customers as well?
> 
> -Dawn Martin
> 
> 
> >At its July 27, 2001 meeting, the ARIN Board of Trustees 
> >ratified the
> >following policy statement:
> >
> >"When an ISP submits a request for IP address space to >be used for
> >IP-based web hosting, they will supply (for >informational 
> purposes only)
> >their technical justification for this practice.  ARIN >will 
> analyze this
> >data continuously, evaluating the need for future policy >change."
> >
> >The Board of Trustees rescinded its previous suspension >of 
> the virtual web
> >hosting policy and replaces that policy with the one >stated above.
> >
> >
> >Ray Plzak
> >President
> >ARIN