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 <[email protected]>, 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 > [email protected] > http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
_______________________________________________ Pdb-tech mailing list [email protected] http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
