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