About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: [lir-wg] RE: [ipv6-wg@localhost] Discussion about RIPE-261

  • To: "Michel Py" < >
    < >
  • From: Hank Nussbacher < >
  • Date: Mon, 26 May 2003 08:01:43 +0200

At 01:59 PM 25-05-03 -0700, Michel Py wrote:

Can you explain "%G Pop."? How is it calculated? I assume it has to do with GDP but please explain the calculation as well as the source of the numbers (the exact UN stats page would help).

Needless to say, your numbers do not seem to take in any socio-economic factors. Assigning a /12 to North America as well as to Northern Africa and India might make socialistic sense as well as being "politically correct", but from a reality standpoint, it just don't fly.

-Hank



Below is an example interpolated from the work we have done on
geographic assignments:
http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt

Quick notes:
- We are presently talking about PA space; the document mentioned above
refers to PI space. However the geographic cutoff collapsed to the
country level would not change.

- I chose to assign a /8 to the entire world, which can be discussed.
This means that after we colonize 255 other planets we have a problem
:-) can someone help me with that warp drive please?

- What could also be discussed are the details of how this was
generated, but I would like to get the _concept_ across then we can talk
about the details.

Zone              Population  %G Pop.  IANA
----------------  ----------  -------  --------------
China             1284971000   20.91%  2346:0000::/11
Continental Asia   673454413   10.96%  2346:2000::/11
India             1025096000   16.68%  2346:4000::/12
Northern Africa    565854163    9.21%  2346:5000::/12
Asian Islands      488468000    7.95%  2346:6000::/12
Western Europe     423412058    6.89%  2346:7000::/12
North America      318243350    5.18%  2346:8000::/12
South America      350724557    5.71%  2346:9000::/13
Eastern Europe     307858000    5.01%  2346:9800::/13
Middle East        258577000    4.21%  2346:A000::/13
Southern Africa    242566332    3.95%  2346:A800::/13
Central America    175719760    2.86%  2346:B000::/14
Oceania             30568053    0.50%  2346:B400::/16
----------------  ----------  -------  --------------
World             6145512686  100.00%  2346:0000::/8


Example of one zone:

Country              Population  %Z Pop.  %G Pop.  IANA
-------------------  ----------  -------  -------  --------------
United States         285926000   89.85%    4.65%  2346:8000::/13
Canada                  1015000    9.75%    0.50%  2346:8800::/17
Hawaii                  1224398    0.38%    0.02%  2346:8880::/21
Bermuda                   60000    0.02%    0.00%  2346:8888::/24
Greenland                 12483    0.00%    0.00%  2346:8889::/24
-------------------- ----------  -------  -------  --------------
Zone: North America   318243350  100.00%    5.18%  2346:8000::/12

Implementing such a system would change the way large(global) LIRs
request space from RIRs. As of today, they would typically request one
/32 per RIR. For people the size of Sprint, they would then have to
request a /32 per country they service and assign space to customers
from the correct prefix.

What this means to large LIRs is a large initial number of prefixes, but
it's not fundamentally worse than an always-growing number of /32s when
IPv6 finally takes off IMHO.

For smaller LIRs that service only one country, there would be no
change.

There would be some impact on the GRT as there would be a "SPRINT-USA"
block, an "ATT-USA" block, a "SPRINT-GERMANY" block, an "ATT-GERMANY"
block, etc. In other words, what we are looking at is one /32 prefix per
country per large LIR, opposed to as many /32s a large LIR would need in
the long run anyway.

Comments welcome.


> - inside that RIR allocation, use the binary chop algorithm
>   described in RIPE-261 for the RIR->LIR distribution.

I'm not familiar with this; would that be something like RFC3531?

Michel.



  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community