[PDB Tech] RIPE NCC IXP Tools Hackathon: Pinder

[Job Snijders]

Hi Matthew,

<no hats>

I recommend you remove the 'cheap gimmick' parts and make it look more
like a boring business tool with appropiate domain name and
documentation style. That will help bring the actual novel and
intriguing parts of the engine into focal point.

I know some people are working on YANG modeling for peering interactions
on the layer-8 level, I can see a the pinder approach as viable too. I
do not know where these things belong yet and what PeeringDB's role in
it will be. For now I view this as a social experiment, fair? :-)

Kind regards,

Job

On Sat, Nov 05, 2016 at 10:32:09AM +0000, Matthew Walster wrote:
> 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​

> _______________________________________________
> Pdb-tech mailing list
> Pdb-tech at lists.peeringdb.com
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech