>>>>Also, if you embed all the criteria in one routing table, how will you
>>>>learn dynamic routing daemons (ospfd et al.) to add the
>>>>source/protocol/TOS fields you need to the transient entries that they
>>>>create in the FIB? Because now routing daemons know only about the
>>>>dest-address criterion.
>>>
>>>This is Quagga/Zebra developers problem :) Btw - since they support
>>>Linux multiple routing tables it should be no harm to support NetBSD's
>>>way ... it's just another #ifdef :)
>>
>>But how they should it? The Linux way with multiple routing tables seem
>>straightforward to support, but I don't see how the OSPFD configuration
>>would look with your scheme.

It is not 100% exact. Some modifications are required in order to have 
the support of many kernel FIB with Quagga. In fact, this patch was 
already done a long time ago on FreeBSD 4 thanks to a setsockopt on the 
routing socket in order to associate the routing table to a specific 
index, and the interfaces to the same index. Then, when you start the 
zebra daemon, you have to provide the FIB index.
It is described by:
   http://2002.eurobsdcon.org/papers/scandariato_presentation.pdf

However, even if this paper starts many zebra daemon, it is easy to 
modify Quagga in order to have a single zebra daemon which supports many 
RIB: one RIB for each VPN id.

Regards,
   Vincent