From owner-freebsd-arch@FreeBSD.ORG Sun Jan 6 18:09:52 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4276116A419 for ; Sun, 6 Jan 2008 18:09:52 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outD.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 33EF413C45A for ; Sun, 6 Jan 2008 18:09:52 +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; Sun, 06 Jan 2008 10:09:51 -0800 Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id C6FA5126E1D; Sun, 6 Jan 2008 10:09:50 -0800 (PST) Message-ID: <4781197F.1000105@elischer.org> Date: Sun, 06 Jan 2008 10:10:07 -0800 From: Julian Elischer User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: "Bruce M. Simpson" References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <4780E5E7.2070202@FreeBSD.org> In-Reply-To: <4780E5E7.2070202@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Qing Li , FreeBSD Net , Vadim Goncharov , arch@freebsd.org, Ivo Vachkov , Robert Watson Subject: Re: resend: multiple routing table roadmap (format fix) X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2008 18:09:52 -0000 Bruce M. Simpson wrote: > Vadim Goncharov wrote: >> >> Is multicast and multipath routing the same? > > No. They are currently orthogonal. > > However it makes sense to merge the multicast and unicast forwarding > code as currently MROUTING is limited to a fan-out of 32 next-hops only. > In multicast, next-hops are normally just interfaces. > > Also the IETF MANET ad-hoc IP is going to need hooks there; multicast in > MANET needs to address its next-hops by their unicast address, and > encapsulate the traffic with a header. This is not true link layer > multicast -- although it might use link layer multicast to leverage the > hash filters in 802.11 MACs. > > As regards getting ARP out of forwarding tables, this should have > happened a long time ago... I'm not 100 % convinced of this... I was, but I think there may still be a place for a cached arp pointer in hte next hop route to the arp entry for that next hop. I DO however thing that the arp stuff should nto be accessing its data via the routing table. > > BMS