On Tue, 29 Apr 2008 16:48:56 -0700
Renee Danson <Renee.Danson at Sun.COM> wrote:
> Attempting to merge the state machine information Michael sent out with the
> existing event descriptions on the daemon page[1] (primarily in section 7.4)
> brought up a few questions, which I've tried to summarize here. Any ideas/
> questions/comments would be appreciated!
>
> First, while I think the state machine diagram is generally correct, I'm
> concerned about it seeming to represent a continuous flow from LINIT to IFUP
> state. The objects nwamd is dealing with are NCUs; these may be of type link
> (which would transition from LINIT to LUP state) or of type ip (which would
> transition from IFDOWN to IFUP). If, for example, we are configured to use
> static ip addresses only and for same reason fail to assign the specified
> address to the interface, I don't think the interface ncu should transition
> to LUP state; it doesn't make sense for an interface to be in the Link Up
> state, really. I would be more inclined to make a separate interface ncu
> state machine that parallels the link ncu state machine. Not only does this
> make more sense (at least to me) for the existing physical links and inter-
> faces that we support, but it forces us to be a bit more conceptual in the
> way we look at and model this, and should make it easier for us to support
> different classes of links and interfaces in the future.
The two state machines are separated although not as clearly on the
diagram as they should be. I like having them on the same page because
an earlier version I wrote which had cross page links ended up being
harder to read then was necessary. But I've simplified things a fair
bit since then so maybe it makes sense to go back to that division.
I'll do them at least two different ways (same page but separated,
different pages) and see which one communicates the best.
>
> I also think the separation would force us to think clearly about what
> happens when we reach that end-state. What does the bigger policy engine
> need to do when a given NCU reaches its "up" state? If the NCU is a physical
> link that has an ip ncu on top of it, this should cause the ip ncu's state
> machine to begin, which is the specific case that this merged state machine
> shows. But if the NCU that reaches LUP state is a physical link that has
> several vlans configured above it, its arrival at LUP state should cause
> each of those vlan NCUs to enter the LINIT state and start making their way
> toward LUP.
>
> A second, more concrete issue is the mapping of events that we've defined
> in the daemon page to the events that are expected in the state table.
> There aren't any big conflicts, but some detailed points need to be ironed
> out:
>
> * IF_UP/DOWN vs. "#ip > 0" and "#ip == 0". The actual trigger we've
> talked about (and use in phase 0, for what it's worth) is reception
> of an RTM_NEWADDR/RTM_DELADDR message via the routing socket. Mapping
> each of these to an IF_UP/DOWN event doesn't make a lot of sense, as
> there might be more than one per interface. I could possibly see
> mapping each of these to an IP_ADD or IP_DEL event, and have the state
> machine accept the possibility of ADDs/DELs coming in while in the
> IFUP state, with the first ADD and last DEL (the one that takes the
> count to 0) signaling the state transitions. Or we could use a
> different trigger altogether, using communication with dhcpagent to
> learn about lease state (and something else to move us out of CSTATIC
> state).
I'll mod the table in the document to show this mapping.
>
> * We need to be more explicit about the source of the Config Refresh
> event that's referenced in the state diagram. I would think this
> would be triggered by a signal of some sort from netcfgd? We've
> also talked about a refresh of the nwam service doing this.
ok
>
> * The table in section 7.4 includes SCAN_REPORT and CONNECTION_REPORT
> events which nwamd sends to registered listeners (such as the gui).
> These might not need to be part of the state machine explicitly, but
> they do need more clarification.
ok
>
> * The NO_MAGIC event maps to the "DNE or Not Unique" line on the state
> machine diagram? I think there are probably other places where we'll
> transition to the PUNT state, and this transition should trigger the
> NO_MAGIC event. Also, the NO_MAGIC (and *_REPORT events) is a little
> different from the other events; in this case, a state transition
> causes an nwam-generated event, rather than an external event causing
> a state transition. We need to clarify that difference, I think.
yes, I have updates for these.
>
> Some of the differences are just word choice; we need to choose one and
> use it in both places:
>
> * Link Discovery/Remove on the state diagram map directly to LINK_CREATE
> and LINK_DESTROY in section 7.4.
>
> * Link Up/Down on the state diagram map to the two LINK_STATE events in
> section 7.4.
>
> Finally, a few nits about the state diagram: I'm not convinced we should
> leave the CDHCP state; the dhcp client will not give up trying to obtain
> a lease, and we take great pains in nwam phase 0 to avoid interfering with
> that (while simultaneously attempting to bring up alternate interfaces).
Agreed. I'll think a bit more about how to represent this.
> Also, there are three ways to leave CSTATIC: Failure no DHCP, Success no
> DHCP, Success DHCP needed; what about Failure DHCP needed? What we do in
> that case comes down to a policy decision; if the user has asked for two
> address acquisition mechanisms, and one fails, should we fail the interface
> entirely, or try to bring it up with only one of the mechanisms? I would
> lean toward the latter, which implies that the transition from CSTATIC to
> CDHCP should simply be "done; DHCP needed" or something like that.
ok
I'll send out an update tomorrow.
mph
>
>
> -renee
>
> [1] http://opensolaris.org/os/project/nwam/p1spec/daemon/
