[address-policy-wg] IXP pool lower boundary of assignments

* Radu-Adrian FEURDEAN

> On Mon, Nov 7, 2022, at 13:00, Tore Anderson wrote:
> > Actually, I do have some real-life experience here as I/AS39029 was
> > part of the NIX renumbering process back in 2017. The whole
> > operation was rather straight-forward and went very smoothly. NIX
> > staff simply informed all members of their new IPs by e-mail and
> > told to migrate within a certain date (different dates for NIX1 and
> > NIX2).
> 
> Well, this seems to be the customer-side experience, not the IXP-
> side.
> Also, what I can see is that responsiveness of NOCs and peering teams
> of members is only getting worse with time.
> At France-IX, just changing a netmask (from /23 to /22) - because we
> have the biggest 3 out of 5 IXPs numbered from PA space - took just
> under 2 years to complete (23 months to be precise). More than 80%
> did the change in less than 3 months, but after 12 months we still
> had a few members that didn't change their config.
> OK, things end up in a slightly more violent manner with renumbering,
> but you sill end up with "zombie members", not all of them being
> small players.

First off, note current policy already requires renumbering if your IXP
grows out of a /23 and into a /22.

Second, current policy already contains a hard deadline of 180 days of
complete this renumbering process and return the old prefix.

Of course, neither the IX nor the RIPE NCC has the power to log into
the router of a «zombie member» and forcibly remove the old IP address
from the «zombie»'s router. But one cannot (well, should not!) allow
unresponsive «zombie» members to block the completion of the project.

So in the case of NIX, a deadline was clearly communicated ahead of
time and that was the end of the story. Perhaps there were «zombies»
that did not act within the deadline back then too, I can't recall, but
if so they just got left behind at the platform (peering only amongst
themselves using old addresses) while the train with all the «non-
zombies» left the station. Such is life. (Hopefully a majority of their
peering sessions dropping brought them back to life, but who knows.)

> /29 is way too small. It's 6 members, and that supposes that you
> don't have route-servers or any other internal stuff on the peering
> LAN. Getting from /29 to /25 that's 4 renumberings, and that may well
> happen within 2 years. You end up being labelled as "unstable" (read
> "junk" or "toy" IXP). 3 renumberings to get to /26.

There would not be a requirement for four renumberings within two
years, no. Policy states that: «After one year, utilisation of the new
assignment must be at least 50%». In other words, a growing IX would
need to renumber exactly ONCE within the first two years.

So your example IX above would be eligible to receive an initial /26,
and would be eligible to receive a /25 replacement one year prior to
its expected utilisation reaching 64 addresses.

It would make zero difference whatsoever to your example whether the
default assignment size was set at /29 or /26 or anywhere in between.

> > NIX is (and was) a mid-sized IX, currently around 60 participants.
> > Based on that experience I have honestly a very hard time believing
> > that renumbering a small IX is «much more difficult [than renumbering
> > a] data centre or an access provider».
> 
> Convincing different distinct parties to do something within a
> specific timeframe is always difficult. Especially when you have to
> deal with big companies. 
> Pushing things too hard will only get you losing members.....

Well, the RIPE community has clearly laid down a renumbering deadline
of 180 days as a condition for getting free prefixes from the IXP pool,
this is already in the policy.

If the operator of a new IX finds that adhering to this policy is
«pushing things too hard», then perhaps it would be better if it got
itself a vastly oversized prefix from somewhere else instead of from
the RIPE NCC. That way, it can forever avoid having to renumber.

> ... or getting rid of v4 entirely, which seems to be on nobody's
> agenda ...

Agreed. For what it is worth, we have for years advertised IPv4
prefixes across IPv6 BGP sessions in our internal networks. It works
very well for us, so I see no real reason why it couldn't work on IXPs
as well – assuming universal vendor support. I suppose that is the
problem…

Tore