Hello Meem,
Thanks for your comments. Some of your questions on show-address and
show-interface will be answered by Vasumathi. Please see in-line
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).
Today we already have the facility of representing an interface using
two tuples. "-f <inet|inet6> -l <logical num>". We can possibly extend
this to achieve what you are saying.
* 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
Sure thing will update the document.
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).
In the case of 'dladm' every sub-command which created the data-link
determined the class of the datalink, i.e. create-vnic meant
DATALINK_CLASS_VNIC, create-vlan meant DATALINK_CLASS_VLAN, et al.
But in ipadm you have one subcommand 'create-interface' to create all
interfaces. Now how do we specify the class here? Do we want a command
option to specify the class? Also isn't this implementation specific
stuff which we would be exposing to Users.
* 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.)
OK. Will update the document.
* 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?
True and it will be removed.
* 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).
Sure. Given that for ipadm subcommands set-prop & show-prop, expect '-m
<proto_module>' we can clearly get rid of prefixes ip_ or tcp_ or udp_ .
Also we will have to think of better names for properties which give
away internal names like 'ire' in ip_ire_pathmtu_interval or
ip_ire_redirect_interval.
yes we will use dashes instead of underscores.
thanks
~Girish
_______________________________________________
networking-discuss mailing list
[email protected]
