Date: Sun, 06 Jan 2008 10:10:07 -0800 From: Julian Elischer <julian@elischer.org> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: Qing Li <qingli@freebsd.org>, FreeBSD Net <freebsd-net@freebsd.org>, Vadim Goncharov <vadim_nuclight@mail.ru>, arch@freebsd.org, Ivo Vachkov <ivo.vachkov@gmail.com>, Robert Watson <rwatson@freebsd.org> Subject: Re: resend: multiple routing table roadmap (format fix) Message-ID: <4781197F.1000105@elischer.org> In-Reply-To: <4780E5E7.2070202@FreeBSD.org> References: <4772F123.5030303@elischer.org> <f85d6aa70712261728h331eadb8p205d350dc7fb7f4c@mail.gmail.com> <477416CC.4090906@elischer.org> <opt4c0imk24fjv08@nuclight.avtf.net> <477D2EF3.2060909@elischer.org> <opt4g4kcis17d6mn@nuclight.avtf.net> <4780E5E7.2070202@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4781197F.1000105>