<div dir="ltr">Hi Chris,<div><br></div><div>Thanks for all the input! I now think I am being very thick here. </div><div><br></div><div>Are the users with issues synching a copy of peeringDB locally for use in their provisioning process? If so, I understand now how this proposal helps them ( as the data they rely on for their own IP interface configs still exists in the DB ) and I totally missed a very important detail due to my API/web focus. </div><div><br></div><div>I don't see how it helps operators who rely on API calls ( of potentially conflicted data ) for automation in an attempt to jump start slow internal provisioning intervals, but I can live with it as the taskforce is here to define data ownership and in the process prevent data quality features like IX-F import from breaking some folks.</div><div><br></div><div>Thanks</div><div><br></div><div> -Bill</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 24, 2020 at 12:25 PM 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">Hi Bill,<br>
<br>
On Fri, 24 Jan 2020, William Marantz wrote:<br>
> I was engaged in a side conversation with Chris on this proposal to <br>
> clarify some things and would like to bring the discussion to the list.<br>
> I'm going to wear two different hats when looking at this proposal.<br>
> <br>
> 1) From a data ownership perspective I like this proposal as it won't <br>
> lead to full deletion of end user network specified IP data but will <br>
> limit its visibility to others and indicate the IX-F conflict to the <br>
> network.<br>
> <br>
> 2) From a poor coder and automated peering operator perspective I have <br>
> some concerns with it depending on how the folks with reported issues <br>
> use the API.<br>
><br>
> a) does anyone know the access method and tables/objects the users who <br>
> had data deletion issues used?<br>
<br>
I'm not sure, but it is important the solution be useful regardless of how <br>
data is submitted. fkorsback raised the flag about the original issue, <br>
resulting in the IX-F JSON importer being disabled, and he has expressed <br>
support for #627.<br>
<br>
> If they are getting netixlan via the API the conflicted IP data won't be <br>
> there in this proposal. If they call a net object will the data be <br>
> viewable in the netixlan_set data element in your proposal Chris? I'd <br>
> assume yes if it will be available via the net web page. If the user is <br>
> using netixlan calls as part of their provisioning process, I don't see <br>
> how this proposal solves the problem. I'd suggest to clearly document <br>
> the potentially conflicted view ( net ) and conflict free view ( <br>
> netixlan ). Users can then code to whatever view meets the needs of <br>
> their network.<br>
<br>
No, it won't be visible in the /net/ result or other results as long as it <br>
is conflicted. The idea here is to prevent PeeringDB from presenting (via <br>
web or API) any data that could be interpreted as valid when it is not <br>
valid. Conflicted data is not valid. While that conflict can be denoted <br>
in the web pages, so a network has a clue that an issue has arisen, for <br>
API queries conflicted data would be withheld to prevent accidental <br>
automation using conflicted data.<br>
<br>
For API developers the lack of consistency between a GET after a PUT/POST <br>
is the way a conflict is indicated.<br>
<br>
I've added the above to the issue on GitHub.<br>
<br>
> b) Some networks are very slow at peer provisioning and IX port <br>
> provisioning, so peers may have a strong desire to get provisioning <br>
> started as soon as the IXP assigns the IPs but that may not yet be <br>
> reflected in IX-F. This means a provisioning system would rely on the <br>
> conflicting data if that system is built to only obtain IPs from <br>
> peeringDB. As long as the caveats are documented, I'd like to support <br>
> such functionality as I feel it would aid many operators.<br>
<br>
The idea with the proposal is that if an IXP is regularly (ex. within last <br>
30 days) providing IX-F JSON data, the IXP is asserting authority over <br>
their address space, which is their right to do. Thus conflicted data <br>
will not be allowed to be presented. I've recommended in the proposal <br>
that PeeringDB pull the IX-F JSON updates hourly to minimize the conflict <br>
period for soon-to-be-valid data. Further, it is expected that IX-F JSON <br>
data be kept current by the IXP such that any assignments go into their <br>
IX-F JSON export when the IXP port for the network is in production (or <br>
earlier, depending on their local policy).<br>
<br>
> The provisioning code I wrote makes API calls to get netixlan but I'm <br>
> happy to change it to make net calls if this proposal goes through.<br>
<br>
I don't think you will need to change any code for this proposal, except <br>
possibly code which performs PUT/POST updates. But even if PUT/POST code <br>
is unmodified and continues to periodically PUT/POST conflicted data, <br>
since it is not showing up in a subsequent GET, that is okay.<br>
<br>
Thanks,<br>
Chris<br>
<br>
> Best Regards<br>
> <br>
> -Bill<br>
> <br>
> <br>
> On Fri, Jan 24, 2020 at 9:25 AM Filiz Yilmaz <<a href="mailto:filiz@peeringdb.com" target="_blank">filiz@peeringdb.com</a>> wrote:<br>
> <br>
> Dear all,<br>
> <br>
> Bringing this to your attention again: <br>
> <br>
> <a href="https://github.com/peeringdb/peeringdb/issues/627" rel="noreferrer" target="_blank">https://github.com/peeringdb/peeringdb/issues/627</a><br>
> <br>
> There seems to be support from Product Com as well as some of the TF members for it. <br>
> <br>
> Thoughts?<br>
> <br>
> Filiz<br>
> <br>
> <br>
> <br>
> ---------- Forwarded message ----------<br>
> Date: Thu, 9 Jan 2020 19:18:13 +0000 (UTC)<br>
> From: Chris Caputo <<a href="mailto:ccaputo@alt.net" target="_blank">ccaputo@alt.net</a>><br>
> Reply-To: Chris Caputo <<a href="mailto:ccaputo-dated-1588965493.0ca23d@alt.net" target="_blank">ccaputo-dated-1588965493.0ca23d@alt.net</a>><br>
> To: DTF PeeringDB <<a href="mailto:dataownership-tf@lists.peeringdb.com" target="_blank">dataownership-tf@lists.peeringdb.com</a>><br>
> Subject: Re: [PDB Data Ownership-TF] IXP assignment IP address (netixlan)<br>
> ownership (was: conditions for being listed in a facility)<br>
> <br>
> On Thu, 9 Jan 2020, Arnold Nipper wrote:<br>
> On 09.01.2020 19:02, Chris Caputo wrote:<br>
> I believe the importer needs to perform an additional task:<br>
> <br>
> - populate/update a new database table, potentially known as<br>
> netixlan_ixp, which represents the IXP viewpoint.<br>
> <br>
> and once that is implemented, it can cease removing conflicted assignments<br>
> unless a network has opted for IX-F JSON automatic updates.<br>
> <br>
> <br>
> There is no reason to do so. See #585 [0] which is ready for implementation.<br>
> <br>
> [...]<br>
> [0] <a href="https://github.com/peeringdb/peeringdb/issues/585" rel="noreferrer" target="_blank">https://github.com/peeringdb/peeringdb/issues/585</a><br>
> <br>
> <br>
> Arnold, #585 has the word "Interim" in its very title. I am proposing a<br>
> longer term solution that does not put the repeated burden of resolution<br>
> of ownership issues on the Admin Committee. I shared my proposal with the<br>
> PC and got positive feedback, so I have now created an issue for it:<br>
> <br>
> <a href="https://github.com/peeringdb/peeringdb/issues/627" rel="noreferrer" target="_blank">https://github.com/peeringdb/peeringdb/issues/627</a><br>
> <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>
> <br>
> <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>
> <br>
> <br>
> <br>
> --<br>
> Bill Marantz<br>
> Principal Network Engineer<br>
> Backbone Engineering<br>
> Mobile: 848-404-4613email: <a href="mailto:wmarantz@salesforce.com" target="_blank">wmarantz@salesforce.com</a><br>
> <br>
> <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>