[PDB Tech] RIPE NCC IXP Tools Hackathon: Pinder

[Matthew Walster]

Hey all,

The weekend before RIPE73, RIPE NCC held an IXP Tools Hackathon, and an
idea we came up with was a system to facilitate peering.

It's not a matchmaking service -- you don't get suggested possible peers,
you don't submit any sensitive data -- it just facilitates peering.

I'm sure you've all received emails from other networks... Perhaps it came
from a @gmail.com address, perhaps it just had their IP address at an
exchange without telling you which exchange it came from, perhaps this peer
is only responsible for a couple of Megabits per second of traffic and the
effort required to setup this peer is disproportional to the benefit your
network would gain from it.

That's why Pinder came around -- Tinder for Peering.

The idea is that if there is a desired peering relationship between two
networks, and you're happy to just configure some sessions rather than
enter into a commercial agreement, Pinder would be the middle man. You
would submit the request via either a basic Web UI or an API, the other
network would either be notified or periodically check their outstanding
requests, and if they are willing to peer, both sides are told to configure
a session. Once both sides indicates sessions are configured and
established, the request is then deleted (rather than persisting in a
database) so as to prevent any data security issues in the future.

We knocked up a brief slide deck to explain a little better:
http://accel.waffle.sexy/pinder.pdf

Our example code is at: http://github.com/dotwaffle/pinder

A brief description of the project is at: http://peer.sexy

I would love it if this could be integrated (probably with entirely new
code) into PeeringDB, taking advantage of almost all networks having valid
accounts and fairly accurate data on which exchanges they are at.

Is this something the PeeringDB board would consider? Is this something
networks are interested in seeing from PeeringDB? Certainly on the of the
other Hackathon teams (the peerme team, partly from Facebook, who I know
have just subscribed to this list to hear this discussion) are interested
in integrating with it as soon as possible, rather than providing yet
another one-sided crazy web form that prospective peers have to fill out.

Here's some discussion points I thought of:

1. Does PeeringDB want to be that facilitator? Does it want to be a third
party service?

2. If so, how is authentication/authorisation performed?

3. Also, if it isn't a function provided by PeeringDB, do we want a new
field in the ASN record that has an endpoint for a particular protocol
(preferably via https rather than on raw TCP) so people can design their
own tools against it and the communication becomes decentralised?

4. If it is taken on by PeeringDB, how much metadata wants attaching to the
communication? Should it just be "accepted", "rejected", "contact me" as we
have suggested, or would a messaging field be appropriate? If that was the
case, does that put PeeringDB in an awkward position?

5. If the primary consumable was an API, with a basic Web UI on top for
those unwilling to build on top of it, how do we make sure the private data
stays private?

6. Assuming PeeringDB was chosen as the "right place" to store this
project, is this likely to gain any traction anytime soon? Do we need
volunteers to help implement it? Is this even something that can be
considered a separate module that perhaps we want to have Open Source from
Day One?

Anyway, enough waffle from me... I'd be interested in hearing people's
thoughts.

Matthew Walster
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.peeringdb.com/pipermail/pdb-tech/attachments/20161101/02a1de47/attachment.html>