[PDB Tech] route-server information add-on

[Job Snijders]

I don't understand your concern. It's self reported information, just like the as-set, the max prefix, etc.

Job

On 12 Dec 2016, 13:59 +0100, Arnold Nipper <arnold.nipper at de-cix.net>, wrote:
> On 12.12.2016 10:26, Job Snijders wrote:
> > On Mon, Dec 12, 2016 at 10:17:19AM +0100, Arnold Nipper wrote:
> > > On 12.12.2016 10:06, Job Snijders wrote:
> > > > On Mon, Dec 12, 2016 at 04:58:22AM +0100, Arnold Nipper wrote:
> > > > > Jon,
> > > > > On 12.12.2016 04:41, Jon Nistor wrote:
> > > > > > I had a peer ask that I add an entry for the TorIX route-servers as
> > > > > > entities in peeringDB as their system uses automation against
> > > > > > peeringDB for configurations, etc.
> > > > > >
> > > > > > It got me thinking, could it be possible to add in an option for
> > > > > > route-servers under Internet Exchange points that one could query
> > > > > > via the API? Would it be worth it? Is there an alternative to this
> > > > > > that would work (i've listed one ref below).
> > > > > >
> > > > > > ref: https://www.peeringdb.com/net/11429
> > > > >
> > > > > route servers belong to an ASN / network. Simply configure them as
> > > > > networks as did some other 50 IXP already (hint: search for "route
> > > > > server").
> > > > >
> > > > > What else is needed?
> > > >
> > > > I think what is requested here is a programmatic way to establish ahead
> > > > of time whether the BGP speaker will confirm to RFC 4271 or RFC 7947. I
> > > > agree with you that putting the words "Route Server" in the name of the
> > > > "net" object is an excellent start, but that's mostly there for humans.
> > > >
> > > > Will Hargrave brought up some configuration settings that are only
> > > > applicable to Route Servers and not to normal peers. (And I'd like to
> > > > add to the list whether do "set ip next-hop peer-address" or not)
> > > >
> > > > A developer can already identify which ASNs belong to the operators of
> > > > an IXP by following the organisational object:
> > > >
> > > > example: https://www.peeringdb.com/net/11429 belongs to
> > > > https://www.peeringdb.com/org/7 and https://www.peeringdb.com/ix/14
> > > > also belongs to https://www.peeringdb.com/org/7
> > > >
> > > > What is lacking however, is for 'net/11429' to declare "I am a route
> > > > server, treat me as one".
> > > >
> > > > Maybe a boolean should be added to "is_routeserver" to the 'net' object
> > > > data model, which can be set to true if the ASN acts as a RFC 7947
> > > > compliant BGP speaker.
> > > >
> > >
> > > Looks like a straight approach but might be not failsafe, because
> > > everyone can set this flag.
> > >
> > > Wouldn't it make sense to wire the ASN used by the route servers in the
> > > IXP object?
> >
> > No, a programmer can already search for the ASNs connected to the IXP
> > operated by the IXP themselves, I should you how net/11429 -> org/7 &&
> > ix/14 -> org/7. All that is needed is a boolean indicating whether a
> > network is a route server or not. The net effect is that you have a
> > programmatic way to deduce which one is the office network, and which
> > one is the route server.
> >
> > Also, I've seen Route Servers in the wild which were not operated by the
> > IXP themselves. I'd consider it a feature if everyone can set the flag. :-)
> >
>
> What does it help when everyone is able to set the flag and you can't
> trust that this really is a route server net?
>
>
>
> Arnold
>
>
> _______________________________________________
> 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: <http://lists.peeringdb.com/pipermail/pdb-tech/attachments/20161212/839a993f/attachment.html>