From owner-freebsd-net@FreeBSD.ORG Wed Apr 30 18:47:30 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90BB2106564A for ; Wed, 30 Apr 2008 18:47:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outZ.internet-mail-service.net (outz.internet-mail-service.net [216.240.47.249]) by mx1.freebsd.org (Postfix) with ESMTP id 6C1978FC23 for ; Wed, 30 Apr 2008 18:47:30 +0000 (UTC) (envelope-from julian@elischer.org) Received: from mx0.idiom.com (HELO idiom.com) (216.240.32.160) by out.internet-mail-service.net (qpsmtpd/0.40) with ESMTP; Wed, 30 Apr 2008 17:04:40 -0700 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id A90012D6006; Wed, 30 Apr 2008 11:47:29 -0700 (PDT) Message-ID: <4818BEC4.7060800@elischer.org> Date: Wed, 30 Apr 2008 11:47:32 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Bruce M Simpson References: <20080429185100.57C2445010@ptavv.es.net> <4817743B.6090107@elischer.org> <48178452.4050700@FreeBSD.org> <4817881B.7010409@elischer.org> <4818926F.8010309@incunabulum.net> <4818AB9F.7000607@elischer.org> <4818B58B.3050400@incunabulum.net> In-Reply-To: <4818B58B.3050400@incunabulum.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Net , Kevin Oberman Subject: Re: multiple routing tables review patch ready for simple testing. X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2008 18:47:30 -0000 Bruce M Simpson wrote: > Julian Elischer wrote: >> >> what's SSM? > > Source-specific multicast, where multicast flows (channels) are > identified by both their original source address, and group address. > Multicast addresses have no meaning on their own beyond the scope of a > single link. > >> I haven't changed any of that.. Basically I've kept clear of >> M/Cast. The way I see it, if you don't define ROUTETABLES=2 (or more) >> or don;t define it at all in your config then you get what you had >> before and I shouldn't have broken anything. > > Cool! Doing multicast "right" is Hard. Doing it "right" in ad-hoc > topologies is Harder. > > It makes sense to steer clear of it for now. It can no doubt benefit > from the hierarchy offered by multiple FIBs, but again, the policy > routing mechanisms don't really exist just now, and things like PIM need > changes to encompass it. > > They will need to come into existence for the model to work on a macro > scale, for the same reason SSM was put on the table. > >> >> I take it from this that you don't have any major complaints >> as far as what I've done. > > No problems here... I haven't tried testing. please please do.. just apply the patch to a regular source tree and compile.. :-) > > I would say though if we are going to be renaming rtalloc() and friends, > that names should really change to be descriptive of what it does. > It doesn't "allocate a route", it tries to look up a forwarding table > entry, and returns a reference to it. It's important to not break source compatibility for 3rd party suppliers and users. (e.g. ironport, juniper, nokia, issilon, etc. etc.) they know about rtalloc... having said that I do plan on a pass over the code to rationalise some of the names that may have "evolved" during developement of the patch. > > cheers > BMS