> We are inviting everyone involved with networking to review the design 
 > document for Brussels Phase II aka /ipadm(1M).  /The document is here:
 > 
 >     http://www.opensolaris.org/os/project/brussels/files/brussels2.pdf

I'm under the gun for some other work so apologies if in my quick scan of
the document I missed anything that resolves some of the matters covered
below.  Note that this is far from exhaustive and intended to get the
discussion rolling.

Some high-level comments:

  * As we discussed in another thread last week, it would be a real shame
    to let the current "interface duality" survive the ipadm transition.
    That is, right now ifconfig has a notion of separate IPv4 and IPv6
    interfaces that have identical names.  I believe this is the wrong
    model.  Instead, there should be one administrative IP interface
    object which can have any number of IPv4 and IPv6 addresses.  For this
    to work without having a ripple effect, I think you'd need to then
    make the logical index field be a tuple of the address family and type
    (e.g., v4:2 and v6:2 would be distinct logicals).

  * For dladm, we generally chose to abbreviate subcommand names - e.g.,
    we have add-aggr, not add-aggregation.  I think we should do the same
    thing here -- e.g., address -> addr, interface -> if

  * 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.

Some low-level comments (not exhaustive):

   * Not sure why "ipmp" is an interface sub-option.  The model I'd expect
     is that every IP interface has a "class", just like every datalink
     has a class.  There are at least two classes (ipmp and "normal") and
     there may be more depending on how we want to model things (e.g.,
     other things that "act different" include point-to-point, tunnels,
     loopback and vni).

   * 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.)

   * Not sure why tunnel src/dst are specified specially.  If these are
     the outer IP addresses, why are they not handled by add-addr?  If
     these are the inner IP addresses, why are they here at all given
     dladm *-iptun?

   * Seems to be a bunch of stuff glommed into the ADDRTYPE field, like
     ipmp-* and iptun-*.  This really doesn't belong.

   * There's a lot of information missing from the show-address view that
     can matter (IFF_TEMPORARY, IFF_PREFERRED, IFF_DEPRECATED, ...) but
     that isn't displayed.
     
   * Some thought needs to be put into the property names.  For instance,
     the document has both ip_ttl and ip_def_ttl but really the "ip_" is
     totally unnecessary given the context of the command.  Further, given
     that the general syntax for ipadm uses dashes I'd encourage us to use
     dashes here too (yes, mistakes were made in this regard with dladm;
     we're looking to fix those).

--
meem

Reply via email to