[Xorp-hackers] Soft-wiring RIB

Mark Handley M.Handley@cs.ucl.ac.uk
Sat, 08 May 2004 09:42:43 +0100


>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.

This is an interesting and tricky problem.

As far as possible, I think the user interface should hide the
internal breakdown of functionality between processes.  This means the
user should not be aware of the existence of a RIB *process* or FEA
process, as these are merely the internal plumbing that exists behind
the scenes.  Of course the user probably is aware that there is RIB
functionality somewhere, at least once they understand about the
concept of administrative distance.

With this in mind, we need to be somewhat careful to only expose
functional configuration, not internal configuration.  For me, the
names of OriginTables in the RIB are internal information, and
shouldn't be visible to the CLI.  However, *requiring* configuration
of administrative distance would be OK, although it seems better to
let this default, because 95% of users don't understand the concept
well enough to choose values that don't shoot themselves in the foot
(at least according to the Cisco advice on setting admin distance).

On balance, I think your first solution (a redist request creating the
OriginTable if none exists) is probably the best solution from the
user's point of view.

Cheers,
	Mark