<div dir="ltr"><div>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.  <br></div><div><br></div><div>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.</div><div><div><br></div><div>Thanks</div><div><br></div><div>  -Bill</div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 27, 2020 at 11:42 AM Chris Caputo <<a href="mailto:ccaputo@alt.net">ccaputo@alt.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 27 Jan 2020, Arnold Nipper wrote:<br>
> On 25.01.2020 15:41, Chris Caputo wrote:<br>
> > On Sat, 25 Jan 2020, Arnold Nipper wrote:<br>
> >> Chris/team<br>
> >><br>
> >> On 25.01.2020 02:30, Chris Caputo wrote:<br>
> >><br>
> >>> On 25.01.2020 01:31, Arnold Nipper wrote:<br>
> >>><br>
> >>>> Again: if there is a conflict, data *must* stay intact and conflict<br>
> >>>> resolution has to happen asap with all parties involved.<br>
> >>><br>
> >>> Network-provided data stays intact in the netixlan table, but it is <br>
> >>> disputable (hence this discussion) that it should be public in such as way <br>
> >>> as to inform provisioning.  I believe the IXP should have the option of <br>
> >>> having a say in that matter, since it is their address space, and their <br>
> >>> fabric which can be affected.<br>
> >>><br>
> >><br>
> >> IMO we are running in circles somehow.<br>
> >><br>
> >> We want to have the IX-F importer, but also want to make it safe in the<br>
> >> sense that data is not deleted/gets invisible in case of an error on<br>
> >> either side.<br>
> >><br>
> >> As we are not able to resolve a conflict automatically w/o causing<br>
> >> interruption of services, the conflict has to be brought to attention<br>
> >> immediately by notifying each party involved and then get resolved.<br>
> >><br>
> >> AC will do this resolution. And I fully agree that the IXP should be the<br>
> >> authoritative source of information regarding (asn, ipv4, ipv6).<br>
> >><br>
> >> If there is anything we can do to minimize the work of AC w/o violating<br>
> >> above mentioned principles we should implement it.<br>
> > <br>
> > Hi Arnold,<br>
> > <br>
> > Maybe the way to reach consensus here is to revise part of #627's initial <br>
> > proposal:<br>
> > <br>
> >   - "Issue #585 could then be adjusted to only generate tickets for <br>
> >     conflicts that are older than a certain amount of time, ideally <br>
> >     exceeding the amount of time a conflict may exist as part of normal <br>
> >     IXP/network provisioning."<br>
> > <br>
> > to rather be:<br>
> > <br>
> >   - "At the same time as #627 (netixlan conflict resolution idea)  <br>
> >     withholds general API and /ix/ HTML page publication of conflicted <br>
> >     data to avoid premature and/or accidental provisioning, and produces a <br>
> >     conflict notification on the Network's /net/ HTML page, the resolution <br>
> >     methods of #585 (Interim IX-F JSON importer) are also triggered.  <br>
> >     This enables the Admin Committee to exercise discretion and/or brings <br>
> >     parties together toward agreement, resulting in either a correction or <br>
> >     override of the IX-F JSON export from the IXP and/or a change in the <br>
> >     data provided by the Network, as needed to aide in resolution of the <br>
> >     conflict.  To facilitate an override, a netixlan_override table is <br>
> >     envisioned, to accompany the netixlan table and new netixlan_ixp <br>
> >     table.  The Admin Committee also has the discretion to disable the <br>
> >     IXP's IX-F JSON import if it is apparent new data is in error, thus <br>
> >     minimizing the duration of accidental censoring of valid data."<br>
> > <br>
> > ?  Does that work for you?<br>
> > <br>
> > Then after implementation and experience is gained, if the trigger delay <br>
> > for invoking #585 turns out to be too low at zero seconds, it could be <br>
> > increased over time, such as to an hour or more, if it makes sense to do <br>
> > so in the judgment of the Admin Committee.<br>
> > <br>
> <br>
> Given the situation that the IX-F import erroneously did not contain<br>
> information for ASN 64512, but ASN 64512 has a valid PDB entry. My<br>
> understanding is that your proposed solution would then immediately<br>
> withhold netixlan information for this ASN and this IX. Right? If so,<br>
> that would be completely unacceptable.<br>
<br>
Hi Arnold,<br>
<br>
Yes, this is the idea, and I disagree it is unacceptable, based on the IXP <br>
having exerted positive control of their subnet by exporting IX-F JSON <br>
data.  Near the beginning of #627, I wrote:<br>
<br>
  - "I assert that if an IXP is providing an automatic export of their <br>
    assignments via the IX-F JSON format, that PeeringDB should not <br>
    present assignments which disagree with the IXP-provided data."<br>
<br>
Per #627, when an IX-F JSON export exists for a given IXP, ASN 64512's <br>
entry of an IP assignment for that IXP would not be visible to the public <br>
until such time as the IX-F JSON export contains a match or the Admin <br>
Committee facilitates a resolution via an override of the IXP export, such <br>
as because they believe there is an error in the IXP IX-F JSON export.<br>
<br>
Assuming accurate data, the amount of time for the disparity would likely <br>
be less than an hour, given the proposal's once-per-hour IX-F JSON update <br>
frequency.  Further, it should be possible to implement a secure <br>
push-to-trigger-pull mechanism from the IXP toward PeeringDB, if better <br>
timeliness is desired.<br>
<br>
PeeringDB has a fundamental concept that no data get added to an entity's <br>
page, without permission.  I believe that includes the IXP's page when the <br>
IXP makes explicit their assignments via IX-F JSON export, and in the case <br>
of a Network adding an assignment that the IXP does not agree with, this <br>
concept is presently being violated on the IXP's PeeringDB page.<br>
<br>
A core question for the task force: Does an IXP exporting IX-F JSON data <br>
have the right to prevent a network from publishing an assignment on the <br>
IXP's subnet?<br>
<br>
I wrote #627 because I believe that right is a given, but apparently you <br>
disagree?  What do others believe?<br>
<br>
Thanks,<br>
Chris<br>
-- <br>
DataOwnership-TF mailing list<br>
<a href="mailto:DataOwnership-TF@lists.peeringdb.com" target="_blank">DataOwnership-TF@lists.peeringdb.com</a><br>
<a href="https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf" rel="noreferrer" target="_blank">https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><b>Bill Marantz</b><br>Principal Network Engineer</div><div dir="ltr">Backbone Engineering<br>Mobile: 848-404-4613<div>email: <a href="mailto:ihamilton@salesforce.com" style="color:rgb(17,85,204)" target="_blank">wmarantz@salesforce.com</a><br></div></div></div></div></div></div><br></div></div></div></div></div>