IRR AS-SET best practices - AS-SET Clash

Sun Jan 28 02:36:05 UTC 2018

On Sat, Jan 27, 2018 at 04:30:56PM -0500, Jared Mauch wrote:
> 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.

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.

Kind regards,

Job