Hesham, > => 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?
In one example, the host could send a multicast RS and get back RAs from several different routers. The host could then use L2 information (e.g., RSSI) to infer that some of the routers have better link quality than others and prefer those in its default router selection. This is just one example (and beyond the scope of the spec) but it illustrates the desire to allow hosts more flexibility in deciding which routers are good and which are "suspect". Fred [EMAIL PROTECTED] -----Original Message----- From: Soliman, Hesham [mailto:[EMAIL PROTECTED] Sent: Thursday, April 20, 2006 3:04 PM To: Templin, Fred L; ipv6@ietf.org Subject: RE: RFC2461(bis), section 6.3.6 > > => 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 --------------------------------------------------------------------
