From owner-freebsd-net@FreeBSD.ORG Sun Jan 6 21:03:18 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 B4CD816A419; Sun, 6 Jan 2008 21:03:18 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from mx40.mail.ru (mx40.mail.ru [194.67.23.36]) by mx1.freebsd.org (Postfix) with ESMTP id 7682113C458; Sun, 6 Jan 2008 21:03:18 +0000 (UTC) (envelope-from vadim_nuclight@mail.ru) Received: from [78.140.2.250] (port=25243 helo=nuclight.avtf.net) by mx40.mail.ru with esmtp id 1JBceK-000PPB-00; Mon, 07 Jan 2008 00:03:16 +0300 Date: Mon, 07 Jan 2008 03:03:11 +0600 To: "Julian Elischer" , "Bruce M. Simpson" References: <4772F123.5030303@elischer.org> <477416CC.4090906@elischer.org> <477D2EF3.2060909@elischer.org> <4780E5E7.2070202@FreeBSD.org> <4781197F.1000105@elischer.org> From: "Vadim Goncharov" Organization: AVTF TPU Hostel Content-Type: text/plain; format=flowed; delsp=yes; charset=koi8-r MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: In-Reply-To: <4781197F.1000105@elischer.org> User-Agent: Opera M2/7.54 (Win32, build 3865) Cc: arch@freebsd.org, Qing Li , Ivo Vachkov , Robert Watson , FreeBSD Net Subject: Re: resend: multiple routing table roadmap (format fix) 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: Sun, 06 Jan 2008 21:03:18 -0000 07.01.08 @ 00:10 Julian Elischer 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. Surely, routing table should contain a cached pointer to an entry in L2 table (ARP in case of Ethernet), to not do double lookups. But still separate those tables... -- WBR, Vadim Goncharov