[arin-ppml] ARIN Multiple Discrete Networks Policy

[John Curran]

On Sep 30, 2011, at 5:58 PM, Richard A Steenbergen wrote:

> 1) I think phrase "autonomous multihomed discrete networks" is intended 
> to mean networks operating different autonomous systems, not networks 
> without a "significant common authority" as you say. The former provides 
> a perfectly reasonable example of a compelling reason for using MDNs 
> (since they indeed *cannot* aggregate their announcements), while the 
> later has absolutely nothing to do with anything.

If that is the intent of the policy text, the text will need to be
modified to make that clear.  We certainly know how to reference 
"networks using distinct autonomous system numbers" is that is truly
the intent.  The policy text and history does not support that 
interpretation, but it is easy enough to change if the community 
desires.

> 2) For the record, absolutely nothing prevents any organization of any 
> structure from taking their allocation and deaggregating it in any way 
> necessary to route it across the Internet.
> 
> In our hypothetical example, say that ARIN gave them a single /19 block 
> which they divide evenly into 2 /20s, and then later find that network 
> #1 needs more space while network #2 does not (the textbook example of 
> where the MDN policy is needed). There is *NOTHING* that prevents them 
> from "stealing" the unused space from network #2 by announcing a bunch 
> of deaggregate /24s from network #1, thus being able to eventually 
> achieve the utilization requirements without the MDN policy.

If network #2 is the mobile wireless business unit, it might be next
to impossible to reallocate the space once it's been allocated. 

> 3) There are actually 3 examples cited in the policy, and you're 
> ignoring the other two. For the record, the text says:
> 
> The organization must have compelling criteria for creating discrete 
> networks. Examples:
> 
> * regulatory restrictions for data transmission
> * geographic distance and diversity between networks
> * autonomous multi-homed discrete networks
> 
> All 3 are perfectly valid examples of compelling reasons to use the MDN 
> policy, and anyone who demonstrates one of them (plus meets all the 
> other stated requirements) should be allowed to use the MDN policy, 
> PERIOD. Nowhere in the policy does it say "must demonstrate that the 
> problem cannot possibly be solved any other way", which is what you're 
> asking for. Indeed I've already shown above that the problem for your 
> cited example can be solved another way, thus by your logic the entire 
> MDN policy becomes pointless (as rs already pointed out).

Actually, it's a very useful policy for organizations that actually have 
multiple discrete networks, but not useful for networks with multiple POPs
that are seeking to use the policy to avoid having to break up their space
into smaller blocks with corresponding smaller routing announcements.

> 4) Look at what you just said above, "where the allocations cannot be 
> aggregated and must be announced seperately". By your own admission, the 
> point of the policy is about aggregation!

Richard - The policy allows an organization to obtain address space 
under circumstances where there are multiple distinct networks.  In
these circumstances, the allocations cannot be aggregated and must be
announced separately.  That does not make the point of the policy to
be improved aggregation, the intent of the policy is to allow use of 
a single maintainer id for organizations with multiple discrete networks
and this is clearly described in the original policy submission: 
http://lists.arin.net/pipermail/arin-ppml/2001-September/000360.html

>> Obviously, we can change the policy to also address the case where the 
>> default ISP additional space policy results in having to finely divide 
>> allocations in small pieces among POPs (in order to handle differing 
>> POP growth rates), but that should be discussed by the community first 
>> to determine it is a desirable policy change.
> 
> I fail to see any change necessary, this is precisely what the policy 
> already handles.

Your interpretation is incorrect, but that does not mean that a policy
change to allow for improved aggregation for additional ISP requests is
not worth considering.  Hopefully, we can get some discussion here of 
the value of such a change, and whether it should be for all ISPs, ISPs 
who have distinct AS routing domains, or some other criteria.

Thanks!
/John

John Curran
President and CEO
ARIN