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

[Mohan.Parthasarathy@nokia.com]

Erik,

Is the following scenario possible ?

1) Host receives a link down event. Does not do anything.
2) Host attaches to the new link. Link UP event happens
   slightly late or the event has not propagated completely
   through the system. Meanwhile you are able to send and
   receive packets. This is not good because you are not
   in the optimistic state yet and you are on the new link.

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