Criteria for initial PA Allocation

Hi,

On Tuesday, May 22, 2001 15:58, Gert Doering, Netmaster
[SMTP:netmaster at space.net] wrote:
> Hi,
> 
> (originally I did not really want to participate in this discussion,
> as much of it has already been said in the last LIR-WG meeting).
> 
> One thing got me thinking,though:
> 
> On Tue, May 22, 2001 at 02:16:32PM +0100, Carlos Friacas wrote:
> > /22 is a much more reasonable value by my view... 
> 
> Be careful what you are asking for.
> 
> If we assume that minimum allocation size will go down to a /22, and
> further assume that one fourth of the full IPv4 address range will
> subsequently be handed out *and announced* as /22's, this means we
> will see ( 1/4 * 2^22 ) = 1048576 /22's announced in the global BGP
> table.  That's over a million BGP routing table entries.

I agree this is a concern, but it's always better then having the same
amount of /20's in the table. I agree that we have to guard that potential
'real' LIR's do not start off with a /22, but that is also already achieved
by reserving contiguous address space for a certain amount of time. The
point is, would the NCC also decrease this reservation mechanism?

> 
> This will have a significant effect on BGP routing stability and
> also on the costs of global routing - you need a Gig of RAM in all
> the BGP routers (on distributed architectures, more than that).  The
> CPU power required to handle a flap of a major line in a timely fashion
> (to keep BGP convergence times low) will be horrendous.
> 
> Also, it can be assumed that in this case, the global topology will
> become complex enough so that most of the time many of the smaller
> ASes won't be reachable anyway due to problems "on the way".
> 
> I think this is something I do NOT want to see.
> 
> 
> So, what is my conclusion?  I estimate that while IPv4 address exhaustion
> is going to be a problem (which IPv6 will solve), the routing topology 
> will cause major problems *sooner* than IPv4 runs out, and we should
> do something against this.  By this, I mean:

IPv6 solves the exhaustion problem, but does it solve the multihoming
problem? You would still have a lot of small companies wanting 'routable'
address space. Getting PA address space makes you dependable on the routing
table of at least one provider and thus doesn't guarantee you redundancy.

> 
>  - strongly encourage people to renumber from historic PI space to
>    PA space from their ISPs network block (and return the PI space
>    to the RIRs, to be aggregated)
> 
>  - stop handing out PI space
> 
>  - discourage "end users" from using multihoming with globally visible
>    address space (there are other ways, like "get multiple uplinks
>    to different POPs of the same ISP, and have them sign a SLA that
>    will get you 99.9% reachability or money back").

That is not really the same. For many companies, an outage of a few days can
mean that they are out of business. Having your money back is then your
least concern.
The fact is that disasters do happen to every ISP once in a while and a lot
of company's want to protect themselves from that. I don't think you really
can discourage that.

> 
>  - discourage people from becoming LIR if that's only to get "portable"
>    address space, with no intention of handing PA space out to customers.

That's nice, but you'll have to be able to offer them a good alternative.
There are a few good alternatives (like NAT), but not all of these are
workable for everybody.

> 
> Yes, this might sound a bit harsh, but I'm *really* worried about
> routeability and reachability of anything in the next couple of years.

I agree it can create huge problems and we have to be careful, but the fact
is multihoming is a huge dilemma for a lot of small company's (small of
course in the sense of size of IP address space).

Regards,
Bert van Hogeloon

> 
> Now go and flame me... :-)
> 
> Gert Doering
>         -- NetMaster
> -- 
> SpaceNet AG                 Mail: netmaster at Space.Net
> Joseph-Dollinger-Bogen 14   Tel : +49-89-32356-0
> 80807 Muenchen              Fax : +49-89-32356-299
>