On Sat, Nov 05, 2016 at 10:52:25AM +0000, Matthew Walster wrote:
> On 5 November 2016 at 10:42, Job Snijders <j...@instituut.net> wrote:
> > 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.
>
> Ordinarily I'd completely agree.
good! My trouble is that conceptually "pinder" and the other thing are
not the same at all. This is confusing, pinder is something different.
I get its a joke, now move on.
> > 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? :-)
>
> I've not come across that, but we use a YANGy/OpenConfigy style
> interface internally. I'd not considered it for something like this
> precisely because I think the barrier to entry needs to be as low as
> humanly possible so that networks new to peering, and those that do
> not have the resources to commit to a fully automated solution are
> able (and encouraged) to use the system.
There are in fact multiple initiatives, some more opaque then others.
An example might be the "Telecom Infra Project". The YANG stuff is
mostly still in people's heads.
If you look at the full service pipeline there are many more aspects to
it then just two entities agreeing with each other "lets peer".
Provisioning can be a massive PITA. The IXP scenario is relatively
straightforward as you are both connected already and the basical
premises to set up BGP are already in place and tested.
The more challenging parts are for instance when a local loop is
involved, and the cost of the local loop could be a deciding factor in
whether to peer or not - or even something mundane as organising a
proper tested crossconnect inside a single facility. Maybe start small
with a tiny state machine that is exposed for humans, or maybe leave it
with third parties.
> I realise this isn't going to be a live feature in PeeringDB (or
> alternative solution) in the next couple of weeks, but I'd like to
> think that with the conversation started that PeeringDB would be
> considered a natural fit for this tooling...
yes. For me the question boils down to:
"Should PeeringDB take up some CRM functionality?".
Where the "C" in "CRM" stands for "Peer" - but the underlaying concepts
and software would be the same.
> Or at least if the board do not decide to pursue it then someone seeks
> to take the idea and run with it.
Main responsibility for the peeringdb 'product' lays with the fine
people from the productcom team. The board is just here to make sure the
engine room stays heated and populated :-)
Kind regards,
Job
_______________________________________________
Pdb-tech mailing list
Pdb-tech@lists.peeringdb.com
http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
