[arin-ppml] Does Moore's law help with routing table growth?

[Matthew Petach]

On Fri, Dec 18, 2009 at 9:34 PM, Scott Leibrand <scottleibrand at gmail.com> wrote:
> On 12/18/2009 9:19 PM, Michel Py wrote:
>>
>> I don't think we have much maneuvering room though; the benefits of
>> Moore's law helping building faster routers are more or less offset by
>> the same Moore's law helping building more bandwidth-hungry consumer
>> devices.
>
> Except that the bandwidth of consumer devices is completely independent of
> the number of routes we have to stuff into our FIB.  That is dependent on
> the number of independently multihomed networks, which is determined by
> economic and business forces.

Which seems to imply that one perfectly valid control point to limit the
growth of the routing table is simply keep raising the price of registering
an ASN to the point where few enough new business can afford to multihome;
if we keep the number of new multihomed networks entering the global
tables to a rate slightly slower than the development and deployment
curve of hardware able to do lookups on those new multihomed networks,
then we should be able to continue to scale the DFZ as long as necessary.
Just give the hardware engineers a means to feed back into the RIRs if
they run into a roadblock, so that the appropriate fees for an ASN can be
raised to slow down the rate of new multihoming entrants until the technology
is able to overcome the roadblock and continue progressing again.

Thus, the concern of DFZ routing table slots moves firmly into the business
realm, subject to economic forces, and out of the policy-making arena.

>>  In other words, growth of the DFZ table has to rely on router
>> enhancements, not on riding Moore's law.
>>
> I believe that enhancements in router FIB capacity are to some degree
> dependent on the same forces driving Moore's law.  Obviously keeping Moore's
> law going (whether in CPUs or in TCAMs) requires hard engineering work, but
> that's not the point.  The point of Moore's law is that all that hard work
> results in a periodic doubling of capacity (in this case, FIB routes) for
> the same price.  For now, that improvement is keeping ahead of the growth
> rate of networks seeking to multihome.

We currently have a very loose economic feedback system in place;
the hardware needed to effectively multihome via BGP4 is kept expensive
because it's funding a rapid development cycle which is attempting to
stay abreast of that curve.  If we raise the costs to multihome, fewer
networks will add to the DFZ routing table, and the pressure on growth
and technology advancement decreases.   We can raise the cost to
multihome in 2 ways; one, through the hardware costs (today's model);
the other is via the one other item required for multihoming--number
resources (IP addresses and ASNs).  ASNs are explicitly tied to
multihoming, so those are an easy one to control; raise the price,
and fewer new entrants show up to tie up slots in the DFZ RIB.
Non-aggregatable IP addresses can also contribute, but they're
a little harder to pin down; you may be using them internally, and
not advertising them at all externally, so they don't burn a slot.
And extending existing allocations should also not burn additional
routing table slots, so pricing on extending existing allocations
won't have the same effect, and doesn't need to share the same
economic feedback loop.


>> There is no such thing as "PI for everyone" in the foreseeable future.
>>
> If by "everyone" you mean "every organization with a single-homed network",
> then I agree, that will be infeasible at least as long as we're running
> BGP4.  But as long as we move the bar gradually, I think we can safely move
> toward a situation where PI addresses are generally available for multihomed
> organizations who are willing to pay their providers enough to run BGP.

I'm interested in digging deeper on the "as long as we move the bar gradually"
concept.  I'm thinking of economic feedback loops to help keep the bar moving
gradually, based on pricing of new ASNs and new non-aggregatable IP address
allocations, which would definitely play a hand in keeping that rate of change
under control; but the one area it doesn't help control at all is the people who
de-aggregate their existing space.  Right now, we have no explicit registration
requirement for prefix announcements, unlike with registering for new ASNs
or new IP address blocks, so there's no means to provide pushback on the
number of additional slots consumed when people deaggregate existing
blocks.

Would it help if we made route table advertisement registration via the
registry's IRR mandatory, and charged each network for IRR services
based on the number of route announcements they make--so, first
announcement for the supernet/aggregate comes free with the number
resource, but each additional more specific within the aggregate
comes at increasing cost to register?  First deaggregation costs
$100/year additional, second one from the same supernet costs
$200/year additional, etc.
That way, even if you have 1,000 prefixes assigned by the RIR, if
all you announce is the aggregates, there's no net additional cost;
but if you have a single /20 from the registry, and deaggregate it
down to /24s, it'll cost you $12,000 extra per year (for the 15
additional deaggregations you've added within the block).
That would give  us very strong economic feedback systems for
ensuring that companies are well-motivated to not deaggregate
unless it is for very good business reasons (ie, the additional
revenue they bring in by deaggregating more than offsets the
additional costs for registering the deaggregates.)

That would also bring about the benefit that we could all build
very clean explicit route filters based on the contents of the
routing registry; if you haven't paid to register the route, people
won't listen to it.

I suppose it's easier to charge more for IP addresses and
ASNs to limit growth than it is to charge for route registrations
because up to now, there's been no charge for route registrations,
and there'd be a huge hue and cry if we tried to start charging
for them, probably even more of a fuss than was heard when
ASNs and IP address registrations were first charged for.

Still...I do think it's valuable to realize that fundamentally the
concerns people have over routing table growth are largely
economic ones, so it would make sense to put the feedback
controls squarely into the economic realm, rather than trying
to figure a way to jury-rig them in via the policy system.

> -Scott

Matt