[PDB Tech] RIPE NCC IXP Tools Hackathon: Pinder

[Matthew Walster]

On 5 November 2016 at 03:54, Rawdon, Ryan <rrawdon at conversantmedia.com>
wrote:

> +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).
>

​To be 100% clear on my intentions with this project: The "matchmaking"
aspect is a cheap gimmick. The real purpose of Pinder is to provide a
centralised method of contacting peers that doesn't rely on the crazy
emails to and fro. Analysing who might peer with you should remain within
the purview of the network itself, not PeeringDB.

Likewise, I've tried to encompass in the finite state machine the concept
not only of "accept" and "reject", but also "let's talk". This signifies
that the request has been seen by someone and they want to discuss things
before making a decision. That could be an email chain, that could be a
phone call, it could be a meeting at GPF/EPF/NANOG/RIPE/whatever, or it
could simply be out of band validation that things such as MD5 passwords,
commercial terms, requests to amend the PeeringDB record to show a valid
IRR record... The list is endless. I imagine 90%+ of the peering requests
through the system wouldn't enter this state, but I feel it's a valuable
one to have.

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
>

​Ok, so, I actually don't think the fact someone peers or not is a
particularly secret thing -- you'll (hopefully) either be registering it in
an IRR object, or given a looking glass in either network, visibility
through traceroute that the path doesn't go via a third party transit
provider!

The potentially "secret" part of it in my view is the metadata around it --
if you integrate a messaging framework you could leak sensitive information
(imagine if someone uses it to send confidential commercial terms or
similar). Hence why the model is deliberately simple in the prototype. It
says "accept", "reject", "contact", "I've configured", "you've configured",
and "finished". The finished state would ideally then delete all previous
evidence of previous states. Whether or not the record persists at all
after the "finished" state (be it for a set number of days or forever) if
up to the implementation.

Of course, this is all up for discussion -- and the feedback I've received
so far is that this idea is due to be discussed at the next PeeringDB board
meeting.

Certainly I'm excited to see where it can go. If it encourages more people
to keep up to date PeeringDB records, including IRR filters, max prefixes,
and points of presence, this can be a wonderful thing for the peering
community.

​M​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.peeringdb.com/pipermail/pdb-tech/attachments/20161105/9f928ce1/attachment.html>