Hesham,

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".

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

Reply via email to