> > * Where is show-interface? There's a lot of useful stuff that should > > be provided from this view, like the OVER relationship for IPMP > > groups, the list of addresses for the interface, the configured MTU, > > and so forth. > > > I have included a flags field for show-address and added show-interface > sample output in the doc. Isn't the list of addresses redundant > information when it can be obtained through show-addr <interface> ?
Possibly, but given that an IP interface without any addresses is not very interesting, it's a little unfortunate to have to use multiple subcommands. However, we may not have a choice given the constraints of the output format. > > * The "group" suboption absolutely must not be mandatory, and probably > > shouldn't exist at all. (Backstory: the group name should be the > > same as the interface name from Clearview IPMP onwards; cases where > > they're different are historical.) > > > How to specify which group an interface should be created under? Group membership is not a creation-time decision, but rather something that can be done at any time. If we wanted to draw parellels with the way dladm handles aggregations, we'd have the ability to assign an initial set of IP interfaces when the IPMP group is created, and then add-ipmp and del-ipmp subcommands to change the members of the group. Again, this makes sense if you model IPMP IP interfaces as their class of IP interface (i.e., there's also a create-ipmp). (I strongly urge you to consider this, as it is much more consistent with dladm than what has been proposed thus far.) > > * Seems to be a bunch of stuff glommed into the ADDRTYPE field, like > > ipmp-* and iptun-*. This really doesn't belong. > > > Isn't it useful to give some clue about the address type (with more details > available from other commands like ipmpstat? At least for tunnels, one at > least needs to know which address is on which end... or the display could be > > INTF LNUM ADDRTYPE STATE ADDR/MASK > tun 0 static up 10.0.0.1 -> 10.0.0.2 At least as far as IPMP goes, I'm not sure why an IPMP data address should be considered any different from any other type of IP address. IPMP test addresses deserve some thought. One thing to keep in mind is that as of Clearview IPMP, all IPMP test addresses live on underlying IP interfaces, and no other IP addresses ever live on underlying IP interfaces. That is, in general, the address configuration for underlying IP interfaces is uninteresting unless you are debugging some problem with IPMP test traffic. -- meem
