Re: merging forwarding & packet filtering?

[Thor Lancelot Simon <tls%panix.com@localhost>]

On Tue, Mar 08, 2011 at 04:25:48PM -0600, David Young wrote:
> On Fri, Feb 18, 2011 at 08:20:27PM -0300, Dennis Ferguson wrote:
> > To keep both types of users well served the structures which implement
> > standard routing (which must be there) and "policy routing" are generally
> > kept separate, preserving the scalability of the former while avoiding
> > implementation constraints that might exist in the latter if it needs
> > to serve users which want to do frequent, incremental updates.  If you
> > think you have a structure which can serve both without penalizing
> > one or the other that is great, but in my experience there is no way
> > to make one thing do both really well.
> 
> Thanks for your thoughtful and informative response!
> 
> I don't think that it's necessary to create a new data structure
> that meets every need.  Some policies just refine forwarding rules,
> and we can apply those policies after a super-fast forwarding-table
> lookup.  For example, a policy that uses PF state to pin a flow to the
> current default nexthop is just a refinement of the default route, so
> let us write it as such.

But using PF state is slow.

For what it's worth, we have policy routing requirements probably
different from (much simpler than) Dennis' but we ended up in much
the same place in terms of his general observation at least.

What we ended up with is probably available to NetBSD if it's wanted.
It is very young and will doubtless need bugs shaken out, though...

Along the way we did notice some relatively quick and painless
optimizations (depessimizations?) that could be made to the current
route lookup.  One very obvious one is that you shouldn't have to
chase a pointer from the route entry to find out the next hop
address!  Some builtin storage in the route entry for this would
be a huge win.

Thor