[PDB Tech] route-server information add-on

[Chris Caputo]

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