[arin-ppml] ARIN Multiple Discrete Networks Policy

[Richard A Steenbergen]

On Fri, Sep 30, 2011 at 06:36:31PM +0000, John Curran wrote:
> 
> Richard - In the example, are the two hypothetical networks operating 
> without any significant common authority (e.g. as seen by corporations 
> with distinct business units for different networks, i.e. autonomous) 
> or simply operated by different teams
> 
> If the former, then the MDN policy clearly notes "Autonomous 
> multihomed discrete networks" as an example of a compelling reason.  
> As Owen noted, the policy was designed to "to address the circumstance 
> where the allocations *cannot* (emphasis added) be aggregated and must 
> be announced separately. In the past, ISPs in such situations either 
> could not obtain additional space or had to resort to asserting 
> multiple maintainer organizations.

Hi John,

A few points here:

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.


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. This is 
precisely what you're asking them to do (even though no such requirement 
exissts in the policy), and it is JUST as easy for any network or any 
organizational structure to accomplish.

More specific prefixes do not care about organizational structure. As 
long as they will be accepted by everyone else on the Internet (which 
today is true of almost everything down to a /24 level), this is a 
perfectly viable solution for ANY network.


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


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! The 3 examples of "compelling 
reasons" are actually just 3 examples where the network cannot 
(reasonably) aggregate their announcements. The MDN policy then steps in 
to provide assistance at giving them allocations which *CAN* be 
announced as an aggregate, so they aren't forced to deaggregate as a way 
to work around the problem. You've just described exactly what I'm 
talking about re: the MDN policy being linked to aggregation.


> 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. You're adding a piece of logic that doesn't exist in 
the policy today, "that there is no other possible way to solve the 
problem", and using that to exclude networks who otherwise demonstrate 
compelling reasons using the 3 perfectly reasonable examples already 
cited in the policy.

Again, by your logic you would exclude almost everyone who uses the MDN 
policy today, as rs has already stated. I'm sure you can find many other 
network operators who can help explain this point as well.

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