[PDB Tech] IX-F JSON to PeeringDB importer (temporarily) disabled

[Lukas Tribus]

Hello Job,


[ resending email from gmail, because "Client host rejected: 554 SPAM
not tolerated here (Mailgun)" ]

On Fri, 30 Aug 2019 at 17:30, Job Snijders <job at instituut.net> wrote:
> A significant challenge here is that sometimes records in PeeringDB
> are out of date (which hinders new IXP participants), and sometimes
> IX-F data doesn't (yet) contain information or this information is
> out-of-date (either case hinders a different group). I think the path
> forward is to express the relations and automated actions between the
> information sources as a state machine which (unlike the current
> version) does account for the full lifecycle from provisioning to
> decommissioning of circuits to IXPs.

A state machine handling the full life-cycle seems overly complex,
with lots of moving parts. I fear that would also result in a number
of disputes that is similarly unsatisfactory. I mean, you don't really
know how the IX constructs this data - a ASN may be removed from that
list for a short period of time to due to a temporary payment issue.
In fact it looks like the disputes are mainly caused by
bad/imprecise/outdated information from IXes, so building more
complexity around it seems like a bad idea to me.

I would opt for simpler, more predictable fixes.

Why not limit the IX-F overwrite to cases where there is an actual ASN
mismatch between PDB and IXF? Or in other words: don't delete
addresses in PDB when the data is simply missing in the IXF data?
Sure, obsolete IP addresses won't get cleaned up immediately. But they
would get cleaned up when it matters (when the IP is reassigned),
without the false-positives we have today.

We can still notify ASN's about the fact that an IP address is no
longer in IXF (once a month or so), to spur the cleanup of obsolete
addresses.

I didn't read through all the github issues, so maybe what I am saying
doesn't tick all the boxes, but my strong opinion about this is: KISS.

If we really NEED peeringdb to be always uptodate without obsolete IP
addresses for IXF enabled IXP's, there is only 1 choice: an IXP
providing IXF data needs to be 100% authoritative of the data, in 100%
of the cases. An operator should not even be able to add addresses for
IXF-enabled IXP's. I'd vote against this approach, but it I think this
would still be better than a state machine handling billing disputes.


Complex processes (and changes thereof) at PDB make it harder for
network operators (and IX'es) to comprehend what happens. Even though
I'd like operators to read pdb-announce and understand PDB processes,
the reality is that PDB needs to be self-explanatory and as
predictable as possible for a large number of operators and IX'es,
small, big and huge.

I can also see that there is confusion about the "Allow IXP updates"
flag. I can understand that, it's easy to interpret this as "nobody is
gonna change my data unless flagged", so people are surprised when
their data changes. We can make this clearer. "Allow manual IXP
updates (automation may remove IP addresses assigned to different
ASNs)" or something like this (if true, of course).



KISSes,

Lukas