> --- 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
> 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.
Yes, I'm moving away from "let us all use this one thing", and rather
explore how to integrate all the available data sources (IRR, WHOIS,
RPKI, our internal DB, and $the_next_thing) and create more choice for
customers. Addressing the various threats that one can model may be
resolved through local policy ("data type X from source A overrides data
type Y from source B", or merge, or prune actions, etc).
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. [ snip ]
Yeah, a real problem for ISPs is that it isn't clear wat AS-SET to use
for what neighbor.
- The discovery mechanism that RPSL was to provide is broken beyond
repair: import/export lines are unparsable.
- I know of route server config generators that query PeeringDB to fetch
the "IRR Record" as a starting point to generate filters, but that is
sometimes problematic because (a) we may be using the wrong IRR DB in
case of duplicate AS-SET names and (b) there is a lack of granularity
(you may not want to announce the same as-set to all route-servers).
- NTT simply asks customers/peers what as-set to use during the turn-up
process, but that as-set name may be deprecated by the peer over time,
and the mechanism to inform us is a bit archaic "email us".
What I think could be done with RPKI:
A mechanism that addresses the autodiscovery, and allows a degree of
granularity by allowing you to specify on a per-ASN basis what should be
used as the starting point to create a filter will make things better.
Toolchains (COTS, closed, and open source) would increase their chances
of finding the right starting point if they first try to query the RPKI
for information, and if that fails, fall back to either a database
record from a service order form or a query to PeeringDB. With "right" I
mean the most up to date and most likely intended one.
An 'AS-SET in RPKI' statement could also be published in IRR format (by
RIRs publishing it under a new "source:" name) to provide some backwards
compatibility. This helps address challenges in geographical regions
where the whole concept of "IRR" never took off, but RPKI is popular
(LATAM comes to mind).
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.
Any platform under end-to-end control of a single entity will be able to
innovate and deliver at a much faster pace than something that'll need
to facilitate coordination across administrative domains
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
I'll make some phone calls Monday.