[PDB Tech] route-server information add-on

[Arnold Nipper]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <http://lists.peeringdb.com/pipermail/pdb-tech/attachments/20161212/c0acacdb/attachment.sig>