[Xorp-hackers] Soft-wiring RIB

[Pavlin Radoslavov]

> 
> On May 7, 2004, at 16:30, Pavlin Radoslavov wrote:
> >> 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.
> >
> > I am missing some of the details here, hence can you provide an
> > example (e.g., a sample config section) so it can become clearer to
> > me.
> 
> Okay, so the explicit naming in the protocols section is avoid any 
> confusion between process names and their functionality, ie the 
> "static_routes" process populates the various "static" tables in the 
> rib.  The config might look something like:
> 
> rib {
> 	tables {
> 		ipv4 {
> 			unicast {
> 				protocol connected
> 				protocol static
> 				protocol rip
> 				protocol ospf
> 				protocol ebgp
> 			}
> 		}
> 		ipv4 multicast {
> 				...
> 		}
> 	}
> 	protocols {
> 		connected {
> 			admin_distance 0
> 		}
> 		static {
> 			admin_distance 1
> 		}
> 	}
> }
> 
> protocols {
> 	rip {
> 		populates ipv4 unicast rip
> 		... RIP specific config ...
> 		import ipv4 unicast static {
> 			metric 1
> 			tag 1
> 		}
> 		import ipv4 unicast connected {
> 			metric 0
> 			tag 0
> 		}
> 	}
> 
> 	static_routes {
> 		populates ipv4 unicast static
> 		... static routes ...
> 	}
> }

I think this is a very good idea.


> This is just one incarnation and it places some overhead on the user 
> unless there's a standard configuration include file.

Can't we "hide" the default setup in the rtrmgr template files?
Thus, the user doesn't need to do anything in the config files.
Only if the default setup is not adequate, then it can be modified
by the user within the config file.

Pavlin