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

[Christian Vogt <chvogt@tm.uka.de>]

Hi James.

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

Certainly.  I meant to say that the tighened definition actually belongs
into RFC2461bis, rather than into the DNA protocol, and should be
updated there IMO.  But it won't really make a difference in the end
anyway, and the IPv6 WG might be unwilling to modify RFC2461bis yet
another time at this stage.

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

This should come as a natural consequence of (a) through (e):  After
step (b), all router entries in the NC are in STALE state.  Hence, since
the MN obeys (e) "at all times", it will reset its default router
immediately after receiving the first RA, because the NC entry for that
default router will be the only one in REACHABLE state.

When the MN received more RAs, it won't change its default router again,
because its current default router is already in REACHABLE state.

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

- Christian

-- 
Christian Vogt, Institute of Telematics, University of Karlsruhe
www.tm.uka.de/~chvogt/pubkey/