[arin-ppml] ARIN Multiple Discrete Networks Policy

[Martin Hannigan]

On Thu, Sep 29, 2011 at 5:10 PM, Richard A Steenbergen <ras at e-gerbil.net>wrote:

> 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. :)
>
>
All that you are required to maintain across the board on MDN is 50%
utilization and non-assignment below 80%. Not sure how anyone can be
required to move addresses around if they meet the thresholds. I'm sure our
policy technicians will clear that one up. It certainly does sound like a
misapplication of the rules.

This is a fairly interesting issue with a large portion of ARINs policies.
They are vague and unpredictable. Sometimes so much so that they can be
interpreted in a variety of ways that are generally inconsistent. This is
bad for the organization and bad for its stakeholders.

Best,

-M<
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110929/ac59c075/attachment.htm>