[arin-ppml] ARIN Multiple Discrete Networks Policy

[Richard A Steenbergen]

On Fri, Sep 30, 2011 at 10:41:37PM +0000, John Curran wrote:
>
> If network #2 is the mobile wireless business unit, it might be next
> to impossible to reallocate the space once it's been allocated.

How so? They can't work SWIP? Everyone else manages to do it just fine. 
Are you saying that every recipient of a multiple discrete network 
allocation is someone in some goofy circumstance of corporate insanity? 
Because it seems to me that anyone who can work SWIP and BGP is 
perfectly capable of having network #1 steal a /24 from network #2's 
space, and thus by your logic make the MDN policy apply to almost no 
one.

> 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.

I'd have to disagree with this as well. Again, from the text of the 
policy:

> 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

Lets consider the example "geographic distance and diversity between 
networks", which is specifically listed as a compelling reason. The 
geographic diversity angle seems simple enough, if a network has (for 
example) a presence in Miami and a presence in Seattle, it could be 
quite sensible for them to operate these two regions as discrete 
networks in order to ensure optimal routing. Similarly, it would be 
quite reasonable to assume that they may need/want diverse transit 
providers in each region (e.g. buy from someone in Seattle who doesn't 
have a presence in Miami, and vice versa), which would also require 
operating as discrete networks.

Clearly "every pop" isn't deserving of being treated as a discrete 
network (e.g. two pops in the same city), but the policy very 
specifically outlines geographic distances and network diversity as 
compelling reasons. Sure you could argue that "geographic distance" 
isn't defined, but I think you'd have a hard time arguing that something 
like Miami to Seattle doesn't qualify, considering it spans almost all 
of the ARIN region.

It seems to me that you're deliberately ignoring a portion of the policy 
as written. If the community would like to change it, then fine, but I 
think the policy as its written today seems perfectly clear on the above 
point.

> 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

I'm not sure how I'm not being clear here. Perhaps if we break this up 
into two components.

Part 1
------
Question: Does the organization have a compelling reason to operate
multiple discrete networks?

Answer: The policy as written lists 3 very specific examples which serve 
as compelling reasons for creating multiple discrete networks. If the 
situation of the applicant matches one of these examples, then the 
answer would seem to be "yes they do have a compelling reason", and we 
move on to part 2.

Part 2
------
Question: What does ARIN need to do about it, in regards to the MDN 
policy?

Answer: As you just said, in the circumstances of someone operating 
multiple discrete networks, the allocation cannot be aggregated and must 
be announced separately. And as you just said in the previous email, 
"the policy was designed to address the circumstances where the 
allocation cannot be aggregated and must be announced separately". 
Therefore, if there IS a compelling reason (as defined by the policy) 
for creating multiple discrete networks, and all the other policy 
requirements are met, how is it that the policy doesn't apply?

Notice how "aggregation" has ABSOLUTELY NOTHING to do with the 
compelling reason to run multiple discrete networks. But if you *DO* 
have a compelling reason, then as a consequence you *MUST* announce each 
route separately (your words), and thus the policy exists to help you 
obtain address space which can be announced separately (your words). 
This is the only context in which I'm using "aggregation", where you 
yourself have said the policy acts to provide it.

> 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.

I'm completely baffled how you can say in one breath "the policy exists 
to handle the situation where the allocations cannot be aggregated and 
must be announced separately", and then say "the policy has nothing to 
do with aggregation" in the next.

The logic seems blindly clear to me:

IF you have a compelling reason to run multiple discrete networks
THEN you have a circumstance where things must be annouced separately

IF you have a circumstance where things must be announced separately
THEN the policy exists to help you obtain address space

-- 
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)