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

Fri Jan 24 10:18:01 PST 2020

Hi Chris,

Thanks for all the input!  I now think I am being very thick here.

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.

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.

Thanks

  -Bill

On Fri, Jan 24, 2020 at 12:25 PM Chris Caputo <ccaputo at alt.net> wrote:

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

-- 
*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/d8832438/attachment-0001.htm>