On Wed 2015-Jul-01 17:02:13 +0200, Mark Tinka <mark.ti...@seacom.mu> wrote:
On 1/Jul/15 16:54, Nick Hilliard wrote:you probably want to ignore more rpsl constructs and depend solely on as-sets, aut-nums and route/route6 objects. RPSL is not going to live up to your expectations.Honestly, I'm ambivalent about using the IRR data for prefix-list generation (even without RPSL), also because of how much junk there is in there, and also how redundant some of it really is, e.g., someone creating a /32 (IPv4) route object and yet we only accept up to a /24 (IPv4) on the actual eBGP session, e.t.c. What I'm more focused is how we can continue to scale our current system, which is much more strict, focuses on deploying customer aggregates + le 24 & le 128, instead of enumerating all possible de-aggregates that have been registered in the IRR (helps keep the configuration file small and manageable, without sacrificing reachability). And then see how we can add RPKI into the mix to make things even simpler, if at all.
Orphaned/crufty data and braindead moves (e.g. someone including a large upstream's AS-SET in their own or something) aside, the deagg issue should be handled by the tools, no? We do automated prefix gen from IRR data, and I know IRRPT will aggregate the route records before spitting out the prefix list. I would have assumed that other tools do the same? Options are available to define your max prefix length and then build your filters off of that, e.g. <aggregated route object> upto /<max prefix len>. You still face issues with people people registering discontiguous blocks (e.g. network has a.b.0.0/22 but creates records for a.b.0.0/23 and a.b.3.0/24, but leaves out a.b.2.0/24), but there isn't much we can do about that without human interaction to verify the actual allocation.
Also:
focuses on deploying customer aggregates + le 24 & le 128...
Jeebuz; you accept /128s? Perhaps "le 24 & le 48"?
Mark.
-- Hugo
signature.asc
Description: Digital signature
