[arin-ppml] ARIN Multiple Discrete Networks Policy
Richard A Steenbergen
ras at e-gerbil.net
Fri Sep 30 17:58:33 EDT 2011
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.
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
* 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)
More information about the ARIN-PPML