Thanks for your detailed response. I have included my comments to the
you have raised below :
> > - Routing table will have lots of address prefixes that are not
> > to the local interface addresses.
> Well, all the direct routes are prefixes by definition.
I had written in my previous mail "More code needs to be present to parse
entry in this case.", which is what I think you have also implied. Eg, for
routing entry, you need to make sure it is the same device, that it is not
Link Local destination, and there is no 'next hop' field.
> > - To be a prefix list entry, it should come via an RA.
> Wrong. But this does not matter, RA routes may be tagged with a flag.
I disagree about the first part :-) A user can add an address with a new
prefix, but that should not be present in the list of prefixes supported
on that subnet. The prefix list should contain elements that a RA has
advertised as part of the prefixes that the router supports. The RFC is
specific about how prefix list entries are to be created (eg 6.3.4).
Regarding the second point you made about the 'flag', I agree with you, and
I did say something to that effect in my previous mail :
"Then the only solution to figure out that this is not a real
entry would involve more code to determine if this is an RA added
routing entry or a manual one."
> > - Also, the search over a longer routing table across all nodes is
> > time consuming.
> Do you jest? You compare linear search with lookup in radix tree. :-)
Since there is no key to lookup, you have to always walk the entire tree
key is an address/prefix, but we don't have it). I think it would be faster
the case where the routing table is very large, and there aren't too many
interfaces (haven't defined "too many" here :-). The number of prefixes on
interface is not important for the search property.
The difference is that in case of routing table lookup, you go through the
entire tree and parse each entry, while in the proposed approach, the
search is only done to locate the 'dev' and then the work is more
straightforward - return all entries after getting the correct 'dev'.
I agree that the Prefix List could be implemented on either the idev list
the routing table, we just need to agree which is better place to put the
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
This archive was generated by hypermail 2b29 : Sat Aug 31 2002 - 22:00:01 EST