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

Fri Jan 24 14:49:44 PST 2020

Thanks Chris,

So, for my own sense-making:

Situation
allow_ixp_update: no
allow_ixp_update: yes
Data disagrees (asn, ipaddr4, ipaddr6: 1 or more mismatches.)
Manual intervention via DeskPro ticket.
IXF Importer will update data.
Data disagrees (Other items)
"Do Nothing"
IXF Importer will update data.
Data agrees (asn, ipaddr4, ipaddr6: all match.)
"Do Nothing"
"Do Nothing"
No Data Present in PDB
"Do Nothing"
Manual intervention via DeskPro ticket.

To me, this seems very fair: allow the parties to be notified that data is misaligned.

I would also say that the lower right corner, has a “new network” contingency where that network is not on PDB and needs to start the journey to create records.

https://github.com/peeringdb/peeringdb/issues/585#issuecomment-549667200 😊

Regards,

Terry Sweetser

General Manager, IX Australia

Terry.Sweetser at ix.asn.au

Mobile/WhatsApp: +61455067119

-----Original Message-----
From: Chris Caputo <ccaputo at alt.net>
Sent: Saturday, 25 January 2020 8:28 AM
To: Terry Sweetser <Terry.Sweetser at ix.asn.au>
Cc: DTF PeeringDB <dataownership-tf at lists.peeringdb.com>
Subject: Re: [PDB Data Ownership-TF] IXP assignment IP address (netixlan) ownership

Hey Terry,

In https://github.com/peeringdb/peeringdb/issues/627 the Network will see details of a conflict on their /net/ HTML page and may choose to act based on that, or may choose to wait for the related IX-F JSON export data to match up.

If some TBD (30?  AdminCom discretion based on workload?) days pass without resolution, the harmony mechanisms described in

https://github.com/peeringdb/peeringdb/issues/585 can be engaged,

specifically:

  - If a network has an IXP entry with differing (asn, ipaddr4, ipaddr6),

    an email is sent to the ix operator, the net owner and the Admin

    committee.

Thanks,

Chris

On Fri, 24 Jan 2020, Terry Sweetser wrote:

> Hi Chris,

>

> The hourly JSON import intrigues me!  It would mean data convergence becomes less of an issue when all data is aligned.

> Convergence is dealt with easily.  Data alignment continues to a central problem.

> How does one get 2 parties to agree when they're putting different data into the same schema?

>

> Regards,

> Terry Sweetser

> General Manager, IX Australia

> Terry.Sweetser at ix.asn.au<mailto:Terry.Sweetser at ix.asn.au>

> Mobile/WhatsApp: +61455067119

>

>

>

> -----Original Message-----

> From: DataOwnership-TF <dataownership-tf-bounces at lists.peeringdb.com<mailto:dataownership-tf-bounces at lists.peeringdb.com>>

> On Behalf Of Chris Caputo

> Sent: Saturday, 25 January 2020 3:26 AM

> To: William Marantz <wmarantz at salesforce.com<mailto:wmarantz at salesforce.com>>

> Cc: DTF PeeringDB <dataownership-tf at lists.peeringdb.com<mailto:dataownership-tf at lists.peeringdb.com>>

> Subject: Re: [PDB Data Ownership-TF] IXP assignment IP address

> (netixlan) ownership

>

> 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<mailto: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<mailto:ccaputo at alt.net>>

> >       Reply-To: Chris Caputo <ccaputo-dated-1588965493.0ca23d at alt.net<mailto:ccaputo-dated-1588965493.0ca23d at alt.net>>

> >       To: DTF PeeringDB <dataownership-tf at lists.peeringdb.com<mailto: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<mailto:DataOwnership-TF at lists.peeringdb.com>

> >

> > https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-t

> > f

> >

> >

> > --

> > DataOwnership-TF mailing list

> > DataOwnership-TF at lists.peeringdb.com<mailto:DataOwnership-TF at lists.peeringdb.com>

> > https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-t

> > f

> >

> >

> >

> > --

> > Bill Marantz

> > Principal Network Engineer

> > Backbone Engineering

> > Mobile: 848-404-4613email: wmarantz at salesforce.com<mailto:wmarantz at salesforce.com>

> >

> >

> >

> --

> DataOwnership-TF mailing list

> DataOwnership-TF at lists.peeringdb.com<mailto:DataOwnership-TF at lists.peeringdb.com>

> https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.peeringdb.com/pipermail/dataownership-tf/attachments/20200124/f3fa7ee0/attachment-0001.htm>