[PDB Data Ownership-TF] IXP assignment IP address (netixlan) ownership
ccaputo at alt.net
Mon Jan 27 08:42:33 PST 2020
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.
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
I wrote #627 because I believe that right is a given, but apparently you
disagree? What do others believe?
More information about the DataOwnership-TF