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 <[email protected]>, 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 <[email protected]>, 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 > [email protected] > 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 | [email protected] | Geschaeftsfuehrer Harald A. Summa | Registergericht AG Koeln HRB 51135
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Pdb-tech mailing list [email protected] http://lists.peeringdb.com/cgi-bin/mailman/listinfo/pdb-tech
