[PDB Data Ownership-TF] IXP IP address assignment race condition and a possible solution

[Chris Caputo]

First, I'd like to apologize for using actual organization names during 
the meeting, especially since it is not critical to the issue discussed.  
I hope my words did not come across as disparaging, since they were not 
meant to.  Both are very fine organizations.  :-)

Upon examination, the particular issue would not have been helped by 
careful ordering/procedure, because unless the IX-F JSON export data is 
updated first and the IXP has knowledge of when PeeringDB has pulled and 
made use of the data, there will generally be a race condition between the 
IP address assignment by an IXP and the currency of the IX-F JSON export 
data present in PeeringDB.

Thus I believe this race condition should be accepted as being normal, and 
we need to expect it and design for it accordingly.

Like many, I agree that an IXP owns its address space and is the ultimate 
arbiter regarding it.  Thus I propose...

In cases where IX-F JSON export data is provided by an IXP and a 
particular network has set Allow_IXP_Update==no:

  - the conflicted data be indicated as such on the network's /net/ page, 
    possibly with an asterisk or color indicating it isn't in agreement 
    with the IXP.  A legend for the asterisk or color could indicate that 
    the data may become accurate over time or may simply be inaccurate.  
    If over time, such as a future IX-F JSON import, the data becomes 
    correct, then the indication would change toward affirmative or 
    neutral depending on the UI design.  Further, if decided appropriate 
    such as by ProductComm, there could be automatic emails to the network 
    explaining any conflict, and additional email explaining if and when a 
    conflict is automatically resolved.

In cases where IX-F JSON export data is provided by an IXP and regardless 
of Allow_IXP_Update setting of a given network:

  - conflicted data would not be present in an /ix/ page, thus maintaining 
    the authority of the IXP

  - conflicted data would not be present in data queried by the API (for 
    example: https://www.peeringdb.com/api/ixlan/13), thus maintaining the 
    authority of the IXP and preventing usability by provisioning systems 
    until the IXP confirms data requested by the network (either in the 
    form of manual entry by the network or Allow_IXP_Update==yes)

The above enables the IXP to remain authoritative (should they choose to 
be by providing IX-F JSON export) while enabling networks that manage 
their own data (Allow_IXP_Update==no) to enter data into PeeringDB at 
their convenience without it being erased.

The IX-F JSON importer, when it ran, was running once per day.  If there 
are concerns about delays in allowing provisioning systems to make use of 
updated data, the importer could be made to run more frequently.

Thoughts?

Chris