[Xorp-hackers] Soft-wiring RIB

[Orion Hodson]

Now that there's some semblance of route redistribution happening via 
the RIB, it's become apparent that there is a start up ordering issue 
when one protocol process imports routes from another.  There's also a 
potential source of confusion in table names.  I believe adding 
additional RIB configuration can solve both problems.

In the template files we specify dependencies.  The RIB depends on the 
FEA, protocols typically depend on the RIB.  We typically don't have 
routing protocols depending on each other.  Using RIP and static routes 
as an example, RIP does not depend on the static routes process.  
However, if the RIP configuration specifies importing routes from the 
static routes process, it implicitly depends on it.  As the rtrmgr is 
now, RIP ends up being configured before the static routes process so 
when RIP requests the RIB to redistribute routes from the static routes 
table it fails because the static routes table has not yet been created 
by the static routes process.

One solution would be to change the code so that a redistribution 
request creates the protocol origin table in the RIB if it does not 
exist already.  So RIP asking for static routes, would create the 
static routes table in the RIB.  This has potential for hiding errors.

A more elegant solution might be to explicitly state protocols and in 
the RIB section of the configuration file.  So when the RIB starts, 
origin tables are added for named protocols and administrative 
distances associated with the protocols too.  This would make the table 
names visible in the configuration file and make it easier to enable 
redistribution (since one doesn't have to guess or know existing table 
names) and we would no longer have to have hard-coded admin distances 
in the RIB.

We could go one step further by having protocol sections state which 
origin tables they will provide routes to.  This makes the RIB origin 
table relations explicit.

Does this seem reasonable?
	Orion