> > http://opensolaris.org/os/project/clearview/ipmp-highlevel-design.pdf > > Meem, some comments:
Thanks for the feedback. > - Section 3.10: page 10: last line should say "which will be set to > the _smallest_ mtu supported by".. either that, or the example > on the top of page 15 is incorrect. Yes, that should be "smallest" -- fixed. > - Section 3.13: is there a legacy/backward-compat reasons to continue > to support mcast ioctls on the underlying interface? e.g., are there > public domain apps that want to do things like IP_MULTICAST_IF with > the underlying interface, or do a JOIN with the test address, > for perverted reasons that we need to support? We support it primarily because in.mpathd uses IP_MULTICAST_IF. I don't anticipate that normal applications will use it. > - Page 18, second paragraph missing "them" in the line > > "NOFAILOVER will be hosted on the (lone) underlying interface, > enabling <them> to be used for test traffic." Yep, fixed. > - meta-question: why does Sun Cluster need the singleton group when > anon group support is available? An interesting question. It seems like the anonymous group could cover their need, provided that there was a way to set it on a per-interface basis (right now, it's an all-interfaces-or-none thing). Another difference is that with singleton, each interface has its own group and thus its own health, whereas with the anonymous group, all interfaces share the same "anonymous" group (and thus even if an interface fails, the anonymous group is still considered "healthy"). But assuming that they monitor the interface (rather than the group) health, that shouldn't matter much. I think converging these modes is worth pursuing in the future, though we will need to coordinate it with Sun Cluster (e.g., since today they place interfaces into a group). > - ECMP will be much simpler with this model: in the current IPv4 > stack does a simple ire_round_robin, but for default routes only. One > of the main reasons for not extending this in Surya to deal with > general network routes was the concern about interactions with ipmp. > With the introduction of the ipmpN interface, feels like some of this > should be simplified. Good to hear :-) I've posted an updated document (now at 1.8.1). It also includes some other minor corrections to the ipmpstat and zone ioctl sections. Same path as before: http://opensolaris.org/os/project/clearview/ipmp-highlevel-design.pdf -- meem
