[arin-ppml] ARIN-2024-5 Rewrite of NRPM Section 4.4 Micro-Allocation - Community Questions

[Martin Hannigan]

On Wed, Feb 26, 2025 at 5:01 PM William Herrin <bill at herrin.us> wrote:

> On Wed, Feb 26, 2025 at 1:50 PM Martin Hannigan <hannigan at gmail.com>
> wrote:
> > IXP Utilization (which has nothing to do with "routing")
> >
> > What exactly is the question staff utilization analysis wise? Not in the
> experience report and not in the policy review. In fact, there is no policy
> review yet.
>
> Howdy,
>

Good afternoon, William;


>
> The main question here is: if the applicant requests more than a /24,
> how should ARIN determine whether the request is justified? The draft
> lays out qualification for a /24 but is mute on qualification for more
> than a /24.
>
>
It's not mute, it doesn't set a limit. And neither does the policy:

The proposal says this: Assignments from this pool will be no smaller than
a /24.
The policy says this: These allocations will be no smaller than a /24.
Multiple allocations may be granted in certain situations.

The data shows ARIN has been doing just fine figuring out how to analyze
use.

If someone meant to ask something else it should've been spelled out more
clearly. Such as: everyone knows ARIN has handed out 2 x /24 for some IXP
requests. If a request says I'm asking for 2 x /24 for a peering lan and
will use a /24 for ops infrastructure and they have been saying yes, keep
saying yes. There's no design question. And we defined IXP as CI (we have a
policy).

However, yes, I can see if you have a /24 for ops and only used /27 and
then you need another peering lan /24 the utilization is going to be off if
the ops /24 is included in the analysis. Perhaps the operational /24 is
important enough resiliency wise but is a one time opportunity if asked and
doesn't count towards peering fabric utilization? Still has to meet 80%
AFAIK.

Thanks, HTH

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