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

[William Marantz]

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?  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.
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 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.

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-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/20200124/db9ddfb6/attachment-0001.htm>