[arin-ppml] ARIN Multiple Discrete Networks Policy

[Jeff Wheeler]

On Tue, Oct 4, 2011 at 8:51 AM, John Curran <jcurran at arin.net> wrote:
> On Oct 4, 2011, at 8:15 AM, Jeff Wheeler wrote:
>> evolve rapidly in the next several years, to a point where allocations
>> being made today become a new "swamp" that could eventually be far
>> worse than its v4 counterpart.
>
> I concur that this is a distinct possibility.

I think it is the inevitable outcome of current allocation policy and
the lack of any neutral entity that takes interest in routing table
growth.  The RIRs are not able to dictate inter-domain routing policy,
and if unease about RPKI is any indicator, most members do not want
them to be tasked with that.  This doesn't mean the RIRs shouldn't
facilitate sensible guidelines.  We should be asking them to do that.

> (Re: authentication, see last's weeks IRR upgrade announcement:
> https://www.arin.net/announcements/2011/20110929.html)

It seems that integration with the ARIN web site / registration
systems, as I believe was your goal earlier this year, did not happen?
 I think that was a perfectly good idea, but obviously you have
addressed the security concerns I raised, which is a prerequisite to
anything more useful.

> Hmm... the ability of folks to express what routes they intend to
> announce doesn't necessarily mean you won't still see an abundance
> of announcements; you'll just see appropriate IRR entries describing
> that routing config in the IRR.

This is certainly true, but you would be surprised how common it is
for inexperienced operators to leak a bunch of /24s from their new RIR
allocation simply by mistake.  Many North American networks do not use
an IRR or rely on their ISP to guess at their intent and create "proxy
objects," which is why the various IRRs in common use by ARIN-region
networks are such a mess.  It is a contributor to DFZ bloat.

If an operator really wants to inject a route to the DFZ, I don't
think I want ARIN to be in the business of stopping them.  I would
like ARIN to be in the business of making it easy for transit networks
to differentiate between intent and accidents.

> If folks want to tie address policy more tightly to declared routing
> policy, that can be done.  Again, this is not something for ARIN to
> do without clear community direction in this area.

I really think it's too late for this to really be fixed where IPv4 is
concerned, but IPv6 DFZ is "fixable" because it isn't too bad yet, and
there is plenty of time to institute sensible policies, and for ARIN
to provide operators with useful tools, like an IRR that is easier to
use (now that it's secure.)

>> I believe in the future, the ARIN membership will realize that we need
>> it to police routing table bloat, or the v4 tables we have today will
>> look small and orderly by comparison.
>
> I highly suggest discussion of these ideas on this mailing list or in person
> at Philly (both in the hallways and at the open microphone session). ARIN
> is your organization, and to the extent the membership supports this as a
> direction, it will happen.

It may be time to revisit some old lessons that many of us take for
granted.  I received an off-list mail in response to this thread from
an operator asking how he could clean up his advertisements.  He has
common transit at many or all of his locations, and was apparently not
aware that he could use no-export functionality to avoid injecting his
de-aggregates to the DFZ.  The reality is that there are thousands of
networks being run by inexperienced people who may clean up their
advertisements if they are simply shown how.  The person asked if I
had any links to presentations or documentation that would provide him
guidance, and I am sorry to say that I had none, and simply suggested
some options to him by email.  It's understandable that he was not
aware of how he could do this better.

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