proposal for RIPE's IPv6-address space structure

  > JOIN Project Team <join at uni-muenster.de> writes:
  > > Can you provide a rationale for grouping providers by country.
  > > It strikes me as contrary to both aggregation and conservation goals.
  > 
  > We assume that ISPs will mainly offer their service within one country.

This is not necessarily a valid assumption.  You might want to test it
against the current local IR list.  More importantly the number of ISPs
per country is not easy to predict.  So there will be fragmentation
which is bad for conservation.  Also topology may suggest ways
aggregation that do not follow county boundaries.  So far I see only
arguments against grouping by country and not a single one in favour. 

  > > This is very difficult to do since it is by no means clear where regional
  > > boundaries will be.
  > 
  > Is it much more difficult to draw a border between the African RIPE region
  > and the European RIPE region than between the RIPE region and the INTERNIC
  > region?

While one may expect that regions will be delineated by geography it is
by no means clear that it will turn out that way.  A region will be
defined by large groups of ISPs agreeing to be served by a regional
registry.  Maybe Northern Africa will be a different region from
Southern Africa again different from the Middle East.  Maybe they will
all be one region.  It is by no means clear.  As grouping picked today
not may make sense once this process starts and worse it may be
counterproductive. 

I propose to use region IDs per regional registry.  Once a new regional
registry starts it gets a new region ID. 

  > > For this to work, the additional space needed must be exactly
  > > the reserved size. Usually it is either less or more.
  > > Strategies like that have been shown to be less than optimal for
  > > conservation while the additional aggregation effect is not very
  > > big. 
  > 
  > Do you prefer a scheme in which the address space of a provider is
  > more precisely adapted for its needs? 

Yes. 

  > More conservation, less aggregation?

That is not necessarily a consequence of the above.  The real challenge
of assignment and allocation policies is to get consensus about the
right balance between the two. 

  > > How about just using the 56 bits for local-IR+subscriber?
  > > The boundary does not need to be fixed at all.
  > > Then use a similar scheme than the present IPv4 one to determine the
  > > size of allocations to local IRs (provider): 
  > > Fixed size for new local IRs and further allocations based on
  > > established usage rate.
  > 
  > I think this scheme could result in a too conservative allocation policy
  > with regard to the large address space we have at our disposal. It might
  > be negative for aggregation and/or IPSs.

It could result in a too conservative allocation policy just as well as 
any other scheme proposed; it does not have to.  
We still have to have the discussion about appropriate allocation sizes.  
I only know that the allocation sizes should not be fixed
should not be fixed, i.e.  every ISP gets the same size because that
will be far less than optimal. 

My question was rather: Is there anything wrong with my proposal of
using the 56 bits for just two fields local IR and subscriber with a
varying boundary.  Do we need other groupings?  If yes, for what
specific purpose? 

Daniel