[PDB Tech] route-server information add-on

Job Snijders job at instituut.net
Mon Dec 12 12:09:32 PST 2016


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.

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


More information about the Pdb-tech mailing list