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
