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

[Thomas Narten <narten@us.ibm.com>]

Erik Nordmark <erik.nordmark@sun.com> writes:

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

Right. I just started thinking about it as I was trying to understand
what information is associated with an interface when one gets a 'link
up' (i.e., there are some unstated assumptions being made in the DNA
drafts I think, and I'm trying to flesh them out). It wasn't
immediately obvious that (by default) any information would be
associated with an interface.

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

Fair enough. I'm definitely not saying that I think this is what
should be doing.

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

Ah.. but a router going away (with an apparently still working link)
strikes me as different than a link that goes down -- and for which we
get an explicit indication from the LL that the link has gone
down. Note: maybe ten years ago when we were doing the spec twisted
pair ethernet was a lot less ubiquitous and the notion that one got
'link down' indications from the interface was a lot less
common. Wireless was still a dream... :-)

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

I don't mean to assert that. I do think that we (the community as a
whole) didn't think about this part in a lot of detail.

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

What I'm trying to get at is: what assumption can be made about the
configuration information that is already associated with an interface
(i.e., from 2461/2426) at the time a 'link up' event takes place?

I guess the obvious model is that whatever IP configuraiton
information  was associated with the interface before the link up
(subject to any lifetime considerations) is assumed to still be
associated with the interface.

But think about this just from a 2461/2462 perspective (i.e., before
we started thinking about DNA). What would happen in practice in a
pre-DNA world?  Suppose an RA is received on an interface, but it
indicates a new prefix that one has never heard of, and it doesn't
include any prefixes currently associated with the
interface. Shouldn't the old information be thrown away (since we
might be at a new link). It needs to be discarded at some point, not
because it has expired, but because it doesn't apply to the current
link anymore. some of that informaitn will stay around for a very long
time if one only looked at Lifetimes. [I don't recall any of this
being discussed in 2461/2462.]

It seems to me that some assumptions have to be made in order to
define what it is that DNA is supposed to do, or, what state it
assumes as it gets invoked.

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

Agreed that we can't _rely_ on them. But there are presumably cases
where they will occur. How should they be handled? Just note them ,
but more-or-less silently ignore them?

Thomas