Nice work Ron

Matthew Petach mpetach at netflight.com
Sat Jan 23 16:25:40 UTC 2021


On Sat, Jan 23, 2021 at 1:11 AM JORDI PALET MARTINEZ via NANOG <
nanog at nanog.org> wrote:

> When you sign a contract with a RIR (whatever RIR), is always 2 parties,
> so majority of resources operated in the region (so to have the complete
> context) clearly means that you are using in the region >50% of the
> provided IPs.


No.

If you operate a global backbone on six continents,
and obtain a block of addresses to use for building
that backbone, you can easily end up in a situation
where there is no continent with >50% utilization of
resources; it can easily end up with the space being
split 10%, 10%, 20%, 25%, 35%.  Every time I have
gone to an RIR for resources, and have described the
need, explaining that the largest percentage of the
addresses will be used within the primary region
has been sufficient.  No RIR has stated that a global
backbone buildout can only be built in a region if > 50%
of the addresses used on that backbone reside within
their region.  Otherwise, you end up at a stalemate
with no RIR able to allocate addresses for your backbone
in good faith, because no region holds more than 50% of
the planet's regions.

"Mainly" has been interpreted to be "the largest percentage"
every time I have requested space.

If RIRs start to put a >50% requirement in place, you're
going to see global backbone providers put into the awkward
position of having to lie about their buildout plans--so they're
going to consistently vote against language that explicitly says
">50%" just so that nobody is put into the position of having to
knowingly lie on an attestation.

I understand where you're coming from; but as someone who
has built global infrastructure in the past, I think it would be
good to consider the view from the other side of the table,
and realize why the language is kept a bit more loose, to
allow for the creation of infrastructure that spans multiple
regions.

Thanks!

Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20210123/d3e617fa/attachment.html>


More information about the NANOG mailing list