multiple routing tables review patch ready for simple testing.

[Julian Elischer]

Bruce M Simpson wrote:
> Julian Elischer wrote:
>> An interface may however be present in entries from multiple FIBs
>> in which case the INCOMING packets on that interface need to
>> be disambiguated with respect to which FIB they belong to.
> 
> Yes, there is no way the forwarding code alone can do this.
> 
> It should not be expected to, and it's important to maintain a clean 
> functional separation there, otherwise one ends up in the same quagmire 
> which has been plaguing a lot of QoS research projects over the years 
> (Where do I put this bit of the system?)
> 
>>
>> This is a job for an outside entity (from the fibs).
>> In this case a packet classifier such as pf or ipfw is ideal
>> for the job. providing an outside mechanism for implementing
>> whatever policy the admin wants to set up.
> 
> Absolutely. This has been the intent from the beginning.
> 
> There is no "one size fits all" approach here. We could put a packet 
> classifier into the kernel which works just fine for DOCSIS consumer 
> distribution networks, but has absolutely no relevance to an ATM 
> backbone (these are the two main flavours of access for folk in the UK).
> 
>[...]

>> It
>> IS possible that an interface in the future might have a default
>> plane, but I haven't implemented this.
> 

> This limitation seems fine for now.
[...]


> 
>    For SSM, the key (S,G)

what's SSM?
[...]


> To summarize:
>    For now, the limitations of the system should be documented so that 
> users don't inadvertently configure local forwarding loops, even for 
> unicast traffic; with multicast, the amplification effect of 
> misconfiguration is inherently more damaging to a network.

I'm not sure where I should add documentation.
I haven't found the exact right place yet..
I have some notes but I haven't found a good place to put them

> 
> cheers
> BMS
> 
> P.S. I see you tweaked verify_path() to do the lookup in the numbered 
> FIB. Cool.
> 
> I should point out that for ad-hoc networks, the ability to turn off 
> RPF/uRPF for multicast is needed as the routing domain is often NOT 
> fully converged -- so the RPF checks normally present may discard 
> legitimate traffic which hasn't been forwarded yet. An encapsulation is 
> typically used to maintain forwarding state which is relevant to the 
> particular topology in use.

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.

I take it from this that you don't have any major complaints
as far as what I've done.

I'd like to get a few people to apply the diff and try it
(more than just me for sure), and then I'd like to get it committed 
soon so that I can move on with it.  I would like to get what is
there now commited becasue it is a logical break before moving to
more work.  What is there is fully functional and consistent.
and should be tested before more extensive changes occur
so that we know where to look if there are problems.