You are here: Home > Participate > Join a Discussion > Mailman Archives
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

Re: Changes to PI Policy?

  • From: Peter Gradwell < >
  • Date: Tue, 22 Apr 2003 17:16:46 +0100

At 18:05 22/04/2003 +0200, Gert Doering wrote:
Hi,

On Tue, Apr 22, 2003 at 05:59:10PM +0200, Andre Chapuis wrote:
> was only a suggestion....
> Let's say RIPE assigns 300x /24 to customers requesting PI, they could as well assign 300x /29 and this would always create 300 more routes in the Internet, not more; and saving address-space.

If those customers really only need a /29, why do they need PI space?

Unless this question can be answered in a way that's more than "because
they want!", I don't see any need to "fix" the policy here.
The justification for address space will always be "I want it because I
have N computers" and it cannot be possible for a registry to disagree
with that request.

If the request is "I have N computers which I want to connect to multiple
providers, but I don't wish to allocate address space to anyone else"
then PI space is the only (realistic) option.

If the problem is that
        (a) we have a limited amount of IPv4 address space
        (b) we can also only have a limited number of routes

then we must place them at each end of a set of scales and determine
the appropriate compromise to make the whole thing balance whilst we
think of a better solution (bigger routers, caching, etc).

Andre suggests that he could cope with /29 allocations. You prefer /24
allocations.

Would more /29 allocations cause such routing bloat as to cause a problem?

Would the wastage caused by /24 allocations cause an allocation problem?

Could some one at RIPE NCC do some mathematical modelling to
demonstrate the different affects that different balances might make?

cheers
peter


--
peter gradwell. gradwell dot com Ltd. http://www.gradwell.com/
engineering & hosting services for email, web and usenet






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