On Wed, 2008-11-05 at 03:02 -0500, Peter Memishian wrote: > Folks, > > I've updated both the High-Level Design Document and the "PSARC 20 > questions" in preparation for PSARC Commitment; the latest documents > are linked off of http://opensolaris.org/os/project/clearview/ipmp/ > > Specifically: > > http://opensolaris.org/os/project/clearview/ipmp-highlevel-design.pdf > http://opensolaris.org/os/project/clearview/ipmp-20q-commitment.txt > > These materials are quite similar to what we originally went to inception > with last year; I've summarized the key changes below. I will ask PSARC > to vote on the case shortly (within a week), so prompt comments are > appreciated.
The changes look mostly straightforward. I just have a couple of questions: > * Section 4.2.3: To improve observability, ipmpstat now separates IPv4 > and IPv6 multicast nominations, and identifies IP interfaces that > have been taken offline due to hardware address conflicts. In > addition, the "disabled" link state proved unnecessary and thus has > been removed. Regarding the IPv4/IPv6 multicast nominations, I'm trying to rationalize and verify with you what happens when different underlying interfaces are picked for IPv4 and IPv6 multicast respectively, and the "allmulti" group is joined for each. I think what ends up happening is that (because DL_PROMISC_MULTI is enabled on two interfaces) the link-layer receives duplicates of all multicast packets (one on each link), but the underlying drivers (or GLDv3) each filter out either IPv4 or IPv6 multicast depending on the sap of the respective DLPI client that enabled DL_PROMISC_MULTI, so ip doesn't end up receiving multicast dups. If that's the case, there could be a potential optimization (if one were somehow concerned with multicast routing performance, ha!), and that would be to have a single phyint_t nomination for the allmulti group, so that only one link enables DL_PROMISC_MULTI. I don't think I'd consider doing that since the code works as I described above (right?), and I don't believe that this affects performance in the vast majority of cases. > * Sections 4.6.1 and 4.6.2: The spec is now much more thorough in its > explanation of how IPv6 link-local data and test addresses will work. Very clearly explained, thanks. > * Section 5.14: To simplify the implementation, only SIOCSLIFUSESRC > will fail in conjunction with IPMP; the other ioctls (SIOCGLIFUSESRC > and SIOCGLIFSRCOF) now trivially succeed. Can you remind me why SIOCLIFUSESRC is incompatible with the new IPMP interfaces? -Seb
