Add API calls for commonly run queries

[mcmanuss8]

Is your feature request related to a problem? Please describe.
It's often the case that users of peeringdb want to find out where two entities intersect. See #16 for such an example.

Who is affected by the problem?
Anyone who dumps the db locally and then writes their own SQL queries to do this.

What is the impact?
Unnecessary time for users and peeringdb server resources serving up full caches of the db, just so folks can do common queries with more flexibility.

Are there security concerns?
No, RO

Are there privacy concerns?
No, all the same data

Describe the solution you'd like
#16 was done but I don't see it documented in https://www.peeringdb.com/apidocs/ which means it functionally doesn't exist for users.
We should:

• Add docs for the work done in Given 2 ASNs, tell me where they overlap #16
• Add similar overlap queries for ix <=> fac (show me which facilities share this set of 2 or more IXes, as well as which IXes share this set of 2 or more facilities)
• Add similar API calls that people commonly do (need to poll the community for this)

Describe alternatives you've considered
Maintain status quo

Could this feature request need support from the Admin Committee?
No

What is the proposed priority?
Nice to have

Provide a rationale for any/all of the above

[mcmanuss8]

• Given 2 IXes, show the list of common networks
• Given 2 Facilities, show the list of common networks

[udf2457]

For those of us using PeeringDB as a handy backend for config generating tools, I don't know what you'd call it but say a Left-Right Merge API output would be good flippin awesome :-) .

So something like ....

INPUT

• "My" ASN
• "Their" ASN
• "My" Port Subset (i.e. for those with X ports, what subset (or all) will establish with the peer ?)
• "Their" Port Subset (as above)
• "Their" Prefix count margin (i.e. what safety margin (if any) you want to add on top of their declared prefix count)
• Peering location(s) & LAN(s)

OUTPUT:

• Nice merged JSON of all the relevant params ("my"/"their" ASN, "my"/"their" port IPs, "their" prefix counts)
• For brownie points, you could "group" the JSON output by peering LAN (e.g. if either/both sides have multiple ports on a LAN, you could group that into one group).

[renatoalmeidaoliveira]

Given two ASN, show the list of common IXes.
Given an ASN (A) and a location, the nearest IX that ASN (B) is present.

Usefull for ISP looking for peering relations based on their network traffic.

[arnoldnipper]

IMO a more powerful API (allowing for logical operations e.g.) would do the trick. E.g. asn__and=asn1,asn2 or, ix_id__or=ixid1,ixid2

[mfringel]

Summary: "Anything that would require a join or two in order to get the information."

Examples:

• ASN List by Organization Name
• POC by Org Name
• Netixlan IDs by Org Name / ASN
• Netfac by Org Name / ASN
• Networks in a Facility
• IX Participants by IX Name
• Common IXes and Facilities between a "left set" and "right set" of ASNs/Networks/Orgs
• Networks in a Facility, including city, country, and state/province for disambiguation.

For things that could return multiple matches (i.e. org name lookups), possibly returning a HTTP Status Code 300 (Ambiguous) with the possible matches (up to a certain number to prevent someone from just typing '*').

---

Also, right now, only the 'fac' table includes 'state' (as in province, etc.), but no other table does, which means that in order to get full disambiguation by address, you need to join the 'fac' table.

[leovegoda]

We discussed this at today's @peeringdb/pc meeting and agreed to investigate how much of this could be achieved with v2 search. This would re-scope the work from development to analysis. That should inform the next step.