[arin-ppml] ARIN Multiple Discrete Networks Policy

[Jeff Wheeler]

On Tue, Oct 4, 2011 at 11:04 AM, John Curran <jcurran at arin.net> wrote:
> Thanks for your perspective on this; I obviously do not agree (but
> that's to be expected - If I had, I would have addressed it already)

A March until September turn-around time on enabling passwords in your
IRR doesn't indicate to you that you need more I.T. resources?  Are
you still not sure why the ARIN IRR is an important tool for
operators?

Do you know what havoc would be caused if some malicious person
decided to delete or corrupt all the unsecured data in the ARIN IRR?
There would be wide-spread network outages as transit provider
prefix-lists were updated.  A lot of clueless customers would not
understand why, and simply call their ISP for help.  ISPs would have
to roll back to the previous day's ARIN IRR data ... and could no
longer trust any data from ARIN IRR because of the numerous unsecured
mntners which could be attacked again.  This would be a lot worse than
any route leaks in the past few years, would make the news, and would
have governments questioning the competence of ARIN (steward of this
information) and asking why the ability to modify this information
wasn't simply ... protected by passwords.

It still isn't, and won't be, until a significant portion of ARIN IRR
mntners change their authentication mechanism.

The fact that it took ARIN many months to fail to integrate the IRR
into your other systems in the planned manner, *and* also took many
months to simply enable passwords, without you believing that you have
inadequate I.T. resources, should cast doubt on your understanding of
how inter-domain routing works (at minimum) and your ability to
prioritize ARIN's expenditures (time and money.)

> We've never raised fees, and that's not the general direction that

I'm not questioning that ARIN should try to be efficient.  That is
certainly good.

Having no I.T. resources to work on ways to reduce DFZ bloat, or
address IRR security problems, is not good.  You have stated that your
I.T. resources are limited and must be prioritized, and this is true
of most organizations.  But if you can do useful things for the
community with additional I.T. budget, the notion of increasing fees,
or simply not reducing fees again very soon (since ARIN operates at a
surplus), should not be off the table.

>> 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
>
> Acknowledged (although many of us opted for MPLS and fast reroute paths
> for similar capabilities in architecting for specific path failures in
> advance)

You don't understand the difference between inter-domain convergence
issues, and intra-domain ones.  They are certainly linked, but MPLS
FRR is not a solution to DFZ bloat driving up convergence times.  It's
not like operators can simply configure FRR and not have this concern.
 Besides that, if you reboot a box, FRR helps the rest of your
network; but it does not help that box, or the customers connected to
it, recover any faster.  This is why I mention that IETF is producing
new ideas in this area which might eventually help us, vendors have
done a lot of work, etc.

I don't mean to rudely call you out for not understanding the way
things work, but if you're going to point to FRR as a technical
solution, I think you should understand what problems that technology
does and does not address.

It certainly does not address power/heat issues -- in fact it
increases them, as do all the IETF ideas in this area.  There are
undoubtedly hundreds of thousands of routers participating in the DFZ,
each of which has OpEx associated with FIB memory.  If you could add
up the electric bill for all that memory, you'd quickly find that it
out-weighs the small cost of RIRs doing more work for us to reduce
accidental introductions of new routes to the DFZ.  The capital cost
of upgrades, too, is very significant and easily eclipses the I.T.
cost of controlling DFZ bloat.

> Please make a concrete proposal for discussion by this community.  It
> would be quite timely, since myself and the staff are presently trying
> to prioritize the 2012 budget and looking forward to input here and at
> the Public Policy Meeting next week.

If you are saying, "put up or shut up," this is well-received.  I am
not a policy-hawk, and do not understand the process for directing
ARIN to "spend time and money on reducing DFZ bloat."  How can this be
accomplished?  What would be the procedure for asking members whether
or not they want to task ARIN with this, and spend necessary time and
money to do so?

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