Summarizing a discussion that I just had with Jim: > jdc-1 3.1.1: why doesn't create-if automatically do what up-if does? > Doesn't that defeat the purpose of having a permanent store? > (If "create-if" is done implicitly by some of the other > commands, such as "create-addr", does this mean that "up-if" > is skipped? Or does it implicitly do both?) > > jdc-2 What is the difference between "delete-if -t foo0" and > "down-if foo0"?
In the initial proposal, we had the following create-if [-t] delete-if [-t] where the '-t' would operate in the ifconfig mode, i.e., 'create-if -t' would create (plumb) the interface but not consult ipadm.conf, and 'delete-if -t' would delete (unplumb) the interface from the running-config, but leave ipadm.conf untouched. However, this (esp. the 'delete-if -t') seemed to generate a lot of confusion, and it was pointed out that we have "up-<object>" and "down-<object>" commands for all the other objects (e.g., aggr, vnic, iptun), with the up-if 'instantiating' the object (i.e., create-if without -t in my model) and down-if doing the equivalent of "delete-if -t". In the interest of conforming to the existing convention, we added the 'up-if' and 'down-if'. I personally would prefer to jut use > jdc-3 4.1: why do temporary addresses on permanent interfaces > generate a warning? Isn't that the most likely usage? > (Similar comment in 4.2 about deleting a temporary address on > a permanent interface.) the motivation behind generating the warning was to be prepared for some subsequent (e.g., addrprop) change being persistently applied to the temporary address. However Jim pointed out that this is needless (the persistent addrprop on the temp address can fail or generate an error in my example). > jdc-4 4.1: how do I manipulate static addresses that are configured > in symbolic (name) form? We debated about this at some length on opensolaris. See http://mail.opensolaris.org/pipermail/brussels-dev/2009-April/001508.html The conclusion of that thread was that, at least for the first component, the "vanity name" of a static address was just the dotted decimal address itself. One additional user-pleaser we can add here is to have libipadm search (only) /etc/inet/hosts and /etc/inet/ipnodes for mapping dotted decimal addresses to hostnames. (See also jdc-5) > jdc-5 4.1: if I don't use "/n" (CIDR notation), what happens? Error > or netmask lookup? The current proposal is that we would return an error, since we want to move away from the class-full addresses, pulling out netmask from /etc/netmasks etc. But if we want to allow vanity-naming of static addresses, then we'd have to pull the netmask out of the nsswitch.conf ordering of netmasks. > jdc-6 Is create-ipv6addrs for IPv6 and create-dhcp for IPv4 really > the best factoring? How would IPv4 link locals fit into such > a scheme? Why is DHCPv6 not administered using the *-dhcp > commands? create-ipv6addrs was created based on the motivation that, for IPv6, Stateful (dhcpv6) addrconf is something that really builds on IPv6 address autoconf, so that dhcpv6 doesn't really stand up on its own. As Jim and I discussed, it would be nice to have symmetric commands for ipv4 and ipv6, and also fit IPv4 link-locals (which we can't auto-configure today). So one suggestion was to have ipadm create-auto [-f <inet>|<inet6>] ... and eliminate create-dhcp For IPv6, this would do the same thing as "create-ipv6addrs" in the design doc. For IPv4, this would do IPv4 LLA or DHCP. > jdc-7 5.1: why not have labels for both static and automatic > addresses? See previous discussion for jdc-4 > jdc-8 It would be good to see some more worked examples. I *think* yes, we'll make sure we have this for commitment review. > that in order to create an IPv6 static address, I need to do > something like this: > ipadm create-if -f inet6 bge0 > ipadm up-if -f inet6 bge0 > ipadm create-ipv6addrs -i bge0 myv6local > ipadm create-addr -i bge0 2005::1/64 not so, for pure static address configuration, you would have to do > ipadm create-addr -i bge0 fe80::1234/10 > ipadm create-addr -i bge0 2005::1/64 > rather than this: > ifconfig bge0 inet6 plumb up > ifconfig bge0 inet6 addif 2005::1/64 up > Is that right? The equivalent of the above (where you are adding a static address to the auto-configured prefixes) would be ipadm create-ipv6addrs -i bge0 myv6local ipadm create-addr -i bge0 2005::1/64 > jdc-9 What's the difference between "tentative" and "optimistic" > DAD? And where do the IFA_* flags come from? Optimistic DAD is RFC 4429. Note that the IFA_* flags are there to provide a wrapper to some of the implemenation peculiarities (e.g., around IFF_UP) in the library. These are not flags in the kernel. To figure out something like "tentative", libipadm may need to do extra computation (including new SIOC* ioctls) to figure out the state of the address. > jdc-10 I love the idea of getifaddrs(), but object to putting it in > libipadm. We don't need that barrier to portability. This > belongs in libsocket/libxnet or (feeling optimistic for the > future) libc. Plus, a Committed interface floating in the > middle of a Consolidation Private library sounds like a > mistake. > > (In the description of this call, you say ~IFF_UP, but I think > you mean that only IFF_UP addresses are returned.) The design doc has a bug when it says this goes into libipadm. The getifaddrs() function will be delivered as part of libsocket (where Solaris has traditionally delivered the BSD socket API). We shall correct the design doc. > > jdc-11 How will the overlap between 'ipmpstat' and 'ipadm show-ipmp' > be handled? Today ipmpstat has the unfortunate task of displaying all the ipmp state, due to lack of better alternatives. After the delivery of the ipmp component of ipadm, ipmpstat will only display statistics. ipadm show-ipmp will display ipmp state (such as interface membership, state etc.) > jdc-12 14.2: why not just have persistent data loaded automatically > (per jdc-1) and allow legacy methods (if used at all) to > override? The conditional logic described here sounds hard to > use (and implement). > > jdc-13 How does DR interface with this? (Is there a DR rewrite?) > What becomes of "ifconfig configinfo"? When we discussed these two issues, it emerged that there seems to be some fundamental confusion about what is being reviewd for this case, and what's being partitioned off for subsequent components of the Umbrella case... to clarify, this case covers interface creation, static address managment, dhcpv4, dhcpv6 and IPv6 auto-configuartion, tunables (both ndd and per-if). jdc-12 and jdc-13 relate to how we will interact with /etc/hostname.intf until the subsequent components (e.g., ipmp) will be delivered. The proposal in the design doc is to first parse /etc/hostname.intf, apply those settings and then apply any ipadm.conf settings. In the case when there is a conflict (e.g., someone is setting an address via /etc/hostname.hme0 and there's also ipadm.conf info for addresses on hme0), the sequence listed will end up applying /etc/hostname.hme0* settings first, and the ipadm.conf settings second, so that the end-result will be that all the requested addresses are configured (if the address is duplicate, the kernel will fail to add the second copy, but one copy of the address will be present). Note that a separate component of this umbrella case will provide a script that converts /etc/hostname.intf configuration to ipadm.conf configuration, to aid upgragde/installs. > > jdc-14 Is there a separate project to update Sun Cluster to use the > new interfaces? We are working with the Sun Cluster group so that they move in step with the various Brussels components. See CR 6843030 which tracks this work. > jdc-15 The new "state" property seems to involve partial success and > partial failure semantics. What happens if I set "up" but not > all of the addresses come up? If some or all have failed DAD, > what state do I see when I read that property? (This looks > like an attempt to recapture BSD semantics, but I'm unsure if > it works ...) You are correct. The only state we can capture correctly is the IFA_* state (for the address). The per-if "state" property should not be present. > jdc-16 Using the name "routing" for the IP forwarding control is very > confusing. Either use "router" (to align with IFF_ROUTER) or > use "forwarding" (to align with routeadm). (I prefer the I think "forwarding" works best.. it's similar to what's used on other OS'es like BSD. > jdc-17 How does "icmp_respond" work? Can I control just one type or > are there multiple instances of this parameter on an > interface? (If there are multiple instances, then how do I > refer to each instance?) The "icmp_respond" is a short-hand for setting a class (responding to icmp requests) of properties and is not a single property itself. However as you point out, the short-hand needs more work to symmetrically display the settings without loss of information. We'll get back to you on this one, but possible models to follow are like those suggested in CR 6804384 or the one used for managing privileges. (Also this should be a per-if property). > jdc-18 Why are some parameters (forward{,6}_src_routed) broken out > for v4 and v6, while others (icmp_err_interval) are not? forward*src_routed should follow the same semantics as the forwarding tunable itself (which is settable per interface). So this sounds to me like something that should be a set-ifprop, with a "-f" flag controlling whether it applies to V4 or V6 packets for that interface. > > jdc-19 I suggest leaving out "multidata_outbound" and "lso_outbound" > as examples of those corner case tweaks that needn't be in the > committed set of properties. "Real" LSO should just work, and > shouldn't need administrative fiddling. Such fiddling is > really an internal design matter, and not (as with the other > controls) a matter of on-the-wire behavior. Ok. > jdc-99 Nit: subcommands listed in 20q don't seem to match design > document. I think that Girish was just listing the "show" commands in the 20q, but we can make sure we list the full set for commitment.
