[arin-ppml] ARIN Multiple Discrete Networks Policy

[Jeff Wheeler]

On Tue, Oct 4, 2011 at 10:08 AM, John Curran <jcurran at arin.net> wrote:
> We have to pace our development efforts, and provide incremental
> improvements in multiple areas at once (ARIN Online registration
> capabilities, Online billing support, RESTful enhancements, IRR
> improvements, RPKI development, etc.)  We haven't given up on
> further ARIN Online/IRR integration, but need to prioritize the
> work and sometimes this means doing things next year to keep this
> year's expenses within plan.

It's worth mentioning that you stated the reason for ARIN needing from
March (?) until August to do something simple, like enable support for
passwords and PGP, in the ARIN IRR was that your I.T. folks intended
to integrate the IRR with other ARIN services.  I point this out
because I strongly believe that your I.T. staff is inadequate and
needs a great deal of improvement.

Not only did a simple task to address a very critical security concern
which could have been exploited by "bad guys" at any time (and still
could, while many mntners remain without passwords/etc) get ballooned
into a larger project which was to take many months, but you then
missed your projected completion date by a month or two and had to
back-peddle and do what I originally suggested: take care of the
security concern urgently, and look at a more sophisticated
integration later on.

If ARIN needs to have a larger I.T. budget to get things done, I for
one am happy to advise my clients to vote in favor of fee increases.

TCAM and tree-based look-up engines with a large memory capacity (for
DFZ routes) are expensive to operate.  They use a lot of power,
produce a lot of heat, and limit the density of routers.  The more
routes there are in the DFZ, the more money we all spend on the next
generation of routers to handle that growth.

The larger the DFZ, the more CPU is needed to converge in a reasonable
period of time (see Richard Steenbergen's many posts on this topic
lately.)  Since single-core performance is not growing much anymore,
vendors are now looking at parallel route processing, with a big R&D
expense to deliver this capability and associated performance
improvement.  IETF is producing various ideas on how to pre-populate
repair paths into the network.

There is a great deal of work going on to maintain the reliability of
the Internet as the DFZ continues to grow, but really, not much at all
is being done to constrain the DFZ in the most sensible manner -- by
reducing unnecessary routes introduced simply by mistake.

If ARIN needs to spend a million dollars to write some Perl scripts,
by all means, spend it.  When you consider the long-term cost of a
continually growing DFZ, and ever-increasing FIB memory (heat/power)
to keep up with it, there is no "greener" I.T. project that ARIN could
undertake, and none with a better cost / benefit equation to the
community, than investing in a more sensible DFZ.

-- 
Jeff S Wheeler <jsw at inconcepts.biz>
Sr Network Operator  /  Innovative Network Concepts