[arin-ppml] ARIN Multiple Discrete Networks Policy

[Owen DeLong]

As one involved in the authorship of said policy, permit me to clarify…

The actual intent of the policy is not related to aggregation, but, is
so that, for example, an entity that ran multiple content source data
centers that grew at different paces and operated independently
from each other without necessarily having (adequate) bandwidth
connecting those data centers could get separate allocations for
each datacenter that allowed them to get additional space for the
one that was at 80% while the others might still be nowhere near
"efficient utilization".

Specifically, this is designed to address the circumstance where
the allocations cannot be aggregated and must be announced
separately.

Owen

On Sep 29, 2011, at 11:59 AM, Richard A Steenbergen wrote:

> Hello,
> 
> I've recently found myself at odds with ARIN's interpretation of the 
> Multiple Discrete Networks policy, and thought it might be useful to 
> bounce to issue off of the community to see what they think.
> 
> https://www.arin.net/policy/proposals/2001_6.html
> 
> As a quick background, this policy is used by entities who operate 
> multiple discrete networks (for any of a variety of reasons, many of 
> which are cited in the policy), and who wish to have their allocations 
> and utilization calculated separately for each discrete network. An 
> example of where this makes sense is when one discrete network is 
> growing much faster than another, and the organization wishes to receive 
> new space for use by only that discrete network, without having to "play 
> games" like creating multiple maintainer IDs to receive such treatment.
> 
> The problem is that ARIN doesn't believe "promoting routing aggregation 
> on the Internet" is a stated goal of this policy, and thus anyone who 
> admits "well yes technically I could always just break up my single ARIN 
> allocation into a bunch of individual /24s for use by each discrete 
> network" does not "NEED" the policy, and therefore does not qualify, 
> even if every other stated justification and requirement of the policy 
> is met.
> 
> In my mind, the ENTIRE PURPOSE of letting a single entity apply for 
> space with each discrete network standing on its own merits is really 
> for aggregation purposes. Otherwise, almost any network would be able to 
> take their single ARIN allocation and break it up into a bunch of 
> smaller deaggregates for use by each discrete network, thus being able 
> to achieve the normal overall utilization goals. At the end of the day, 
> I can't think of anything else that is actually being accomplished by 
> this policy EXCEPT maintaining reasonable aggregation.
> 
> To me, ARINs policy interpretation seems not only wrong given the stated 
> goals of the existing policy, but intentionally harmful to the shared 
> global resources of the Internet. Increased deaggregation carries 
> significant costs in terms of routing hardware upgrades necessary to 
> support larger FIB sizes and increased memory and CPU loads, as well as 
> slower convergence times, especially within large networks who must 
> carry many views/copies of the routing table (think route reflectors, 
> l3vpn providers, etc). Wasteful announcements impact every BGP speaking 
> router in the global DFZ, and while ARIN's policy has traditionally (and 
> sensibly) been "routing agnostic", I don't believe intentionally making 
> the problem worse for no good reason is the correct solution.
> 
> I'd very much like to see something done about this, either through the 
> community voicing its opinion to ARIN about their interpretation of the 
> existing policy, or through a policy proposal which amends this to make 
> maintaining reasonable route aggregation a stated goal of the MDN 
> policy.
> 
> Thoughts?
> 
> -- 
> Richard A Steenbergen <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.