proposal for RIPE's IPv6-address space structure

Hi Daniel,

On Fri, 22 Nov 1996, Daniel Karrenberg wrote: 

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

Does this imply that one geographical region may be covered by more
than one regional registry? In this case 5 bit Reg IR ID would not be
really 'plenty'.

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

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

Section 3.2 in ID [1] says that a Regional Registry may have more than one
block of addresses allocated to it.

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

I agree. We are sceptical about aggregation on the regional/country level.
So it gets more important to achieve almost optimal aggregation on the
provider level, i.e. one prefix per provider. But even with this claim:
Before running in problems with conservation (i.e. insufficient 
conservation), we would probably get problems with aggregation 
(i.e. insufficient aggregation). Consider, in our proposal a single
country has room for 2^17 providers.

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

I don't think that there is anything wrong with your proposal. But
for really estimating it, it is not concrete enough. It would be helpful
to start the 'further discussion' on detailed policies such as 
ranges for r.

> 
> Daniel
> 

Guido