Renee Danson writes: > The major reason is that there is some state, and some actions, > that work on the single link: in particular, a wireless link needs > to connect to a wlan. The more simple wired analog would be waiting > for the cable to be plugged in. Once you have connectivity at the > link layer, though, the IPv4 and IPv6 interfaces need to be handled > independently, with their own flavors of information gathering, for > example. There may be a simpler way of making this distinction > which hasn't occurred to me; please jump in with ideas.
So, the issue here really is with handling the commands (or administrative operations) that would affect the entire link, rather than with the up/down notice, right? (If it were just up/down state, then continuing to pretend that IPv4 and IPv6 are separate would also work.) What other splits does NWAM potentially need to know about? For example, there's the split between VLANs and the link below: you can't have the VLAN configured and usable without the link as well. And there's the split between the link and the physical instance -- the former might be an aggregation of multiple physical instances, each with administrative issues. Getting into 802.1X is what concerns me here. The authentication issues there are at the lowest possible level -- they authenticate a "wire" -- and many of the other structures are above that level. If we treat 'link' as the lowest level, where it means both "thing that IP can plumb" and "thing that 801.X protects," then NWAM can't represent (for instance) VLANs. (Another wrinkle is wireless operation where one could in theory maintain associations with multiple APs ... but we can probably ignore that.) > 1.5. EV_WIRELESS_NET (EV_LINK_WIRELESS??) > > This event is generated internally when the daemon finishes > a scan on available networks using a wireless interface. This looks like an instance of a much more general issue to me. It's possible to scan the sub-IP link for all sorts of information -- including link partner (for aggregation) and perhaps even VLANs via LLDP. I'm not sure what to call that event -- it's some sort of "EV_LINK_INFO" bit. (I'd also shy away from the word "finishes" here. Scanning may never finish. Instead, I think it'd be nice to have something that reports interesting _changes_ in state. If some link layer designer wants to say that his link has a "finish" state, that's fine, but I think NWAM comes out as more flexible if it doesn't admit this.) > +------+ > >-----------------> |CLOSED| > | +------+ > | | > EV_LINK_DESTROY | EV_LINK_CREATE > | | > | V > | +-----------------+ > +------<----- |NWAM_LINK_PLUMBED| > | +-----------------+ > | ^ | > | EV_LINK_DOWN | | EV_LINK_UP > | | V > | +-----------------+ > +------<----- | NWAM_LINK_UP | > +-----------------+ Should EV_WIRELESS_NET or EV_LINK_INFO appear there somewhere -- perhaps going from NWAM_LINK_PLUMBED to NWAM_LINK_CONNECTED? (Or does it implicitly just loop-to-self everywhere?) > | +-----------------+ | > +------<----- |NWAM_IF_QUERYING |-------->---------+ EV_LINK_DOWN > | +-----------------+ | > | | | > | | EV_IF_INFO_KNOWN | > | V | > | +-----------------+ | > +------<----- | NWAM_IF_READY |-------->---------+ > | +-----------------+ | > | ^ | | > | EV_IF_DOWN | | EV_IF_UP | > | | V | > | +-----------------+ | > +------<----- | NWAM_IF_RUNNING |-------->---------+ > +-----------------+ How do we deal with configuration changes that don't involve EV_IF_UP/EV_IF_DOWN? Is there something that performs the NWAM_IF_QUERYING function essentially all the time? Or are we relying on external providers to do that and deliver EV_SIGNAL? If it's the latter, then why not just rely on EV_SIGNAL all the time rather than having a 'querying' state ... ? -- James Carlson, KISS Network <james.d.carlson at sun.com> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
