when & how could policy be changed

Jeremy and all,

Jeremy Porter wrote:
> 
> 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.

  Yep!  I really don't either.
> 
> 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.

  Exactly!  And again, curently is one of the reasons why I possed
my original question as suggested that if there is to be a new
multihomed ISP starting up that there should be some consideration for
/19 allocations initialy.  Benifits everybody as I see it.  >;)
> 
> >> 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).

  I agree that this is not very hard, as you put it here, but is
not necessary and somewhat time consuming, with potential user
impact.  I think the big picture is more important in this regard.
> 
> >>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

Regards,
-- 
Jeffrey A. Williams
DIR. Internet Network Eng/SR. Java Development Eng.
Information Eng. Group. IEG. INC. 
Phone :913-294-2375 (v-office)
E-Mail jwkckid1 at ix.netcom.com