hi folks

In the process of fixing 10377, I've been thinking
a bit about how we need to distinguish between
responses to various link down cases. The main
questions are

- when do we unplumb IP? We don't want to
unplumb if the failure is transient, as is likely
the case with a wifi disconnect, but we do
want to unplumb when a link's priority group
is unselected, or when a link is wired and has
been unplugged, since that's a user-driven
act of deselection.
- what state/aux state should the IP NCU be in?

Here's my proposal:

- if a wired link goes down, unplumb IP and
mark the IP NCU as offline/conditions not met
and unplumb IP. A cable has been unplugged,
so it signifies intent. This is what happens
today.
- if a wireless link that was connected goes
down, mark the IP NCU as offline/conditions
not met and _do not_ unplumb IP. The only
complication here is that when handling
the IP NCU offline event, the state machine
would have to examine the state of the underlying
link to determine whether to unplumb or not.
We'd unplumb if the underlying link was offline
(as would be the case if another priority group
activates), but not if it was wifi and offline*,
since in the latter case we're still trying to reconnect.

So this would change behaviour in that
link down events for wifi link NCUs would be
propogated to IP in terms of state changes,
but we'd stop short of unplumbing IP. Sound
reasonable?

Thanks!

Alan

Reply via email to