[PDB Tech] RIPE NCC IXP Tools Hackathon: Pinder

Fri Nov 4 20:54:46 PDT 2016

Chiming in, top-posting because work MUA  and to keep the trend going

This year we automated a good amount of our peering maintenance: checking for missing sessions with existing peers in IXPs we have in common, checking session status across all peers, configuring new peers across any/all locations in common (or adding the missing sessions) (with a bit of human review), and digging through netflow top talkers on transit to look for peering opportunities…

However, the piece that is more difficult to find a good approach to is also the most time-consuming remaining piece: contacting prospective peers, figuring out whether they’re interested, whether we have contacted them before, and also removing the human bit from the incoming requests/communication.  “Pinder” helps not only the matchmaking aspect, but if run by a well-known central database of peering information whose API we already use… it is inherently a deterministic mechanism to help solve this programmatic challenge.

If this state was centralized by PeeringDB, with an API and Python module – that would provide a robust enough solution to these gooey meatspace problems described in the above paragraph.  For smaller networks, they would likely just want to interact with it through the PeeringDB web UI … and yeah, I suspect there are some out there that would like to use a Pinder app (but hey, that’s just another consumer/client of the API so who cares at that point).

+1 for turning this into something running on/inside of PDB, since it is already the hub of peering matchmaking today… just without the actual matchmaking (well, Peering Coordinator Communication State Machine).

The only downside is if those networks don’t want to trust PeeringDB (or any 3rd party) with a potential list of all of their peers, since this Pinder-esque mechanism would benefit from maintaining state on who a given network already peers with.  There are options that can probably help solve this, if it is a real concern – but could diminish the value for others.  So this may not be an issue worth solving until it is an actual problem/blocker for participants

Ryan

--
Ryan Rawdon
Network Engineer , Principal
+1-312-477-5410
101 N Wacker Dr Fl 23, Chicago, IL 60606 conversantmedia.com

From: Pdb-tech [mailto:pdb-tech-bounces at lists.peeringdb.com] On Behalf Of Matthew Walster
Sent: Wednesday, November 02, 2016 22:13
To: Matt Griswold <grizz at 20c.com>
Cc: pdb-tech at lists.peeringdb.com
Subject: Re: [PDB Tech] RIPE NCC IXP Tools Hackathon: Pinder

Excellent, most appreciated!

[Image removed by sender.]
Matthew Walster | Network Engineer
fastly.com<http://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<mailto: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<mailto: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<http://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<mailto: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/20161105/2203d8ee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ~WRD259.jpg
Type: image/jpeg
Size: 823 bytes
Desc: ~WRD259.jpg
URL: <https://lists.peeringdb.com/pipermail/pdb-tech/attachments/20161105/2203d8ee/attachment-0001.jpg>