On Wed, Jan 24, 2018 at 02:48:58PM +0000, Job Snijders wrote:
--- thread hijack ---
Coincidentally, I'm working to define something like "AS-SETs in RPKI". There are a number of downsides to "AS-SETs in IRR": collisions between databases can exist, it is hard to figure out what AS-SET to use for what ASN (we rely on service order forms, peeringdb or guessing for that), and the way the recursion was done can too easily result in gigantic sets.
Obviously you have to prune once you hit a loop, but this is how you can traverse a edge-node graph to find the leaves given a starting point.
I'd be interested to know what others think about improving feature parity between IRR and RPKI, and while doing that make the bad aspects of AS-SETs go away and keep the good parts. Thoughts?
I've found that saying RR, IRR and RPKI overloads one technology with another. One needs a standards based method to access a database about routing information. We can federate databases together or come up with methods to do this. RPKI is another database you can validate against but it also has limits. If I were a backbone, I would be asking myself: How can customers effectively communicate with me their intent? RPKI and IRR have weknesses and the networks with automation and tooling here are light years ahead of those that have nothing. We as an industry must get better so the impact is less when bad things happen. It's clear to me a decade later even asking people to filter out so called tier-1 networks with as-paths is still a major problem. 6453 & 5511 are still accepting their peering partner ASNs from customers (for example) and it shows. 701 still accepts peer ASNs from peers. (example AS_PATHs in postscript).. There's no universal way to communicate these relationships yet we have web based platforms where I can tell you what many list members ate for dinner last night. There is a lack of will to take action here and a lack of common toolchains that can be integrated to perform the tasks. - Jared
ps. raised the question here too https://mail.lacnic.net/pipermail/lacnog/2018-January/005845.html
A few interesting AS_Paths: 2497 701 5511 59378 7473 2914 132602 38203 137038 3356 6453 21502 1299 6848 44216 701 6453 21502 1299 6848 44216 -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.