hi,
Stephen seems just wants to solve UUNET problem with proposing MIR. However I am agree basically with the Idea. APNIC has added NIR ( National Internet Registry ) to the hierarchy. I think RIPE must let the NIRs as well.
Just a note about this. The membership category of NIR actually does not relate in any way to the specific problem that Stephen is trying to address which is that of large multinational organisations routed under one AS, having discontiguous IP address allocations through the establishment of many LIRs. In fact, the NIR model actually does nothing for aggregation - as NIRs receive a block which they further allocate to their members who run businesses within a particular country. The members in those countries served by NIRs are more likely to receive discontiguous blocks (simply because the NIRs have a smaller pool), thus not contributing to aggregation of routing information at all. We are working with the NIRs to solve this with a referral process for allocations directly from APNIC for the very large members of NIRs. Of course, having access to a local language service is very much on the plus side of having NIRs. For the record though, the NIRs exist under the confederation membership category. This also includes ISP confederations as well as NIRs. The two are *very* different entities, so the confederation category has been suspended until we work out a better solution. While I agree totally with Stephens objective and understand the motivation, the proposal needs detail. How would it work exactly? APNIC's ISP confederation model which tried to address the same thing, did not work, and gave unfair advantages to the ISP confederations. (Part of the reason the 'confederation' category has been suspended). It is definately a laudable challenge to try to produce a model and procedures such that the policies are fairly applied to all. regards Anne _____________________________________________________________________ Anne Lord, Manager, Policy Liaison <anne@apnic.net> Asia Pacific Network Information Centre phone: +61 7 3367 0490 http://www.apnic.net fax: +61 7 3367 0482 _____________________________________________________________________
----- Original Message ----- From: "Stephen Burley" <stephenb@uk.uu.net> To: <crain@icann.org>; <lir-wg@ripe.net> Sent: 06/09/2001 7:40 �.� Subject: Re: MIR proposal
----- Original Message ----- From: "John L Crain" <crain@icann.org> To: <lir-wg@ripe.net> Sent: Thursday, September 06, 2001 4:03 PM Subject: Re: MIR proposal
<CUT>
Hi Gert,
And yes, this is also very much needed for IPv6. Getting a /35 and having to hand out individual /48's to customers of customers of ours isn't going to build proper hierarchical routing.
The concepts for IPv6 that are under discussion do already cover this. An allocation goes to a large ISP who can then assign /48's directly to networks connecting to them or shorter prefixes to
I'm not sure if this works in IPv4 because of the limited amount of room
we
have to play with.
We are only limited because of teh current thinking and structure.
I'm also not sure what the criteria would be in the proposal that
defines
who is and isn't allowed to become a MIR. It's certainly a differnet concept to the present one in the RIPE region where LIR's don't "officially" sub- allocate.
Its not so different from the RIR model.
I can certainly see why a large ISP would want to do this. I'm not sure how it changes the dynamics for smaller ISP's as to how they would get their IP addresses. Becoming an LIR with an upstream rather than a regional registry I assume means renumbering if you change the upstream.
MIR's are only to be created within a network (AS if you like) they would not suballocate to customers only LIR's withing their network (usualy country specific). Other LIR's not needing a MIR would deal direct with
resellers/downstreams. the
NCC. UUNET has 17 LIR's currently the MIR would suballocate to these not to other ISP's or customers direct. BTW Nice to hear from you.
John Crain
* Mailing List: hostmaster-staff * * Handled by majordomo@staff.apnic.net *