> > => 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. > > No, I am talking about the case of multiple routers on the *same* > link in which the host may prefer some on-link routers over others > for reasons beyond the scope of the spec.
=> Ok, that's fine, but how do you these routers: a) exist, and b) are working, i.e. not down. Shouldn't you at least know this before you prefer a router? Hesham That is why I would like > to see the simple "etc" added; it gives flexibility for the host > to prefer some on-link routers over others in its default router > selection process. > > Fred > [EMAIL PROTECTED] > > -----Original Message----- > From: Soliman, Hesham [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 20, 2006 1:37 PM > To: Templin, Fred L; ipv6@ietf.org > Subject: RE: RFC2461(bis), section 6.3.6 > > > > > > 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 --------------------------------------------------------------------
