[arin-ppml] ARIN Multiple Discrete Networks Policy

[John Curran]

I am a huge supporter of the principles in ICP-2, but we have a case where the policy provides for allocation of space to a particular configuration "Multiple Discrete Networks" with defining what makes networks discrete.  That leaves ARIN staff having to determine based on the stated examples and policy history.

If the community wants to clarify
Multiple Discrete Networks so that any
ISP (as well as the overall routing tables) can benefit from improved address
block management, then it can make
that policy change, but recognize that is a new use for a policy originally written for actual discrete networks.

FYI,
/John

John Curran
President and CEO
ARIN
(about to board a flight for many hours - expect lag in replies)

On Sep 29, 2011, at 10:45 PM, "Robert E. Seastrom" <ppml at rs.seastrom.com> wrote:

> 
> ICANN's ICP-2 states that the main goals of the registry system
> include "conservation of IP address space and aggregation of routing
> information".
> 
> To interpret the MDN policy as requiring disaggregation to the /24
> level and transferring that complexity to the DFZ routing table is at
> direct odds with the spirit of ICP-2, and turns the entire MDN policy
> section into a no-op.
> 
> I agree with Richard's interpretation of the MDN policy.
> 
> In other contexts ARIN has studiously refrained from prescribing
> particular engineering solutions to problems (for instance being
> silent on the issue of NAT, or not forcing autonomous system numbers
> to be reused at each node of an MDN cloud), and I urge ARIN staff to
> apply the same principles of confirming defensible engineering
> decisions - but not dictating a particular solution - as part of
> vetting a number resource request.
> 
> -r
> 
> 
> Richard A Steenbergen <ras at e-gerbil.net> writes:
> 
>> 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.
> _______________________________________________
> 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.