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

[William Marantz]

I believe IXPs own the data presented on their IXP page as they control the
IP space.  Networks own their data unless they delegate to the IXP.

In the case of a disagreement: restricting API visibility, notifying the
network, and marking the network web page as a conflict seem reasonable
steps to encourage quick agreement.

Thanks

  -Bill

On Mon, Jan 27, 2020 at 11:42 AM Chris Caputo <ccaputo at alt.net> wrote:

> 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
> --
> DataOwnership-TF mailing list
> DataOwnership-TF at lists.peeringdb.com
> https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf
>


-- 
*Bill Marantz*
Principal Network Engineer
Backbone Engineering
Mobile: 848-404-4613
email: wmarantz at salesforce.com <ihamilton at salesforce.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.peeringdb.com/pipermail/dataownership-tf/attachments/20200127/8167706c/attachment-0001.htm>