resend: multiple routing table roadmap (format fix)

[Andre Oppermann]

Vadim Goncharov wrote:
> 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...

Locking hell over again.  How do you remove an ARP entry without doing
a full walk over the entire routing table (some 250K entries for the
DFZ)?  Make it rmlocks and be done with it.

-- 
Andre