[PDB Data Ownership-TF] IXP assignment IP address (netixlan) ownership (was: conditions for being listed in a facility)

[Chris Caputo]

On Thu, 9 Jan 2020, Arnold Nipper wrote:
> On 09.01.2020 05:03, Christopher Malayter wrote:
> >> On Jan 8, 2020, at 11:00 PM, Chris Caputo <ccaputo at alt.net> wrote:
> >> On Wed, 8 Jan 2020, Chris Caputo wrote:
> >>> On Wed, 8 Jan 2020, Arnold Nipper wrote:
> >>>> On 08.01.2020 19:06, Chris Caputo wrote:
> >>>>> Dear All:
> >>>>>
> >>>>> The fundamental conflict which spawned this effort is the 
> >>>>> differing perspectives of an IXP and a network with respect to IP 
> >>>>> assignment at an IXP and whether or how to present or how to 
> >>>>> handle the differing data.
> >>>>
> >>>> More precisely, the conflict arose from auto-removal of netixlan 
> >>>> records and not notifying the networks when doing so.
> >>>>
> >>>>> Is there any reason not to try to first solve that (IMHO most 
> >>>>> significant) question?
> >>>>
> >>>> #539 [0] and #585 [1] both address this question.
> >>>>
> >>>> * #539 proposes an additional boolean field `operational`. Esp. larger
> >>>> networks want to announce their presence at IXPs well in advance, even
> >>>> if they are not operational.
> >>>>
> >>>> * #585 copes with cases where the old IX-F importer would delete
> >>>> netixlan records. Now a support ticket with all parties involved is
> >>>> opened to resolve the conflict.
> >>>>
> >>>> IMO It definitely would help if the TF comes up with a recommendation
> >>>> who is the (trusted) source of information for IP addresses.
> >>>
> >>> I believe the IXP responsible for a subnet is the trusted source of 
> >>> information for IP address assignments on a subnet.
> >>>
> >>> Does anyone disagree?
> >>
> >> Or better yet, to make sure, do others agree?  Maybe we are unanimous in 
> >> that belief...
> > 
> > I agree that the IXP responsible for a subnet should be the trusted
> > source and owner for that object.
> 
> While I agree that the IXP responsible for a subnet should be the
> trusted source, I disagree that the IXP also is the owner of the object
> netixlan. For netixlan we have co-ownership between IXP and net.

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.

Chris

*: 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"
    }
  ]
}