peeringdb: netixlan conflict resolution idea

Capturing elements of what I posted to the data ownership task force and the @peeringdb/pc since there has been support:

With respect to the REST API netixlan data (*: see below for example), I agree there is co-ownership.

I assert that if an IXP is providing an automatic export of their assignments via the IX-F JSON format, that PeeringDB should not present assignments which disagree with the IXP-provided data.

At the same, PeeringDB should only present assignments which have been affirmatively supplied by a network.

Thus, while the DATABASE netixlan table is supplied by the network users, the web site presentation, at least as far as the IXP web pages, and REST API netixlan results should only present data that represents the mutual agreement of the IX-F JSON data and the DATABASE netixlan data.

The current IX-F JSON importer is designed to run from a cron task. Keeping in mind it is currently disabled, as part of what precipitated this task force, when it runs it does the following:

• fills in data for those networks that have opted to have automatic updates.

• removes data supplied by networks which is in conflict.

I believe the importer needs to perform an additional task:

• populate/update a new database table, potentially known as netixlan_ixp, which represents the IXP viewpoint.

and once that is implemented, it can cease removing conflicted assignments unless a network has opted for IX-F JSON automatic updates.

The netixlan_ixp aspect of the importer needs to run frequently, such as once per hour.

Then, for IXPs that have a populated database netixlan_ixp table, the web site IXP pages and REST API netixlan and “peeringdb sync” peeringdb_ixlan table may only present IP assignments that exist in BOTH the netixlan_ixp and netixlan tables.

In this proposal, web site network pages will continue to show netixlan data which is not public in the other views, with an indicator to the viewer that the data is preliminary or not yet sanctioned.

Issue #585 could then be adjusted to only generate tickets for conflicts that are older than a certain amount of time, ideally exceeding the amount of time a conflict may exist as part of normal IXP/network provisioning.

*: So we are all clear on what REST API netixlan is, from my example:

• netixlan: Network’s IP assignment at an IXP
  • Ex: https://www.peeringdb.com/api/netixlan/1534

the result is below, in paraphrased form.

{
  "meta": {},
  "data": [
    {
      "id": 1534,
      "net_id": 416,
      "net": { [...] },
      "ix_id": 13,
      "name": "SIX Seattle: MTU 1500",
      "ixlan_id": 13,
      "ixlan": { [...] },
      "notes": "",
      "speed": 20000,
      "asn": 6456,
      "ipaddr4": "206.81.80.10",
      "ipaddr6": "2001:504:16::1938",
      "is_rs_peer": true,
      "created": "2010-07-29T00:00:00Z",
      "updated": "2019-03-02T03:15:13Z",
      "status": "ok"
    }
  ]
}

Also, from my example:

• ixlan: Join of ix and netixlan, listing networks at IXP
  • Ex: https://www.peeringdb.com/api/ixlan/13

in paraphrased form:

{
  "meta": {},
  "data": [
    {
      "id": 13,
      "ix_id": 13,
      "ix": { [...] },
      "name": "MTU 1500",
      "descr": "",
      "mtu": 1500,
      "dot1q_support": false,
      "rs_asn": 0,
      "arp_sponge": null,
      "net_set": [ FULL LIST OF PARTICIPANTS FROM WHICH IPs CAN BE DERIVED ],
      "ixpfx_set": [ ... ],
      "created": "2010-07-29T00:00:00Z",
      "updated": "2019-05-08T03:57:10Z",
      "status": "ok"
    }
  ]
}