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