cvs commit: src/sys/conf files options src/sys/net radix.c radix.h route.c route.h rtsock.c src/sys/netinet in_proto.c ip_output.c src/sys/netinet6 in6_proto.c in6_src.c nd6_nbr.c

[Bruce M. Simpson]

Qing Li,

First of all thanks for doing this. It would have been nice to have had 
some advance warning though.

Qing Li wrote:
>> How does this behave with common routing daemons; 
>> Quagga/Zebra, OpenBGPD, OpenOSPFD?  
>>     
>
> 	Hmm... Good question, I haven't tried them but
> 	I will.  Is this something you could help me
> 	with ?
>   

I'm surprised XORP hasn't been mentioned here, so I'll mention it now...

For what it's worth this should not make any operational changes to 
XORP's behaviour, it already plumbs routes to the FIB from its RIB with 
the next-hop field, and always parses the next-hop in any PF_ROUTE 
messages it sees. I can't speak for the others.

Questions:
 * So, does this RADIX_MPATH code originate from KAME?
 * If so, to what extent does it share heritage with the OpenBSD code?

I looked at this stuff in some depth last year, with a view to 
implementing new forwarding code. However without a source of ongoing 
financial support it was difficult to make real progress with anything, 
and other things came onto my plate at that stage.

It will be useful as a baseline for other work, in particular removing 
the 32 (S,G) channel limitation from the multicast forwarding code -- 
with such a change it would be possible to move multicasting into the 
usual radix trie lookup by adding a new flag which says "flood this to 
all next-hops specified as AF_LINK sockaddrs".

We really need to get ARP out of there now. :-) It would be nice if 
rt_mpath_matchgate() used the sa_dl_equal() macros from if.c, it reads a 
bit quirky.

The questions you raise about ownership of FIB entries bear some 
scrutiny. Microsoft, for example, are pretty strict about only exposing 
the forwarding table to consumers which are willing to play by all rules 
of the API. What they have could be termed a RIB in of itself, you never 
get to interact with the forwarding tables directly outside of the 
TCPIP.SYS driver, except for read-only access e.g. SNMP. There is 
locking capability in their API.

At the moment in the open source sphere what we have are mechanisms 
which build on top of this in userland (e.g. the quagga approach), or 
things which push these issues into a lower layer (such as the Linux 
rtnetlink socket).

It really is worth looking at Linux, rtnetlink has an informational RFC, 
it uses a tag-length-value protocol which addresses a number of the 
issues blocking further progress in this area, and whilst we can't take 
the code, the design, and the idea, are not subject to the GPL -- 
particularly so given the informational RFC status.

cheers
BMS