Re: [DNA] Text on Router Reachability for draft-ietf-dna-protocol

[James Kempf <kempf@docomolabs-usa.com>]

> some comments relating to the text you proposed for inclusion in
> draft-ietf-dna-protocol-00.txt.
>
> Neither RFC2461 nor RFC2462bis specify that a MN should prefer a default
> router with a corresponding NC entry in REACHABLE state over a default
> router with a NC entry in STALE, DELAY, or PROBE state.  This a bit
> unfortunate and should be fixed IMO.
>

RFC 2641 says this in Section 6.3.6:

     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).
        An implementation may choose to always return the same router or
        cycle through the router list in a round-robin fashion as long
        as it always returns a reachable or a probably reachable router
        when one is available.

So, in effect, this proposal is to tighten the definition up.

> In your text, the MN sets the NC entry for a previous default router to
> STALE state in case it does not receive a solicited RA from that router.
> This implies that the MN must wait a little while, after sending the
> RS, until it can be sure that no more RAs will be received.
>
> The procedure outlined below would faster because the MN selects a new
> default router immediately when it gets the first RA:
>
> (a)  Receive a trigger indicating a change in L2 attachment.
>
> (b)  Set all NC entries corresponding to routers in the Default Router
> List to STALE state.
>
> (c)  Send an RS.
>
> (d)  For each received unicast RA, add the sender of the RA to the
> Default Router List, if need be, and set the corresponding NC entry to
> REACHABLE state (as specified in section 5.2.5 of
> draft-ietf-dna-protocol-00.txt).
>
> (e)  At all times, prefer a default router with a NC entry in REACHABLE
> state over a default router with a NC entry in STALE, DELAY, or PROBE 
> state.
>

To really accelerate router selection, the following needs to be added:

(f) In order to reduce the delay in achieving IP connectivity, reset the 
chosen default router to the router in the first RA received after the RS is 
sent.


> Note that step (b) does not prevent a MN from sending packets to its
> current default router.  If the current default router is still
> reachable, it will forward the packets.  Step (b) does not even imply
> that the MN sends an NS (as part of NUD) for the current default router
> if that router is still reachable.  This is because the NS is deferred
> for 5 seconds (DELAY_FIRST_PROBE_TIME), and a solicited RA meanwhile
> received from the current default router would abort the 5-seconds timer
> and set the NC entry for the current default router to REACHABLE.
>

OK.

> Also, in case the MN did not change L3 connectivity, the new default
> router is likely to be the same as the previous default router, given
> the algorithm for sending FastRAs.
>
> Finally, the procedure outlined above is easier to implement:  The MN
> does not need to remember from which router it gets an RA until it sets
> the NC entries for routers, from which it did not get an RA, to STALE 
> state.
>

Any objections from other WG members to modifying the text I sent to 
incorporate Christian's changes?

            jak