[PDB Tech] route-server information add-on

[Arnold Nipper]

On 12.12.2016 21:09, Job Snijders wrote:
> Hi Chris,
> 
> ASNs presently have a cost price of 0 (zero) euro in the RIPE region. I
> don't imagine the price to be much different in other regions. The IETF
> RFCs recommend to get different ASNs for different routing policies.
> This clearly applies to the case of the office network vs the route
> server function - each deserve a separate ASN. I consider it a matter of
> engineering hygiene to use different ASNs for different functions.
> 
> Happy to continue this specific topic off list since it somewhat
> deviates from the main thread.
> 

+1 what Job says. Otoh I can imagine that you have additional servers in
an RS net which do net act as a RS (e.g. simply for monitoring)

Arnold

> Kind regards,
> 
> Job
> 
> On 12 Dec 2016, 21:04 +0100, Chris Caputo <ccaputo at alt.net>, wrote:
>> A dedicated ASN runs counter to a budget IXP. At the SIX we have an ASN
>> presently used just for our route servers, but if the SIX ever become
>> multi-homed as far as its website/email/DNS, the same ASN would likely be
>> used.
>>
>> Seems to me the flag makes sense with the IP, just like "RS Peer". Ie.,
>> add "RS Server" to the IP table.
>>
>> Chris
>>
>> On Mon, 12 Dec 2016, Job Snijders wrote:
>>> I myself am also of two mind on where the flag belongs: on the one hand
>>> I strongly recommend everyone to use dedicated ASNs for route server
>>> functions (and as such the "net" object is a good place to store it), on
>>> the other hand at the "ip level" offers more fine grained control.
>>>
>>> What do others think?
>>>
>>> Kind regards,
>>>
>>> Job
>>>
>>>
>>> On 12 Dec 2016, 20:47 +0100, Arnold Nipper <arnold at nipper.de>, wrote:
>>> On 12.12.2016 14:25, Job Snijders wrote:
>>> On Mon, Dec 12, 2016 at 01:58:51PM +0100, Arnold Nipper wrote:
>>> 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?
>>>
>>>
>>> It helps on the configuration generation side:
>>>
>>> If "route server" == true:
>>> no bgp enforce-first-as
>>> no bgp next-hop peer-address
>>> no as_path_filter "^$peer_asn_"
>>> else:
>>> bgp enforce-first-as
>>> bgp next-hop peer-address
>>> as_path_filter XYZ
>>>
>>> The above pseudo code is assuming people generate config straight from
>>> PDB, in addition to the above, a PDB user can programmatically enforce
>>> their:
>>>
>>> "we peer with every route server"-policy
>>> or "we dont peer with any route servers"-policy
>>> or "we only peer with route servers operated by the IXP
>>> themselves"-policy
>>>
>>> So one could argue there is a wide varierty of decisions that can be
>>> assisted if your peers self-report whether they are perform a Route
>>> Server function or not.
>>>
>>> All data retrieved from PDB must be validated against an operators own
>>> policy and procedures. I always consider PDB data to be a raw resources,
>>> this does not have to do with (lack of) trust, but rather with making
>>> assisted choices.
>>>
>>> Hope this clarifies the use case.
>>>
>>>
>>> The use case is quite clear. It's more about where and what to store.
>>> And the more I think about that I come to the conclusion that this
>>> information belongs to the peering IP and not to the network. So far you
>>> can tag the IP that it is an RS Peer. What you would need additionally
>>> is that the IP is an RS itself. Does that make sense?
>>>
>>>
>>>
>>> Arnold
> 
> 
> _______________________________________________
> Pdb-tech mailing list
> Pdb-tech at lists.peeringdb.com
> http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
> 


-- 
Arnold Nipper
Chief Technology Evangelist and Co-Founder

DE-CIX Management GmbH | Lindleystrasse 12 | 60314 Frankfurt am Main |
Germany | www.de-cix.net | Phone +49 69 1730902 22 |
Mobile +49 172 2650958 | Fax +49 69 4056 2716 |
arnold.nipper at de-cix.net | Geschaeftsfuehrer Harald A. Summa |
Registergericht AG Koeln HRB 51135

-------------- 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/5cb92a46/attachment.sig>