[arin-ppml] ARIN Multiple Discrete Networks Policy

[Jeff Wheeler]

On Mon, Oct 3, 2011 at 7:32 PM, John Curran <jcurran at arin.net> wrote:
>>   In order to be assigned an AS Number, each requesting organization
>>   must provide ARIN with verification that it has one of the following:
>>
>>     • A unique routing policy (its policy differs from its border gateway peers)
>>     • A multihomed site.

The "unique routing policy" language above is not necessary.  I'm not
sure it ever was.  All you have to do to get organizations the AS
numbers they legitimately need is to understand what a multihomed site
is, and that it does indeed apply to islands within enterprise
networks, those who may have private interconnections to two or more
other enterprises but no Internet connectivity, and so on.  Discrete
networks is another application where ARIN have allowed organizations
to have multiple AS numbers, and given that we aren't really in danger
of running out of ASN, this is good (other than problems with 32-bit
ASN implementations, another topic that is not necessary to rehash.)

The ASN language should not be anyone's first or primary example of
how RIR policy and inter-domain routing policy are closely related.
Sure, if you hit find and type "routing policy" into the box, that's
what you get; but I don't think either of us have such a pedestrian
view of the way things work that the "unique routing policy" provision
for ASN allocation is of any real consequence.  It should never have
been codified in the first place, but it is harmless.

> applicant requests such to qualify.  It is true that the ARIN
> community has generally shied away from having address policy
> based on routing criteria, but if folks make address policy which
> includes routing criteria, then the ARIN staff will indeed
> implement it.

I have given several examples of how ARIN takes routing policy into
account when allocating addresses, even though the NPRM does not
direct ARIN to do so.  This is good -- ARIN has applied common sense
to these areas of policy interpretation and we benefit from it.

The problem is you, specifically, and a lot of other folks, have spent
time and energy denying that the RIRs should or do care about routing
instead of figuring out what non-obstructive, beneficial things you
can do.  I would love to read the email from John Curran that says,
"if we *did* care about routing, what could we do to reduce DFZ bloat
without getting in anyone's way?  Do we need any different policy
language, or are there things we can do today?  What kind of
applications will be affected by proposed changes?  What affect will
this have in a post-exhaustion world?"  I don't see any of that.

As long as folks continue to deny that RIRs should involve themselves
more explicitly in inter-domain routing policy, we are climbing higher
and higher up a hill, and v4 exhaustion may push us over a cliff.  I
don't think anyone wants to upgrade all of their routers because ARIN
leadership were afraid to explore what benefits (and disadvantages)
there could be from modifying policy interpretation, and from no
longer shying away from policy changes that impact routing policy.

Here is the harsh reality: IPv6 is a real danger to us because we
currently have folks de-aggregating to /48 boundaries within /32
allocations, special allocations for critical infrastructure are
poorly-understood, and most operators are afraid to filter because
there is very little guidance in this area.  With the plentiful IPv6
address space, we could have a much more efficient system, or we could
have one that is far worse than IPv4.

On the other hand, there isn't much reason for the RIRs to have a big
staff if the frequency of requests from growing ISPs changes from
several times per year to a few times per decade (if they ever need to
make a follow-up request at all.)

ARIN's primary job, for its entire lifetime, has been to be a
barrier-to-entry.  ARIN does nothing better than say "no," because
that's what we needed it to do.  In an IPv6 world we will no longer
really have that need.  Unless RIR policy gets really, really stupid
(though it is in some ways already) we will never exhaust IPv6 and
will hopefully never need to implement policies to stave that off.

What we do need is to control routing table bloat.  This should be the
primary function of RIRs in an IPv6 world, and yet they continue to
resist this job.

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