In addition to the responses that Sangeeta already provided in the issues file, the relevant parts of today's Inception review were:
* Regarding djr-00 and the general interaction with filtering hooks: There isn't very much ILB specific code in the ip kernel module itself. Only the hooks are part of the IP datapath code, and those don't comprise very much code. Erik Nordmark gave an overview of the reasons why filtering hooks aren't a good fit for load balancing. Specifically, there are requirements on the location of the hooks which the filtering hooks don't meet, as well as issues regarding the ordering of the hook callbacks. There are also semantic requirements of the load balancing hooks (the ability to change the next hop on output for example) that the filtering hooks don't provide in an efficient way. There were concerns raised that the lack of a general-purpose hook mechanism (despite the claims that there is already such a mechanism, it doesn't appear to be the case) is leading to exploding complexity in the IP implementation. Erik noted that the existence of a general-purpose hook mechanism would not necessarily address the complexity problem due to the sensitive nature of the interactions between the different hook consumers. Given this information, the committee asks the project team to clearly document the interactions between load balancing and other hooks such as filtering, observability, and Dtrace probes. * Regarding Jim Carlson's whiteboard level 0: requirements on VRRP Sangeeta Misra noted that there are two failover cases that will use VRRP, neither of which would require any feature beyond what is currently defined in the VRRP RFC. There are more details in appendix C of the design document. This project does not require "grouping" (a feature that was initially included in the VRRP case), nor the scripting interface that is being defined by VRRP. Sangeeta took an action-item to send mail to the VRRP case log to state the requirements that this case poses on VRRP. * Regarding Glenn Skinner's issue of "one more special-purpose uid": Do we really need another special-purpose user-id? The project team will investigate whether this is really needed, including the possibility of using "root" with dropped privileges. There should be advice in the opinion for this case to the appropriate management team on defining architecture suitable to allow projects to use user-id's other than "root". -Seb
