[arin-ppml] ARIN Multiple Discrete Networks Policy
Richard A Steenbergen
ras at e-gerbil.net
Thu Sep 29 17:10:48 EDT 2011
On Thu, Sep 29, 2011 at 01:30:58PM -0700, Owen DeLong wrote:
> As one involved in the authorship of said policy, permit me to clarify?
> The actual intent of the policy is not related to aggregation, but, is
> so that, for example, an entity that ran multiple content source data
> centers that grew at different paces and operated independently from
> each other without necessarily having (adequate) bandwidth connecting
> those data centers could get separate allocations for each datacenter
> that allowed them to get additional space for the one that was at 80%
> while the others might still be nowhere near "efficient utilization".
> Specifically, this is designed to address the circumstance where the
> allocations cannot be aggregated and must be announced separately.
I understand the point of the policy, and agree with it completely, but
that isn't the issue.
Lets consider your specific example, 2 discrete networks which operate
independantly from each other, where one grows at a faster pace than the
other and needs more IPs before the aggregate utilization of both
networks would otherwise provide justification. ARIN is essentially
saying that if you "CAN" solve this problem by "stealing" space from
discrete network #1 and announcing it via discrete network #2, even if
this means flooding the Internet with a bunch of deaggregates in the
process, then you don't "NEED" the policy and therefore don't qualify.
My point is that almost every network "CAN" do this today, but that
doesn't mean that they SHOULD. :)
What you're citing above (re: discrete networks which grow at a
different rate) is actually an example of where the MDN policy makes
sense, rather than the reason for it. The actual REASON for the MDN
policy is so that these two discrete networks can receive two distinct
allocations, rather than be forced to deaggregate their single
allocation for use across both networks to hit the 80% aggregate
requirement. Thus, aggregation is actually the real motivating factor
behind the entire thing. :)
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