Peeringdb: IXPs should have a control of IP addresses within their own Peering LAN prefixes

[shusugmt]

Currently any organization/user can declare that he/she is connecting to an IXP A and the address at there is 192.0.2.1, but the IXP A who actually owns the Peering LAN prefix 192.0.2.0/24 have no control of it. It is better for IXPs to have the privilege especially deleting it on their own prefixes, to keep the data fresh and correct.

[arnoldnipper]

The current PeeringDB model is network centric. Networks decide what to disclose. Hence your request in the current phrasing clashes with this paradigm. A more elaborated approach could be

• networks decide whether they want to be listed at an IXP or not.

• if they decide to be listed, relevant information like IP address, port speed, RS peering comes from the IXP in question

• IXP provide their data at http://ml.ix-f.net/directory

[eloos]

I believe with the allow_ixp_update and json/ix-f link we are now deleting invalid addresses if the IXP creates the correct IX-F JSON file?

[arnoldnipper]

yes, that's covered by the new feature

[arnoldnipper]

@shusugmt, are you happy with the solution? Please respond within 5 working days. If we don't get a response we close the issue

[shusugmt]

@arnoldnipper Thanks for pinging. I think that function only partially solve this problem that:

• allow_ixp_update option needs to be enabled by networks, which is not controllable by prefix owner
• Not all IXPs are exposing IXP-F JSON

But at least I know where to contact when we face a problem if our IP is held by wrong network, so you can close this as this can't be achieved in a short term. Or, should be left open for longer term discussion?

[arnoldnipper]

@shusugmt imho the function completely solves the problem.

• even if allow_ixp_update is set to false, false IP information is removed (given the IXP provides information in IX-F JSON format)

• well, if IXP want to have control, using the IX-F JSON schema is the way to go

So, what's missing?