[PDB Tech] route-server information add-on

[Job Snijders]

Hi all,

To close the loop on Jon Nistor's request, I've filed the following
small proposed change to the PDB code (screenshot mockup included):
    
    https://github.com/peeringdb/peeringdb/issues/105

Today we can set "Network Type" to various things such as "NSP"
"Non-Profit", "Content" etc. If we add a new type called "Route Server",
the programmatic aspect which was brought up in this thread is resolved.

I believe that "per ASN" is just the right amount of granularity, and is
beneficial in that it strikes me as less error prone (you can't forget
to set it per-connetion because you set it at the 'network' level), less
ambiguous, aligns with the engineering paradigm to use a separate ASN
"per routing policy", and finally: it fits into an existing data field. :-)

Kind regards,

Job

On Mon, Dec 12, 2016 at 09:18:24PM +0100, Arnold Nipper wrote:
> 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 <ccaputo at alt.net>, 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 <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
> > 
> > 
> > _______________________________________________
> > Pdb-tech mailing list
> > Pdb-tech at lists.peeringdb.com
> > 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 |
> arnold.nipper at de-cix.net | Geschaeftsfuehrer Harald A. Summa |
> Registergericht AG Koeln HRB 51135
>