RFC: Separate import/export tables

[Maria Matejka]

Hello!

I'm quite confused by what you're trying to achieve. How would you 
choose the routes that are likely to be exported? If there is something 
that you repetitively count in export filters, you may move this check 
into the import filters (these are run only once) and store the result 
using a custom attribute:

	attribute int whatever;
	...
	import filter { ... whatever = something; }
	...
	export filter { if whatever > otherthing then ... }

Anyway, in the complete picture, you are always going to run an export 
filter at least once for all routes combined with all exporting channels 
in some form.

Maria

On 6/18/21 7:11 PM, Asbjørn Sloth Tønnesen wrote:
> Hi,
> 
> We have an internet router setup where we have a few
> customer connections, and hundreds of peering sessions.
> 
> A lot of CPU time is wasted running the export filters over
> the entire internet routing table per peer, in order to find
> the relatively few prefixes to actually export.
> 
> I know we could try to work around it, by having a complicated
> system of tables and pipes, like one table per peer per family.
> 
> However I would prefer to keep things simple, so if I could
> just keep a small table containing the few prefixes that are
> likely to match the export filter, and use that as export table,
> while still importing prefixes from peers into the master table.
> 
> Since BGP already has "(import|export) table <switch>", then
> maybe "table [import|export] <table>" could work.
> 
> Before I try to implement this, are there any support/comments/
> objections to this approach?
>