Re: [dna] Review of draft-ietf-dna-simple-11

[Erik Nordmark <[e-mail]>]

Bernard Aboba wrote:
> Ted Lemon said:
> 
> "More, from section 4.3:
> 
>   It SHOULD also set all Neighbor
>   Cache entries for the routers on its Default Router List to STALE.
>   This is done to speed up the acquisition of a new default router when
>   link change has occurred.
> 
> It's my impression that by default, a stale routing table entry won't
> be used, so if an application writes to an open tcp connection while
> the routing table entry is stale, it will get an EHOSTUNREACH, and the
> connection will be dropped.  I have had this exact experience with
> IPv4 DNA implementations when my WiFi router signal is flaky.  This is
> much worse than taking a long time (500ms isn't really that long) to
> identify a new link.
> 
> This would also be a problem in the case where you are on a WiFi
> network with more than one device advertising the same SSID - when you
> switch to a new beacon, arguably this is a DNA event, but it would clearly
> be a mistake to break existing connections in this case.
> 
> [BA] I agree that the paragraph cited does not make sense.  RFC 4436 does
> not contain equivalent advice.  In general, Simple DNAv6 should seek to 
> minimize connectivity disruption. 

Perhaps the reference to "STALE" is not clear above?
STALE refers to a state in RFC 4861 which implies that the host would 
trigger NUD sooner rather than later. If it isn't set to STALE then it 
might take up to 30 seconds more to detect that a router has gone dead. 
Thus a neighbor cache entry of STALE doesn't have anything to do with a 
routing table entry (unless the implementation is broken.)

    Erik