when & how could policy be changed

[Jeremy Porter]

In message <3.0.2.32.19970701214734.00714c18 at pop.srv.paranet.com>, Stephen Spru
nk writes:
>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.

This seems fairly problematic to me.  Based on previous rushes on
the registries (Can you said Internic, before Sean's /19 filter?), I would
expect to see this resource consumed very fast, without substanitally impacting
the base perceived need.  We would defenitely require some type of assurance
of a net reduction in table size, but this assumes that these small
customers would be allowed to de-aggregated from their PA space,
which in a large number of cases is contractlly disallowed currently.
So I still don't see a net reduction.

I'd like to seem some real world numbers based on multihomed ASs
announcing /20s or smaller that aren't aggregated currently.

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

M increase with the number of multihomed customers also, since each route
appears in two or more views.  Essentlially now a /19 is required to
multihome via BGP and have global reachablity.  This reduces the
number of possible multihome sites.

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

Again, I disagree.  There seems to be little evidence to suggest
that de-aggregated /20s are being announced by single homed/dual home
systems.

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

I don't seem renumbering serves as a very difficult challenge.
I've renumber servers on 3 networks, two of them being regional ISPs,
and it just isn't that hard.  (Hint IP aliasing makes it much less painful).

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

---
Jeremy Porter, Freeside Communications, Inc.      jerry at fc.net
PO BOX 80315 Austin, Tx 78708  |  1-800-968-8750  |  512-458-9810
http://www.fc.net