[PDB Tech] RIPE NCC IXP Tools Hackathon: Pinder

[Matthew Walster]

Excellent, most appreciated!

*Matthew Walster *| Network Engineer
fastly.com | @fastly <https://twitter.com/fastly> | LinkedIn
<http://www.linkedin.com/company/fastly>

On 3 November 2016 at 03:08, Matt Griswold <grizz at 20c.com> wrote:

> Top posting since I just skimmed it (but had already looked at your
> slide deck from the RIPE emails) and am not addressing specific
> points... yet :)
>
> Nice work - I think it's a good idea and would belong in PeeringDB.
> I've brought it up internally for board discussion and we will update
> the list after further discussion.
>
> * Matthew Walster <matthew at walster.org> [161101 16:39 +0000]:
> > 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
>
> _______________________________________________
> Pdb-tech mailing list
> Pdb-tech at lists.peeringdb.com
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.peeringdb.com/pipermail/pdb-tech/attachments/20161103/a0dbde39/attachment.html>