From owner-cvs-all@FreeBSD.ORG Tue Apr 15 09:24:21 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 47AF7106564A; Tue, 15 Apr 2008 09:24:21 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com [66.111.4.25]) by mx1.freebsd.org (Postfix) with ESMTP id EF8BB8FC0A; Tue, 15 Apr 2008 09:24:20 +0000 (UTC) (envelope-from bms@FreeBSD.org) Received: from compute1.internal (compute1.internal [10.202.2.41]) by out1.messagingengine.com (Postfix) with ESMTP id 87D7BFF5EA; Tue, 15 Apr 2008 05:24:20 -0400 (EDT) Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by compute1.internal (MEProxy); Tue, 15 Apr 2008 05:24:20 -0400 X-Sasl-enc: A8cOXBa9T+BICfyXm7DJwZF7nTMkaKvW8q547AL0vlxG 1208251460 Received: from empiric.lon.incunabulum.net (82-35-112-254.cable.ubr07.dals.blueyonder.co.uk [82.35.112.254]) by mail.messagingengine.com (Postfix) with ESMTPSA id 6E1AFE09A; Tue, 15 Apr 2008 05:24:19 -0400 (EDT) Message-ID: <48047442.1030609@FreeBSD.org> Date: Tue, 15 Apr 2008 10:24:18 +0100 From: "Bruce M. Simpson" User-Agent: Thunderbird 2.0.0.12 (X11/20080405) MIME-Version: 1.0 To: Qing Li References: <200804130545.m3D5jEtd081771@repoman.freebsd.org> <4803D7E2.80000@freebsd.org> <000201c89eae$d4dcfe10$b1335140@SAINTS> In-Reply-To: <000201c89eae$d4dcfe10$b1335140@SAINTS> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: 'Qing Li' , src-committers@FreeBSD.org, 'Andre Oppermann' , cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: Re: 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 X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Apr 2008 09:24:21 -0000 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