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
