multiple routing tables review patch ready for simple testing.

[Julian Elischer]

Bruce M Simpson wrote:
> Julian Elischer wrote:
>>
>> what's SSM?
> 
> Source-specific multicast, where multicast flows (channels) are 
> identified by both their original source address, and group address. 
> Multicast addresses have no meaning on their own beyond the scope of a 
> single link.
> 
>> 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.
> 
> Cool! Doing multicast "right" is Hard. Doing it "right" in ad-hoc 
> topologies is Harder.
> 
> It makes sense to steer clear of it for now. It can no doubt benefit 
> from the hierarchy offered by multiple FIBs, but again, the policy 
> routing mechanisms don't really exist just now, and things like PIM need 
> changes to encompass it.
> 
> They will need to come into existence for the model to work on a macro 
> scale, for the same reason SSM was put on the table.
> 
>>
>> I take it from this that you don't have any major complaints
>> as far as what I've done.
> 
> No problems here... I haven't tried testing.

please  please do..

just apply the patch to a regular source tree and compile.. :-)

> 
> I would say though if we are going to be renaming rtalloc() and friends, 
> that names should really change to be descriptive of what it does.
> It doesn't "allocate a route", it tries to look up a forwarding table 
> entry, and returns a reference to it.

It's important to not break source compatibility for 3rd party 
suppliers and users. (e.g. ironport, juniper, nokia, issilon, etc. etc.)

they know about rtalloc...

having said that I do plan on a pass over the code to rationalise some 
of the names that may have "evolved" during developement of the patch.


> 
> cheers
> BMS