[arin-ppml] ARIN Multiple Discrete Networks Policy

[John Curran]

On Oct 4, 2011, at 12:15 PM, Jeff Wheeler wrote:

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

Jeff - As I noted earlier, this request was added to an existing work 
plan for a very busy year.  I'm actually quite pleased that we were 
able to add anything to the year, given the amount of work this year.

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

Correct.  What should be done in this area?

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

Thanks Jeff!  

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

Agreed - we have them, but they're working on an specific list of
deliverables.  Adding deliverables to the current year is always 
a challenge.

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

Agreed.

What useful things do you want us to do to "reduce DFZ bloat"  You have
mentioned that twice but not indicated exactly what you are looking for...

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

I said acknowledged your point about not having enough CPU to quickly
converge.  That actually occurs in large networks both internally and
externally: references to using FRR 'similar capabilities in architecting 
for specific path failures' is obviously for avoiding needless internal
recalcs; I did not mean to imply that it directly addresses DFZ bloat 
at all but simply that the concept of "prepopulation" is where we all 
go when we run out of enough resources to do things in a timely manner.

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

Let's look at some options -

  - Do you want ARIN to alter the way in which it does address allocations
    so it ties to the state of someone's IRR information?  If so, that
    would be an address policy suggestion.  I have no idea how the community
    would feel about either requiring the IRR to be updated to receive or 
    maintain address space, but you've got to get from the generic statement
    "do something to reduce the DFZ bloat" to "issue/don't issue/reclaim under 
    conditions z,y,x"
  
  - If all you want is for ARIN to improve its IRR services in some manner,
    and expend more budget in this area in the future, explain the feature
    that you want to me and I'll include it in the next list of objectives.
    (If you want to do it formally, you can submit the same to the suggestion
    process - https://www.arin.net/participate/acsp/index.html

Thanks,
/John

John Curran
President and CEO
ARIN