when & how could policy be changed

In message <v0310281aafdeee0588e2@[10.11.12.33]>, Michael Dillon writes:
>At 5:55 PM -0400 6/30/97, Gordon Cook wrote:
>
>> is there a view from the arin board that with stringent
>>dampening it could agree to give everyone a 19/?   or are you saying that
>>it would not have do this because the 'big boys' would all agree to route
>>20/s?
...
>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.
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.  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.

Now if we had some real data on the per flap costs, pathology of route
flap, effectiveness of flap dampening, etc.  Right now we are seriously
lacking data on flap. We need to ask where does flap orginate?
Can we dampen it at the source?  (Vadim's suggestion of link bounce
dampening might be useful.)  Also there is some hint of evidence to suggest
that some part of route flap is caused by policy changes.  Changes
to allow for soft reconfigurate can help, but there is the router upgrade
problem again.
Backbone providers do not have a economic motive to dampen flap that
is customer originated, compared to dampening flap at the peer level.

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.  Smaller providers have a number of cost advantages over
the larger players, and I see this as a way to offset the cost of
renumbering.  Since new allocations involve customer interaction, and
the customer interaction is the primary cost of renumbering, and renumbering
is fairly painless if the network is design properly.  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.

If you have people in PA /20, /21, etc., already you are going to have to
renumber, if you haven't started yet renumbering can be without any
distruption in services, and with a small finacial impact.  Thus renumbering
once does not seem to be a huge issue to me.  So far the only response
to this I have seen is that well, @Home got a large assignment,
which is completely different because @Home went to IANA, not to the
registries.

With this said, I do support the allocation of a routeable /19 to
providers that are a. Multihomed b. Have a history of efficient utilization
of addresses c. Are willing to renumber customers into their allocations
to maintain efficient utilization of routeable prefixes.

I have yet to see an objection to this proposal.  Other than unfounded
complaints of "Its not fair."

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

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