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 > brussels-dev at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/brussels-dev >
