Re: [sig-policy] prop-029-v001: Proposal for Discrete Networks and Natio
Per policy:
4. This proposal does not conflict with current APNIC policy:
If I understand your statement correctly, My idea is for APNIC to
assign the allocations for the discrete Networks as is currently done with
each country account. Discrete networks can be placed in categories:
- Per country
- Per Service Networks
We are aware of the prop-013-v001.html presented at APNIC17 which was
withdrawn, this is a different policy and a more explicit one.
The fundamental goal as stated is to have one account per organization
while managing allocations by APNIC through disrcrete networks; which can
be
defined as Country-discrete or Service-discrete to mentiona few.
Therefore the HD ratios and alocations policies will be applied to the
discrete network level while the billing will only apply at the
organizational level.
I see no conflicts only a realignment of policies to include the discrete
networks.
Uchenna N Ibekwe
Manager
MCI Inc. (Latin America, Asia-Pacific, Backhauls and Business Partners)
Hours: 9:00AM Eastern US - 6:00PM Eastern US (Mon. & Fri.)
3:00PM Eastern US - 11:00PM Eastern US (Tues.- Thurs.)
US & Latin America +1-703-886-2650, v806-2650
Group Alias: isd_ip at lists dot mci dot com
Group Phone: 703-886-7840 US, 612-94345537 Australia, 852-2236-8985 Hong Kong,
81-3-53653740 Japan, 65-6248-6928 Singapore, 82-2-6281-7950 S.Korea,
886-2-2794-7769 Taiwan.
uchenna.ibekwe at mci dot com
> On Thu, 25 Aug 2005, Anne Lord wrote:
>
> > Hi Uchenna,
> >
> > Many thanks for your proposal. I have just a couple of questions to
> > assist me in my understanding.
> >
> > At APNIC17 a similar proposal to this one was presented by Norman Hoy of
> > MCI on behalf of Dawn Martin:
> > (http://www.apnic.net/docs/policy/proposals/prop-013-v001.html).
> >
> > The minutes from that meeting document a recommendation to look at the
> > HD ratio proposal as a possible solution to the problems that were
> > raised. Although this is not in your proposal, I would be interested to
> > know if you looked at this at all?
> >
> > For more details see:
> > http://www.apnic.net/docs/policy/proposals/prop-020-v001.html
> >
> > One clarification w.r.t item 4:
> >
> > >>4. This proposal does not conflict with current APNIC policy;
> >
> > This is not in fact quite right. Current policy does not support the
> > allocation of large blocks of address space in the way that you
> > describe. The policies under the suspended 'confederation' membership
> > did operate in this way in the past, but today they are very different
> > and in fact are now in line with the way the rest of the membership
> > receives its resources. The parent company does not get a super-block to
> > 'manage' and sub-allocate. Each 'discrete' network is handled directly
> > by APNIC hostmasters in terms of the their resource requests and
> > assignment window requests.
> >
> > I hope this clarifies things for you (and please dont hesitate to ask if
> > not!)
> >
> > Best wishes,
> > Anne
> > --
> >
> > >
> > >Here is the proposal for review and comments.
> > >
> > >----------------------------------------------------------------------------
> > >
> > >Proposal to permit large ISPs to manage multiple country accounts under a
> > >single APNIC membership using discrete network concept.
> > >----------------------------------------------------------------------------
> > >
> > >
> > >Summary
> > >----------------------------------------------------------------------------
> > >
> > >This Proposal is intended to simplify the management of multiple country
> > >accounts hereby each country account would be considered a discrete
> > >network.
> > >
> > >This proposal will support Global/Continental-Regional/National peering
> > >policies and would be vital for the implementation of the IPv6 routing
> > >policies.
> > >
> > >Benefits
> > >----------------------------------------------------------------------------
> > >
> > >
> > >1. Simplify management of multiple country accounts;
> > >
> > > Currently large ISPs such as MCI with multiple APNIC accounts (one
> > >per country) using the concept of discrete network can simplify their
> > >procedures by combining their membership accounts under a single account, while
> > >managing each country IP allocation as separate discrete networks.
> > >
> > >2. Simplify Billing;
> > >
> > > This concept will simplify the billing requirement for APNIC, hereby
> > >reducing the number of member accounts per ISP and unify the billing
> > >cycles.
> > >
> > >3. Peering;
> > > Most large ISPs with International networks spanning multiple
> > >continent and regions have peering policies implemented on their network.
> > >Currently, MCI has 3 levels of peering, namely global-peering,
> > >continental-regional peering and National peering. In order to make
> > >national peering work in IPv6, we will need to advertise a single aggregate
> > >per country. This will typically a /32, each country /32 should be able to
> > >be aggregate into a single aggregate so that a single announcement could be
> > >made to customers and continental-regional peers.
> > >
> > > In some countries, it is required by law that we peer with other ISPs
> > >or interconnect at NAP (Network Access Point). In this case, the issue of
> > >peering is required and this can only be done using aggregated IPv6
> > >addresses which will be based on the level of peering (It can be
> > >Global/Continental-regional/National peering).
> > >
> > >4. This proposal does not conflict with current APNIC policy; only seeks to
> > >simplify current APNIC operational requirements, frameworks for management
> > >and allocation of IPv6/IPv4 addresses. This policy will be vital to
> > >integration of implantation of IPv6 into an Asia Pacific region.
> > >
> > >Case Study
> > >----------------------------------------------------------------------------
> > >
> > >Some organizations have requirements for multiple discrete networks that
> > >need individual address allocations. Discrete networks must often have
> > >separate unique globally routable address space and will often grow at
> > >different rates. In order for organizations with multiple discrete networks
> > >to request additional address space under a single maintainer ID, the
> > >organization must use the following criteria:
> > >
> > >* The organization should be a single entity, and not a consortium of
> > >smaller independent entities.
> > >
> > >* 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 compelling criteria for creating discrete
> > >networks. Examples:
> > >
> > >o regulatory restrictions for data transmission
> > >
> > >o geographic distance and diversity between networks
> > >
> > > o autonomous multi-homed discrete networks
> > >
> > > * The organization must apply for this policy to be applied to their
> > > account.
> > >
> > > Other APNIC IP allocation policies for IPv6/IPv4 would apply to this
> > > proposal.
> > >
> > > Proposal
> > > ----------------------------------------------------------------------------
> > >
> > >
> > > 4.1 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.
> > >
> > > 4.2 The organization must not issue additional IP address space to a
> > > discrete network unless all the blocks sub-allocated to that
> > > network show utilization greater than 80% individually and as a
> > > whole.
> > >
> > > 4.3 The organization must not sub-allocate a CIDR block larger than
> > > the current minimum allocation size of the RIR (currently
> > > /21-IPv4, /32-IPv6 for APNIC region) to a new network.
> > >
> > > 4.4 The organization must not sub-allocate an additional CIDR block
> > > larger than the current minimum allocation size of the RIR
> > > (currently /21-IPv4, /32-IPv6 for APNIC 's region) 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.
> > >
> > > 4.5 When sub-allocating a block larger than the minimum allocation
> > > size to an existing network the ISPs should use the smallest
> > > allocation possible out of a larger reserved block. This
> > > requirement is to reduce the number of routes the ISPs will
> > > announce from that autonomous system.
> > >
> > > 4.6 The ISPs must follow guidelines of RFC 2050 (or its replacement)
> > > and the policy of the granting RIR for allocations that are
> > > assigned or sub-allocated to downstream networks. This includes
> > > record keeping of IP address requests and network utilization
> > > documents for audits by the RIR.
> > >
> > > 4.7 ISPs with 'multiple membership accounts' should request that this
> > > policy apply to them, their existing allocations be merged, and that
> > > additional allocations will fall under this policy.
> > >
> > > 4.8 The ISPs must record sub-allocations or assignments down to the
> > > current RIR bit boundary and record them in an approved RIR public
> > > database.
> > >
> > > 4.9 The ISPs must keep detailed records of how it has sub-allocated
> > > space to each discrete network. This should include the block
> > > sub-allocated, any reserved blocks, and date of allocation/
> > > reservation. The discrete network allocation information should
> > > also be present in a public database.
> > >
> > > 4.10 An assignment window will be assigned to the ISPs and will need to
> > > be followed for their entire network. Second opinion requests will
> > > need to be sent to APNIC for review. This is to include blocks of
> > > addresses that are assigned to new or existing pools within the ISPs
> > > network.
> > >
> > >
> > > Fees
> > > ----------------------------------------------------------------------------
> > >
> > >
> > > The IP addresses from all combined resources would be taken into account
> > > when assessing the membership tier for the organization upon the renewal of
> > > their membership.
> > >
> > >
> > > References
> > > ----------------------------------------------------------------------------
> > >
> > >
> > > http://www.arin.net/policy/index.html#four5
> > >
> > > http://www.arin.net/policy/proposals/2004_5.html
> > >
> > > Policy Proposal 2004-5: Address Space for Multiple Discrete Networks
> > >
> > > http://www.arin.net/policy/proposals/2001_6.html
> > >
> > > Policy 2001-6: Multiple Discrete Networks - Single Maintainer ID
> > >
> > >
> > > Uchenna N Ibekwe
> > > MCI Inc.
> > > Phone +1-703-886-2650
> > > uchenna.ibekwe at mci dot com
> > >
> > > "All I have seen teaches me to trust the Creator for all I have not seen."
> > > Ralph Waldo Emerson
> > >
> > > "Confidence comes not from always being right, but from not fearing to be
> > > wrong." --Peter T. McIntyre
> > >
> > >
> > > * sig-policy: APNIC SIG on resource management
> > > policy *
> > > _______________________________________________
> > > sig-policy mailing list
> > > sig-policy at lists dot apnic dot net
> > > http://mailman.apnic.net/mailman/listinfo/sig-policy
> >
>
>