(Since implementors' comments are required, I'll talk about a
particular network stack; the one in BSDs.)
>>>>> On Thu, 25 Jul 2002 08:43:49 -0400,
>>>>> Thomas Narten <[EMAIL PROTECTED]> said:
>> 3.3. Destination Cache Management
>>
>> When host C processes a Router Advertisement and updates its
>> conceptual Routing Table, it SHOULD invalidate or remove Destination
>> Cache Entries and redo next-hop determination for destinations
>> affected by the Routing Table changes. The host MAY implement this
>> requirement by flushing its entire Destination Cache.
> Seems like the above SHOULD should be a MUST, in order to meet the
> principle of least astonishment.
> However, the MAY seems ill-advised, as the Destination Cache may also
> include other information (e.g., path MTU info?) that should not be
> flushed as a side-effect of such a route change. Can the above be
> implemented reasonably without resorting to just flushing the table
> and rebuilding whenever a change is present?
Based on my knowledge and experiences of BSD's routing architecture,
this should be able to be implemented without much side effect in
BSDs; we can prune a subtree, where destination caches exist, of the
affected route entry in the tree-based routing table.
> 4) I'm also unclear as to how easy it will be to implement the
> specific lookup algorithm that type C hosts will implement. My
> understandinng is that routing lookups today are done using
> longest-match, where the lookup stops at a particular node in the
> tree. I could imagine multiple nodes being at the same point in the
> tree (i.e., corresponding to two or more instances of a prefix but
> using different routers with possibly different preferences).
> But the algorithm specified actually says reachable routers are to be
> preferred over unreachable ones. This means that the longest-match
> lookup may stop at a node with an unreachable router. What is done in
> this case? Does one have to unwind the tree search to try a node
> visited earlier (i.e., a shorter match?)? Is this reasonable for
> implementations? [note: its not immediately clear that one can just
> remove nodes from the routing tree that correspond to unreachable
> routers, because one must also probe these routers in some cases.]
> Another implementation complexity is due to the preferences combined
> with the reachability status. Many implementations have a user-level
> process which takes preferences into account and only installs the
> most preferred route for a given prefix into the kernel. Hence the
> kernel need not be aware of preferences. Given the reachability status
> all routes need to be in the kernel since the most preferred for a
> given prefix might be unreachable and a less preferred route might
> exist for the identical prefix.
> Q: who has implemented this draft? Can they comment on the
> implementations issues mentioned above?
The issue 4 would have very strong impact on BSD's routing
architecture. It seems to me that will require a total revise of the
architecture, and I don't think the BSD community accepts it just
because of the merits described in the draft. Actually, we'd rather
choose to run routing protocols than changing the basic routing
architecture in the kernel. (I know the draft mentions the issue of
routing protocols vs RAs, but the benefit of RAs is not convincing
enough comparing to the complexity - at least to me.)
Honestly, it seems to me that the "more specific routes" part of the
draft is quite complicated, and I wonder how large the applicability
is, particularly from implementor's point of view. For very poor
environments, implementors would skip this part due to the complexity.
For some rich/powerful stack, such as BSDs, implementors would rather
run routing protocols as I said above.
To be clear, I'm not making a strong objection to advance the draft
just from the limited, personal thoughts. I've described my view on
this as required, and I'm also interested how other implementors think
of it.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
