From owner-cvs-all@FreeBSD.ORG Thu Apr 17 07:02:55 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 3A3DE1065674 for ; Thu, 17 Apr 2008 07:02:55 +0000 (UTC) (envelope-from qingli@speakeasy.net) Received: from mail5.sea5.speakeasy.net (mail5.sea5.speakeasy.net [69.17.117.7]) by mx1.freebsd.org (Postfix) with ESMTP id 0FBF78FC16 for ; Thu, 17 Apr 2008 07:02:54 +0000 (UTC) (envelope-from qingli@speakeasy.net) Received: (qmail 7780 invoked from network); 17 Apr 2008 07:02:54 -0000 Received: from dsl081-051-177.sfo1.dsl.speakeasy.net (HELO SAINTS) (qingli@[64.81.51.177]) (envelope-sender ) by mail5.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 17 Apr 2008 07:02:54 -0000 From: "Qing Li" To: "'Bruce M. Simpson'" References: <200804130545.m3D5jEtd081771@repoman.freebsd.org> <4803D7E2.80000@freebsd.org> <000201c89eae$d4dcfe10$b1335140@SAINTS> <48047442.1030609@FreeBSD.org> Date: Thu, 17 Apr 2008 00:03:00 -0700 Message-ID: <004901c8a059$135ffb50$b1335140@SAINTS> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <48047442.1030609@FreeBSD.org> Thread-Index: Acie2nyRXqvDoL9GR+6s6KSqi024jwBfB6Ig Cc: 'Qing Li' , src-committers@FreeBSD.org, 'Andre Oppermann' , cvs-all@FreeBSD.org, cvs-src@FreeBSD.org Subject: RE: multipath stuff 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: Thu, 17 Apr 2008 07:02:55 -0000 Hi Bruce, > > First of all thanks for doing this. It would have been nice > to have had some advance warning though. > Hopefully it wasn't too much of a grief ... > > 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. > I was hoping that would be the case, and that should be how it's done in theory, no ? > > Questions: > * So, does this RADIX_MPATH code originate from KAME? > Yes, this work originated from the KAME project. > > * If so, to what extent does it share heritage with the OpenBSD code? > I don't know much about the OpenBSD code and never looked at that branch. What I do know, is the original code from KAME worked on all except FreeBSD, at least that was the case when I did the initial work in FreeBSD 5.4, and the original code has not changed for quite some time even before that. The bulk of the addition/change is actually in route.c With the original code, the box would boot-up and crash immediately. If my memory serves me right, the crash was due to the address alias was not being properly taken care of. Also in the original code, the deletion did not really work and also crashed often. > > 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". > That would be good. I'd like to learn more about what you have in mind and would be happy to help you out on that front. > > We really need to get ARP out of there now. :-) > Yes. I am going to be focused on getting this work revised and hope to wrap it up in a couple of weeks. Julian is helping me out on the debugging and testing front. > > It would be nice if rt_mpath_matchgate() used the sa_dl_equal() macros > from if.c, it reads a bit quirky. > I will update the code. Thanks. > > 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. > I am going to postpone this discussion until I get done with the new ARP work. However, one thing I do want to mention, is I doubt one can get the proper entries out of the table using SNMP because I do know the forwarding table MIB is and has been broken for years. The table does not support these concepts with the proper table index. > > 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. > Interesting. Is this the RFC you are referring to ? 3549 Linux Netlink as an IP Services Protocol. J. Salim, H. Khosravi, A. Kleen, A. Kuznetsov. July 2003. (Format: TXT=72161 bytes) (Status: INFORMATIONAL) -- Qing