when & how could policy be changed

At 17:38 01-07-97 -0500, you wrote:
>>I personally would like to see some PI space opened up with longer prefixes
>>than /19. This could be a new /8 like 210/8 that we all agree to allocate
>>in /20 blocks. Or we could use reclaimed space from the swamp and allocate
>>it in /20 and/or /21 sizes. In the case of 210/8 we need providers to agree
>>to adjust their filters. But before we can decide just how this should be
>>done we need some hard numbers, especially on how many additional routes
>>the new PI space would add. And we also need some more thorough analysis of
>>the prefixes that appear to be eligible for aggregation in the weekly CIDR
>>reports.
>
>The only problem is that going from /19 to /20 doubles the total
>table size, assuming lack of greater aggregation, worst case.

The proposal was to allocate a fixed number of PI /20 blocks which would be
specifically for use by multihomed providers that didn't qualify for a /19
(or shorter) under RFC 2050.  This will not double the total table size,
only increase it by 4k routes in the short term; hopefully, in the long
term it would reduce the number of more-specifics advertised out of the
large ISPs' PA blocks, having a net REDUCTION in the routing table size.

>There are issues with flap, and dampening helps but does not solve
>the problem.  The problem seens to growth with order N^M,
>where N is the number of prefixes and M is the number of peering sessions
>or views.

N will remain roughly constant, since we are merely switching PA route(s)
for an equal or slightly shorter PI route.  M will remain constant, since
the AS's in question are already advertising routes on the net.

> Also for fun the cost of upgrading networks grows at N^R, in this
>case R is the number of routers. We have some data to suggest
>that todays hardware could handle the load generated by /19 aggregation,
>but also seems to indicate that we cannot as a general rule freely
>allocate /20s, without severly imparing network perfomance in the near
>term.

Again, N is not intended to grow significantly (and may in fact shrink).

>Having renumbered several /20s and a /19, I don't see they need to
>create PI /20 space.  There is this ideal out there that the playing
>field should be completely flat, however, in the real world, this
>isn't the case.

I'm not after a separate-but-equal net; there are technical problems that
creating said PI space would solve.  If done correctly, it would:

. Reduce routing table entries
. Reduce the effects of flap
. Reduce the "holes" in the large ISPs' PA blocks
. Reduce the number of unqualified AS's requesting RFC 2050 /19 blocks
. Make it easier for small ISPs to grow, fostering competition

>All modern hardware
>and software can support dynamic assignment for networks.  With a small
>bit of planning and intergration, one change can renumber DNS A and PTR
>records, and change the assigneds when the DHCP leases expire.

You're ignoring the important minority here: servers. 

>If there is enough intereste I will work up this proposal to put
>before the ARIN membership at the first suitable time.

As I'm sure hundreds of others will as well.


Stephen