Subject: RE: AD comments on draft-ietf-ipv6-router-selection-02.txt

From: "Richard Draves" <[email-masked]>
Date: Thu, 1 Aug 2002 11:49:42 -0700

> Hmm.... the IPv6 neighbor discovery says that after probes 
> fail, entry should be removed, see RFC-2461 7.3.3
> 
>    Upon entering the PROBE state, a node sends a unicast Neighbor
>    Solicitation message to the neighbor using the cached link-layer
>    address.....
>    ..... If no response is received after waiting RetransTimer
>    milliseconds after sending the MAX_UNICAST_SOLICIT solicitations,
>    retransmissions cease and the entry SHOULD be deleted.

I think to implement router-selection, you need to keep track of whether
a router is reachable or unreachable. Whether that's in the Neighbor
Cache Entry or not and how it interacts with the ND states is an
implementation concern that is not specified in the draft.

Note that RFC 2461 does not really say that implementations should
delete a data structure, it is saying that implementations should behave
as if the conceptual data structure were deleted. RFC 2461 is a protocol
spec not an implementation spec.

> As to 3.4 in internet-drafts/draft-ietf-ipv6-router-selection-02.txt,
> it talks only about routers X and Y.
> 
> Playing nasty, I imagine situation where I have routers X, Y 
> and Z (with prefix lengths X > Y > Z) and destination 
> matching all of them. Now, if only Z is currently reachable, 
> I should probably probe both X and Y using some logic...

Yes both X & Y should be probed. I think section 3.4 implies that,
although it could be clarified. Section 3.4 says "When a host avoids
using a non-reachable router X ..." - it's quite possible for this
clause to apply to more than one router.

Rich

--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------

---

From: Erik Nordmark <[email-masked]>
Date: Thu, 1 Aug 2002 19:55:44 +0200 (CEST)

3.4. Router Reachability Probing 

   When a host avoids using a non-reachable router X and instead uses 
   another router Y, and the host would have used router X if router X 
   were reachable, then the host SHOULD probe router X's reachability 
s/were/was/

   by sending a Neighbor Solicitation. A host MUST NOT probe a router's 
   reachability in the absence of useful traffic that the host would 
   have sent to the router if it were reachable. In any case, these 
   probes MUST be rate-limited to no more than one per minute per 
   router. 

"probe" isn't well-defined. There are two possible interpretations:
1. Send a single unicast neighbor solicitation
2. Do what RFC 2461 does when in the PROBE state (implies retransmitting NS
   messages N times)

I think #1 is the intent; it would make sense to state that explicitly.

   Erik

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 17 Aug 2002 17:10:28 +0900

(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-masked]> 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-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------