[PDB Data Ownership-TF] IXP assignment IP address (netixlan) ownership

[Chris Caputo]

On Mon, 27 Jan 2020, Arnold Nipper wrote:
> On 25.01.2020 15:41, Chris Caputo wrote:
> > On Sat, 25 Jan 2020, Arnold Nipper wrote:
> >> Chris/team
> >>
> >> On 25.01.2020 02:30, Chris Caputo wrote:
> >>
> >>> On 25.01.2020 01:31, Arnold Nipper wrote:
> >>>
> >>>> Again: if there is a conflict, data *must* stay intact and conflict
> >>>> resolution has to happen asap with all parties involved.
> >>>
> >>> Network-provided data stays intact in the netixlan table, but it is 
> >>> disputable (hence this discussion) that it should be public in such as way 
> >>> as to inform provisioning.  I believe the IXP should have the option of 
> >>> having a say in that matter, since it is their address space, and their 
> >>> fabric which can be affected.
> >>>
> >>
> >> IMO we are running in circles somehow.
> >>
> >> We want to have the IX-F importer, but also want to make it safe in the
> >> sense that data is not deleted/gets invisible in case of an error on
> >> either side.
> >>
> >> As we are not able to resolve a conflict automatically w/o causing
> >> interruption of services, the conflict has to be brought to attention
> >> immediately by notifying each party involved and then get resolved.
> >>
> >> AC will do this resolution. And I fully agree that the IXP should be the
> >> authoritative source of information regarding (asn, ipv4, ipv6).
> >>
> >> If there is anything we can do to minimize the work of AC w/o violating
> >> above mentioned principles we should implement it.
> > 
> > Hi Arnold,
> > 
> > Maybe the way to reach consensus here is to revise part of #627's initial 
> > proposal:
> > 
> >   - "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."
> > 
> > to rather be:
> > 
> >   - "At the same time as #627 (netixlan conflict resolution idea)  
> >     withholds general API and /ix/ HTML page publication of conflicted 
> >     data to avoid premature and/or accidental provisioning, and produces a 
> >     conflict notification on the Network's /net/ HTML page, the resolution 
> >     methods of #585 (Interim IX-F JSON importer) are also triggered.  
> >     This enables the Admin Committee to exercise discretion and/or brings 
> >     parties together toward agreement, resulting in either a correction or 
> >     override of the IX-F JSON export from the IXP and/or a change in the 
> >     data provided by the Network, as needed to aide in resolution of the 
> >     conflict.  To facilitate an override, a netixlan_override table is 
> >     envisioned, to accompany the netixlan table and new netixlan_ixp 
> >     table.  The Admin Committee also has the discretion to disable the 
> >     IXP's IX-F JSON import if it is apparent new data is in error, thus 
> >     minimizing the duration of accidental censoring of valid data."
> > 
> > ?  Does that work for you?
> > 
> > Then after implementation and experience is gained, if the trigger delay 
> > for invoking #585 turns out to be too low at zero seconds, it could be 
> > increased over time, such as to an hour or more, if it makes sense to do 
> > so in the judgment of the Admin Committee.
> > 
> 
> Given the situation that the IX-F import erroneously did not contain
> information for ASN 64512, but ASN 64512 has a valid PDB entry. My
> understanding is that your proposed solution would then immediately
> withhold netixlan information for this ASN and this IX. Right? If so,
> that would be completely unacceptable.

Hi Arnold,

Yes, this is the idea, and I disagree it is unacceptable, based on the IXP 
having exerted positive control of their subnet by exporting IX-F JSON 
data.  Near the beginning of #627, I wrote:

  - "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."

Per #627, when an IX-F JSON export exists for a given IXP, ASN 64512's 
entry of an IP assignment for that IXP would not be visible to the public 
until such time as the IX-F JSON export contains a match or the Admin 
Committee facilitates a resolution via an override of the IXP export, such 
as because they believe there is an error in the IXP IX-F JSON export.

Assuming accurate data, the amount of time for the disparity would likely 
be less than an hour, given the proposal's once-per-hour IX-F JSON update 
frequency.  Further, it should be possible to implement a secure 
push-to-trigger-pull mechanism from the IXP toward PeeringDB, if better 
timeliness is desired.

PeeringDB has a fundamental concept that no data get added to an entity's 
page, without permission.  I believe that includes the IXP's page when the 
IXP makes explicit their assignments via IX-F JSON export, and in the case 
of a Network adding an assignment that the IXP does not agree with, this 
concept is presently being violated on the IXP's PeeringDB page.

A core question for the task force: Does an IXP exporting IX-F JSON data 
have the right to prevent a network from publishing an assignment on the 
IXP's subnet?

I wrote #627 because I believe that right is a given, but apparently you 
disagree?  What do others believe?

Thanks,
Chris