[j-nsp] dynamic prefix list based on as-path .. is it possible?

[Jeff Haas]

[Note that this is where I go off into speculative thinking land.  Those who know me from conferences are familiar with the process, but I'd really rather not have someone note my email address and think they should start hammering on product management as a result of such public discussion.]

> On Jul 29, 2015, at 10:16 AM, Roland Dobbins <rdobbins at arbor.net> wrote:
> 
> On 29 Jul 2015, at 21:02, Jeff Haas wrote:
> 
>> I don't have a clean answer, but it's leading me to ponder some.
> 
> Just origin and/or destination AS would be useful in and of themselves, irrespective of further pathing options. . .

As I mentioned in the earlier mail, I think a lot of the base problem is really a distributed knowledge issue.  Routers in an AS that may want to take advantage of origin/peer-as to prefix mappings only can do so if they use their local knowledge or have a distribution mechanism that handles passing along that remote knowledge to the rest of the AS.  That gets into some ugly scaling.  The big providers who do a large amount of IRR filtering combined with AS regex checks already understand a significant part of the state cost invovled. Obviously a non-CLI mechanism or a somewhat more dense policy format would help, but at the end of the day that state needs to end up in data structures.

Locally on a router, we have some potential ability to do this sort of mapping within routing.  The missing plumbing right now is the ability to jump from a given origin or peer-as to the set of routes containing it.  The most likely way to implement that plumbing is to take the existing routes and throw them onto a pair of doubly linked lists, one for origin and one for peer.  (Singly doesn't scale for removal.)  

The issue with such "well, that sounds easy" solutions is what it does to system scale.  In the days of 2G 32-bit RPD, the addition of a single *word* (4 bytes) to the route data structures was reason for massive freak-out.  Even in 3G 32-bit RPD, it's problematic.

We're now in the land of 64-bit RPD as an option.  At some point, finding ways to enable optional features that burn memory to get cool effects but can be disabled for lower scale systems would be cool.  Right now, the data structures in question are insufficiently polymorphic for us to do such a thing, but we're keeping it in mind as part of future work.

But you'll note I said "within routing".  Trying to push this sort of mapping to the line cards for firewalling won't scale.  It'd probably move into a triggered poll/update model.  So, for those thinking this is useful, is it useful if you can only do this sort of thing for a subset of your routes/ASes?

And then eventually we get back to the information hiding issue that route selection imposes on your AS.  You probably want all of the information, not just your active routes.  This *really* pushes you to some sort of external database and this starts smelling like policy.  Policy scales a lot better since it doesn't gum up the size of important data structures; it does its work via functional side effect.

So, hopefully having walked everyone through something policy-like perhaps making better sense (and if you're not convinced, I'm sure you'll let me know!), what does that look like?  My suspicion is it's really something a bit like what we have for the internals of rpki-rtr for RPKI ROA objects: An as-map.  E.g. "AS 64512: 192.0.2/24, 10/8 24<= prefixlen <= 32", etc.  You can obviously get this functionally today with a mix of route-filters, prefix-lists and as-regex.  The question is whether being able to store a map and then say something like:

term a {
   match origin-as via as-map foo;
}

is useful.

-- Jeff