> > Yes, this is the passage I am concerned with. The point is > that (in some environments) not all routers on the link will > be equivalent, e.g., some routers may exhibit better QoS than > others due to different signal-to-noise ratios, queue lengths, > etc. > > In those cases, hosts may prefer some routers over others > for reasons that are not related to: "...in the INCOMPLETE > state, or for which no Neighbor Cache entry exists". Adding > the "etc" allows for other cases in which reachability of > some routers is "suspect".
=> I agree with your scenario, however, I think the "preference" of one *link* over another that you refer to happens before this text becomes effective. For example, you might prefer link A over link B because you think link-layer A suits you more. If you do, you will first need to make sure router A is reachable before you make it your default router. In other words, you can't automatically translate a link layer preference to a router preference. In the example I just gave, link-layer A would not be useful if router A is down; despite preferring link-layer A, you would still make router B your default router. So in summary, you first want to make sure that the router is reachable before you start applying other metrics for preferring it over another router. Hesham > > Fred > [EMAIL PROTECTED] > > -----Original Message----- > From: Soliman, Hesham [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 20, 2006 12:51 PM > To: Templin, Fred L; ipv6@ietf.org > Subject: RE: RFC2461(bis), section 6.3.6 > > Fred > > I assume you're referring to this : > > 1) Routers that are reachable or probably reachable > (i.e., in any > state other than INCOMPLETE) SHOULD be preferred over routers > whose reachability is unknown or suspect (i.e., in the > INCOMPLETE state, or for which no Neighbor Cache > entry exists). > Further implementation hints on default router selection when > multiple equivalent routers are available are discussed in > [LD-SHRE]. > > Can you please elaborate on what this change will do and why > it is more > inclusive? just trying to understand. > > I'll add in the reference for [LD-SHRE], thanks. > > Hesham > > > ________________________________ > > From: Templin, Fred L [mailto:[EMAIL PROTECTED] > Sent: Wednesday, April 19, 2006 11:57 AM > To: ipv6@ietf.org > Subject: RFC2461(bis), section 6.3.6 > > > I would like to see something a bit more inclusive in > (RFC2461(bis), > section 6.3.6) for default router selection when not all routers > on the > link are equivalent, e.g., when a wireless host sees routers > with > varying link quality. Suggestion is to simply change: > > INCOMPLETE state, or for which no Neighbor Cache entry > exists). > to: > INCOMPLETE state, for which no Neighbor Cache entry exists, > etc.). > > This could either go in the next draft version or as an AUTH48 > item. > (Also the reference for [LD-SHRE] is missing.) > > Fred > [EMAIL PROTECTED] > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
