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

[William Marantz]

I support that "already published" modification to your proposal Chris. I
totally forgot about that use case and great idea.

Best Regards

  -Bill

On Tue, Jan 28, 2020 at 2:27 AM Arnold Nipper <arnold at peeringdb.com> wrote:

> On 27.01.2020 18:37, Chris Caputo wrote:
> > On Mon, 27 Jan 2020, Arnold Nipper wrote:
> >> On 27.01.2020 17:42, Chris Caputo wrote:
> >>> A core question for the task force: Does an IXP exporting IX-F JSON
> data
> >>> have the right to prevent a network from publishing an assignment on
> the
> >>> IXP's subnet?
> >>>
> >>
> >> The answer is "no" IMO
> >>
> >>> I wrote #627 because I believe that right is a given, but apparently
> you
> >>> disagree?  What do others believe?
> >>>
> >>
> >> I completely agree that the IX is the authoritative source. However, the
> >> IX-F JSON may be faulty. Hence any conflict should be escalated
> >> immediately to all parties involved and resolution be sought.
> >>
> >> That's the reason we have the Data Ownership TF. We have found out that
> >> currently everything boils down to the netixlan object where both the
> >> net and the ix have a say.
> >>
> >> In short. Without the ix having defined an ixpfx no network is able to
> >> create a netixlan record. The only one able to create and modify a
> >> netixlan record is a net (setting allow_ixp_update=yes only means that
> >> the net delegates this right to the ix).
> >>
> >> Of course the net is able to delete a netixlan object. And with the old
> >> importer the ix was also able to delete a netixlan record. Even w/o
> >> permission of the net. And we have seen that this behaviour is
> >> unacceptable. Hence manual resolution is needed.
> >>
> >>
> >> Does that make sense?
> >
> > It makes sense, but what I perceive you believe is that it is okay to
> > publicize what may be incorrect data, rather than resolve the conflict
> > first.
> >
> > Just as IX-F JSON data can be wrong, so can Network-provided netixlan
> data
> > be wrong.  I argue that when there is a difference, it is best to play
> it
> > safe and not publicize until resolved.
> >
> > If you are concerned about what was previously unconflicted data being
> > pulled down by accident, then maybe the handling of previously published
> > data should be different than the publishing of new data?  Could that be
> > the solution we are looking for?  Ex:
> >
> > if (data is in conflict)
> > {
> >   if (already published)
> >   {
> >     keep data up
> >     initiate resolution process
> >   }
> >   else
> >   {
> >     don't put data up
> >     initiate resolution process
> >   }
> > }
> >
> > On Sat, 25 Jan 2020, Arnold Nipper wrote:
> >> Even though we consider data from IXP as authoritative, it might contain
> >> errors. According to your proposal data would disappear in the API.
> Booom!
> >
> > I think the above avoids the "Booom!", if "Booom!" refers to
> > unintentionally causing deprovisioning.
> >
>
> Now it starts to make sense to me as well. If you could also take #539
> into account we should have a made a huge step forward.
>
>
> Arnold
> --
> Arnold Nipper
> email: arnold at peeringdb.com
> mobile: +49 172 2650958
>
> --
> 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/20200128/ec6976cb/attachment.htm>