[PDB Tech] route-server information add-on

[Job Snijders]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.peeringdb.com/pipermail/pdb-tech/attachments/20161212/06fc7b27/attachment-0001.html>