Hi all, This is a summary of the current feedback and discussions for the first round design review, and also a reminder that the comments for the design review are due by the end of this week, i.e. November 7th.
Lots of people provided valuable comments and advices which are much appreciated. The document is updated according to the comments. http://www.opensolaris.org/os/project/vrrp/vrrp_design.pdf Although some issues haven't got conclusion and are still being discussed, they are revised in the document based on the current opinions from the project team for further discussion. Note that in order to provide more detailed information, the CLI/API specification is appended to the design document for detailed review. Below are summaries for review comments and opinions: 1. Utilizing SMF instances for configuring VRRP instances/groups. (jbk, darrenr, calsonj) Still being discussed. There is no issue from the configuration perspective. But the idea of utilizing SMF dependency for protecting services has the issue that it would be a mutual dependency between vrrp and the service to be protected. See section 3.5. 2. Location of unix socket file. (jbk, meem, calsonj) Opinion accepted that boot sequence should be decided first. Since vrrp will have dependency on network/routing/ndp, the decision is the unix socket file will be put in /var/run. See section 3.2, 7.1. 3. Information about the VRRP SMF service such as properties, dependencies, and methods should be in the doc. (darrenr) Accepted. See section 3.2. 4. Confusing terminologies need clarification. (sowmini) Accepted. Clarifications are added for VRRP virtual router (Section 3.1), vrrpadm command (appendix), primary IP address (Section 7.3), and IPMP (Section 8). 5. Define new type for storing vrrp IP address. (sowmini, kcpoon, meem, nico, darrenr, calsonj) Accepted. A new type vrrp_addr_t will be used. See section 5.1, 5.5. 6. More detailed introduction for data structures, algorithms, locking, etc. (calsonj) Accepted. Interface specifications are appended to the document as appendix. 7. The benefit of inventing VRRP group and related issues. (calsonj, sangeeta, darrenr) A detailed introduction on VRRP group is added to the document. See section 3.4. Further discussion maybe needed for VRRP group. 8. Should use in.ndpd to handle Router Advertisements for VRRP. (calsonj, seb) Accepted. See section 7.6. 9. How does VRRP protect other services? (calsonj) See #1. 10. Information on registrated scripts. (calsonj) CLI/API specifications are added to the document with the detailed usage of registrated scripts. See appendix. 11. How does extension to the protocol (section 7.6) work? (calsonj) The section is revised to explain how does the non-router extension work. See 7.6. 12. Necessity of using a separate thread for the timers and the possibility of utilizing libinetutil. (calsonj) Accepted. The libinetutil can be utilized for managing timers and sockets. See section 7.7. The original design was storing "relative" timestamp in the timer queue. Thus it needs to use alarm()/ualarm() to invoke timers so that it could tell how much time is left when the timer is interrupted. Using the timeout parameter of poll(2) is unable to handle this issue. But by migrating to libinetutil which stores "absolute" timestamp in the timer queue, it is easy to find out how much time is left and then poll(2) can be used using the timeout parameter. Thus a separate thread is not needed. 13. Clarification for privilege. (calsonj) Section 9.1 revised. Thanks, Yifan _______________________________________________ networking-discuss mailing list [email protected]
