Renee Danson wrote: > On Sat, Nov 17, 2007 at 11:16:43AM +0000, Alan Maguire wrote: > > [...cut...] > My comments/questions: > > 1. Do we need so many control/policy services? In a perfect world, I > would like to see network/datalink:default and network/ip:default > handle pretty much all of the work that this proposal spreads out > among network/dlmgmt, network/config, and network/physical:default. > > network/datalink:default would start dlmgmtd, and create/enable its > instances as needed to match the available links in the system. > > network/ip:default would depend on network/datalink:default, and > would create/enable its instances as needed to match the existing > /etc/hostname.intf files. Individual instances would depend on > the corresponding network/datalink instances. > > I like this scheme for its simplicity. A potential problem would be > the challenge of eliminating existing services. I'm not sure how > feasible this is, even if their stability level is Unstable (as is > the case for network/physical:default). The "either nwam or default" > switch for determining which policy engine we're using is also > convenient. > > A reasonable middle-ground might be to just eliminate network/config; > I think its tasks could reasonably be folded into network/dlmgmt and > network/physical:default. > So, what we have now are network/datalink:default, network/ip:default, and network/physical:default/nwam:
Network/datalink:default will: + start dlmgmtd + create or remove 'network/datalink:<UV-name>' as requested by dladm or hotplugging event. Network/ip:default will: + create or remove (if needed) 'network/ip:<UV-name>' to match existing /etc/hostname.intf files (and as requested by ifconfig and nwamcfg?). Network/physical:default/nwam will: + be the policy engine + enable or disable each individual 'network/datalink:<UV-name>' or 'network/ip:<UV-name>', if it sees fit. Network/datalink:<UV-name> will: + set up or tear down the corresponding datalink (for vlan/aggr/iptun/vnic) based on the parameters stored in it + notify policy engine about the result of the operation Network/ip:<UV-name> will: + plumb or unplumb the corresponding interface + notify policy engine about the result of the operation Not sure if I'm summarizing it right, or not... :-P , please correct me, if I'm wrong. Max > Whatever we decide, it would be really good if we could coordinate > with the clearview/uv folks to make sure we agree on what the plan > is moving forward (primarily for service names) before they integrate > their new service. > > 2. The question you raised in section 1.3 of your write-up: are vnics, > vlans, aggregations, ip tunnels instances of the datalink service? > Or do we have separate services for each of those. There are some > naming questions in either case: if we go with a service per link- > type, I don't think it's appropriate to use "datalink" for just one > type (phys, in clearview terminology). And network/phys would clearly > be a bad choice! On the other hand, as you pointed out, if they're > all under the datalink service, you may not be able to tell what > type of links you have just by looking at the service list, as vanity > names may not convey the link type. > > My minimal service model that I described in item 1 definitely pushes > me toward one service for all datalinks. But I haven't come up with > a more compelling technical argument for that. > > 3. We need to be more careful about when ip instances are created and/or > enabled. We can't just do one for every link; it's quite possible that > two physical links are being aggregated with ip plumbed on the aggr link. > In this case, you have three links, but only one ip interface. > > I think this is pretty easy to solve, though; rather than making ip > instances map to all the links, we make them map to all the hostname.intf > files. > > -renee > _______________________________________________ > nwam-discuss mailing list > nwam-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/nwam-discuss >
