Hi, Following is the list of questions and comments:
General Questions: ============== - What's the current release model for this feature opensolaris and Nevada? - Will this feature be available in the S10 updates? - What's the timeline for this feature availability? - Will the backward compatibility be provided? - Any plan of dropping any ifconfig flags or ndd properties as part of this project? IPMP Interaction: ============== - ipmp option is only possible with create-option, so how do we bring an existing interface "under" ipmp group. - If the /etc/hostname.adp mechanism is being replaced, that means going further the only mechanism to create the ipmp groups is with ipadm command. If I understand correctly, whether we want the changes to be persistent or not, it will be just ipadm command. Right? - Does it mean ipadm command will be used to create the ipmp groups and ipmpstat is used to get the status or can we use the ipadm command to get the ipmp group status as well? - May be this is clearview specific, but with the new ipadm command how do we customize the name of psuedo interface? With Clearview we do that by creating the file with the /etc/hostname.<psuedo_interface> In Sun Cluster, we do auto creation of ipmp groups by updating the /etc/hostname.<adp> file and running the ifconfig command to create groups for an existing interface, so answers to above questions would be useful. It would be good to clarify this in the design doc for reference. ipadm library: ============== - As I understand the ipadm command can be used in place of current ifconfig command. - Can the ipadm library be used just in place of ndd to set/get the protocol properties or can this also be used in place of current ioctls for interface specific operations like plumb, unplumb etc? In other words, are you expecting the applications currently using the ioctls to plumb, unplumb, addif etc operations migrating to the new ipadm libarary calls? - Expecting that this project will not have any impact on kstr_ioctls. ifconfig vs. ipadm: -=============== - ipadm command description in the design doc did not include any flags related to zones. How do we attach a zone to an interface? Today using ifconfig we can do something like below: ifconfig <interface> <address> zone <zonename> How do we achieve this with the new ipadm command? - Did not see any flag for the netmask? How do we set the netmask using the ipadm command? - seems like ipadm semantics are different compare to ifconfig with respect to plumbing the v4 and v6 as default instead of just v4 as the default. Is this right? If yes, then if user is interested in only v4 version then need to restrict with -f flag. What's the motivation for change? Do we have more customers now who are using the v6? Otherwise, it looks unneccesary to use the extra flag. - Question related to Modify/Add address section: Is specifying the -l num will be same as ifconfig ce0:1 <address> Also is not specifying the -l is same as ifconfig ce0 addif <address> So how do I change the existing IP address for an interface? In other words, if my ce0 is plumbed currently with let's say x.x.x.x and want to change that to a new IP address let's say y.y.y.y? - For the address options, type = static. Don't remember seeing this type in ifconfig context, is this a new word that we are using in ipadm context? Property persistent Mechanism ============================= - In section, 2.6.1, it was mentioned that by default, the set-prop options are stored in the persistent storage: >The setting will >be persistent by default and applied when the interface is recreated with ipadm create-interface But section 2.6.3 mentions that the properties can be restored via init-prop: ># ipadm init-prop >which will consult the persistent store and re-apply global properties Does end-user ever required to use this init-prop option? Or is this only useful for the new process "netstart" during the reboot? - Section 4.1 mentions applications or the ipadm requires the file_dac_write privilege? By default is this privilege available to root? - Is the /etc/ipadm/ipadm.conf a directory under which there will be interface specific files? Otherwise how does the interface specic config be stored? - Let me reiterate the property restoration process as I understood and correct me if there is anything incorrect: During the reboot, the new process "netstart" will be started which will run the ipadm init-prop command to initialize all the global properties. After that when the net-physical script which I believe is an SMF service gets executed, it runs the ipadm show-interface to get the list of interfaces. For each interface from this list, it refers to the /etc/ipadm/ipadm.conf/<interface> file to read the config and creates the intefaces with this information. If the /etc/ipadm/ipadm.conf/<interface> does not exist, then it looks at the /etc/hosntame.<inteface> and creates the new <interface> specific file under ipadm.conf directory to be used for later reboots. Based on the above understanding have following questions: 1) How does the new process "netstart" be started? Will this be part of an existing SMF service or will there be a new SMF service? Based on that, Sun Cluster might need to add a new dependency on this SMF, if it's not already covered by the existing Solaris dependencies. 2) Are the global properties which will be restored by init-prop also stored in the /etc/ipadm/ipadm.conf directory? 3) In section 4.2, third bullet mentions that if the /etc/hostname.adp files are detected then the subsequent SMF service will update this configuration information to input in the ipadm store for the next reboot. What exactly does it mean? Does it store the config information from the /etc/hosntame.<adp> file to /etc/ipadm/ipadm.conf directory to be used by next reboot? Then what happens if user has changed the /etc/hostname.<adp> file in between? In other words, how does the /etc/ipadm/ipadm.conf will be in sync with the /etc/hostname.adp files? It would be good to summarize this flow or better add a flow diagram for the above in the design doc. Thanks, Prasanna Kunisetty On 03/20/09 08:28, Girish M G wrote: > We are inviting everyone involved with networking to review the design > document for Brussels Phase II aka /ipadm(1M). /The document is here: > > http://www.opensolaris.org/os/project/brussels/files/brussels2.pdf > > Comments, from the community, on the first phase of the design review > are incorporated in the latest design document. Also we have updated > the document based on the few technical/architectural discussions that > took place in the community. Thank you guys. > > Quick highlights on what has changed: > (a) /ipadm(1M)/ CLI changes, persistence & temporary operations > handling (section 2) > (b) library data store access (section 4.1) > (c) legacy support of 'ndd' tunables (section 3.1) > (Note: Everything other than Section 1 has changed) > > The comment period begins today and ends on the 31st of March. We > would really appreciate your comments in the timely manner :-). > > You can browse our project web page for some reference materials. > http://www.opensolaris.org/os/project/brussels/ > > thanks > ~Brussels Team > _______________________________________________ > networking-discuss mailing list > networking-discuss at opensolaris.org
