Hello Lukas(all On 30.08.2019 20:12, Lukas Tribus wrote:
> I would opt for simpler, more predictable fixes. > > Why not limit the IX-F overwrite to cases where there is an actual > ASN mismatch between PDB and IXF? Or in other words: don't delete > addresses in PDB when the data is simply missing in the IXF data? > Sure, obsolete IP addresses won't get cleaned up immediately. But > they would get cleaned up when it matters (when the IP is > reassigned), without the false-positives we have today. > what imho makes sense is to have an additional field in the netixlan record which gives more information about the status of the connection. Such a field could also hold a value for the situation you described above [0] Current interpretation of netixlan is that the network is *operational* at the IX. However networks may want to let others know well in advance that they will connect to an IX and also already provide IP information [1] Another use case could be to let peers know that the connection is down for whatever reason. We could work on such an approach w/o even involving 3rd parties like the IX-F JSON from the IXes. We've seen that we have been a bit naive when implementing the IX-JSON importer. However, when implemented carefully 3rd party information would help. Cheers Arnold [0] For very good reasons PDB currently checks that an IP is unique. That part of the code would have to be reworked as well. On the customer side that might introduce more complex changes as well. [1] https://github.com/peeringdb/peeringdb/issues/539 -- Arnold Nipper email: [email protected] mobile: +49 172 2650958
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pdb-tech mailing list [email protected] https://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
