Peter Memishian wrote:
> 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.
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> ?
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.)
How to specify which group an interface should be created under? I agree
that "group" suboption must not be mandatory while creating the group
itself.
* 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.
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
(though the parsable output then becomes messy).
* 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.
Included in the sample output.
Thanks
Vasumathi
* 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
_______________________________________________
brussels-dev mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/brussels-dev
_______________________________________________
networking-discuss mailing list
[email protected]
