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

Fri Jan 24 15:04:11 PST 2020

I defer #585 questions to Arnold :-) , but I think you are on the right 
track with:

  https://docs.google.com/spreadsheets/d/1GJ-TdK5B3LfBpYT-wDwNv86_HKZpi5wy5qY4Gipsvno

One of my intentions with #627 is to minimize the need for the processes 
described in #585 by automating resolution of conflicts that will happen 
during normal provisioning.  Ie., in most cases there should not be a need 
to escalate to the processes of #585 involving the Admin Committee.

Thanks,
Chris

On Fri, 24 Jan 2020, Terry Sweetser wrote:
> 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
> 
> > Mobile/WhatsApp: +61455067119
> 
> >
> 
> >
> 
> >
> 
> > -----Original Message-----
> 
> > From: DataOwnership-TF <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>
> 
> > Cc: DTF PeeringDB <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> 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-t
> 
> > > f
> 
> > >
> 
> > >
> 
> > > --
> 
> > > DataOwnership-TF mailing list
> 
> > > 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
> 
> > >
> 
> > >
> 
> > >
> 
> > --
> 
> > DataOwnership-TF mailing list
> 
> > DataOwnership-TF at lists.peeringdb.com
> 
> > https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf
> 
> >
> 
> 
> 