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

[Chris Caputo]

Arnold,

> Even though we consider data from IXP as authoritative,

Either data from the IXP is authoritative or it is not.

If an IXP's IX-F JSON export is properly formatted and decoded, I believe 
it should be considered authoritative, giving the IXP the ability to 
prevent conflicted data from being propagated and used to inform 
provisioning systems.

Propagation of conflicted data affects peering fabrics by either causing 
broadcast/multicast storms for missing routers or by having networks 
attempt connections to routers using incorrect ASNs.

IXP data might contain errors, as may PeeringDB data.  That has always 
been the case.  Further, both sources of data can be hacked, and the value 
of PeeringDB as a hacker target only goes up if networks are automating 
BGP sessions in a senseless manner.  Thus networks that use data provided 
by PeeringDB should be careful in their automation, such as by involving 
human review, or handling changes in source data in a manner resistant to 
unintended disruption.

> it might contain errors. According to your proposal data would disappear 
> in the API. Booom!

When the IX-F importer was running, it did exactly that!

Upon initial implementation of #627, conflicted data would disappear from 
all views except the /net/ (aka /asn/) HTML page.  On the /net/ (aka 
/asn/) HTML page it would be flagged as conflicted.

After initial run of #627, no data would disappear, except in cases where 
either the IXP or the Network no longer lists an assignment.  That is 
intended, since the idea is that mutual agreement is needed in order for 
the assignment to be public.

In the same way that no one is allowed to force data onto a Network's 
PeeringDB pages, no one should be allowed to force data onto an IXP's 
PeeringDB pages if an IXP makes it clear they do not want that.  As I 
understand things, that's always been a fundamental PeeringDB concept with 
respect to Network pages, and I don't see why that shouldn't also apply to 
IXP pages.

> Again: if there is a conflict, data *must* stay intact and conflict
> resolution has to happen asap with all parties involved.

Network-provided data stays intact in the netixlan table, but it is 
disputable (hence this discussion) that it should be public in such as way 
as to inform provisioning.  I believe the IXP should have the option of 
having a say in that matter, since it is their address space, and their 
fabric which can be affected.

Chris

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!
> 
> Again: if there is a conflict, data *must* stay intact and conflict
> resolution has to happen asap with all parties involved.
> 
> 
> Arnold
> 
> On 25.01.2020 00:37, Chris Caputo wrote:
> > In practice, with #627, data would not disappear.  Rather, in cases where 
> > an IXP is providing authoritative data, it won't be allowed to appear 
> > prematurely in a way to be used for provisioning.  And then once agreement 
> > happens, it will become available.
> > 
> > 
> > Chris
> > 
> > On Fri, 24 Jan 2020, Terry Sweetser wrote:
> >> Agreeing with Arnold here, it's the ISSUE.  Having data disappear is 
> >> annoying some large players in the market and devaluing the PDB.
> >>
> >> 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 Arnold Nipper
> >> Sent: Saturday, 25 January 2020 9:29 AM
> >> To: DTF PeeringDB <dataownership-tf at lists.peeringdb.com>
> >> Subject: Re: [PDB Data Ownership-TF] IXP assignment IP address (netixlan) ownership
> >>
> >> On 24.01.2020 18:25, Chris Caputo wrote:
> >>
> >>> On Fri, 24 Jan 2020, William Marantz wrote:
> >>>
> >>>> 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.
> >>>
> >>
> >> I totally disagree. If data is conflicted we can't decide whether it is valid or not. Hence the conflict has to be resolved.
> >>
> >> Interpreting conflicted data as invalid is the worth you can do IMO.
> >> This might lead to deconfiguration of sessions as the netixlan object is not shown anymore via the API.
> >>
> >> Instead conflicts must be resolved asap leaving the data intact until the conflict is resolved.
> >>
> >>
> >>
> >> Arnold
> >> --
> >> Arnold Nipper
> >> email: arnold at nipper.de
> >> mobile: +49 172 2650958
> >>
> >> -- 
> >> DataOwnership-TF mailing list
> >> DataOwnership-TF at lists.peeringdb.com
> >> https://lists.peeringdb.com/cgi-bin/mailman/listinfo/dataownership-tf
> 
> 
> -- 
> Arnold Nipper
> email: arnold at nipper.de
> mobile: +49 172 2650958
> 
>