Re: [DNA] Model: how to treat "link down" events

[Erik Nordmark <erik.nordmark@sun.com>]

Thomas Narten wrote:
> In thinking through this, one thing that is not clear to me is what
> the model is for what to do when a "link down" event takes place. This
> is actually important to understand as it plays into how to handle
> "link up" events.

This discussion might be interesting, but I'm not sure it is critical or 
even relevant to DNS, since we've designed DNA to only operate using 
'link up' event notifications i.e., there is no dependency on any 'link 
down' event notifications.

> RFC 2461/2462 defines the IPv6 behavior for configuring a link with
> IPv6 information such as addresses, MTU, on-link prefixes, etc.  When
> a link goes down, conceptually one disables the interface and discards
> all associated config info. 

FWIW I take exception to this interpretation. There is nothing in 
2461/62 that leads me to believe this was the intent.

In fact, the default timers in the RFCs are quite long (90 minutes for 
default routers, and 7 days until an address becomes deprecated - 30 
days to become invalid.)
I don't remember exactly how we picked those values, but I have vague 
recollections that we didn't want the IPv6 addresses to accidentally 
disappear just because the router that advertises the prefix disappears 
for a few days. So I think the intent when 2461/62 was written was to 
err on the side of stability of the addresses.
Your assertion that the specifications should be interpreted as 
discarding everything on a 'link down' event doesn't match that presumed 
desire for stability.

> Q: what is a good model for what to do with the config information
> assocated with an interface that is going down? In some cases (e.g.,
> administrative shutdown of an interface) returning hard errors to
> upper-layer protocols is probably OK. But for wireless hiccups, it may
> not be.  And if I unplug a wired ethernet from the jack, should that
> automatically cause all connections using the address on that
> interface to fail? Not clear. There are certainly times when I wish
> that didn't happen...

I can recommend an Open Source OS and IPv6 stack that doesn't have that 
problem ;-)

> Proposal:
> 
> There are two types of errors that can be returned upon sending a
> packet:
> 
> hard error: means a failure of a type for which retrying is likely to
>             result in the same error, and upper layer protocols are OK
>             giving up.
> 
> soft error: a temporary failure occured, but retrying a short time
>             later may result in a different result. I would put "ICMP
>             dest unreachables" into this category.
> 
> 
> When a link goes down (i.e., via a "link down" event), soft errors
> should be returned when a) sending through the interface, or b) if
> using addresses associated with that interface. Soft errors should be
> returned from some short time. After (say) 2 minutes, hard errors can
> be returned.
> 
> Does this make sense?

It might make sense. But I don't see how defining these things more 
carefully, and making the above recommendations, would have any impact 
on how we specify the behavior of the DNA.

We can't rely on timely 'link down' events for DNA, hence it makes sense 
to only rely on 'link up' events, which is what CPL and the DNA solution do.

    Erik