On 04/22/09 20:55, Erik Nordmark wrote:
>
> I though I saw some email saying we should do a global replace of "intf"
> with "if", which is a good idea.
Yes, we are doing that.
>
>> Note that
>> applying a persistent change that relies on the result of a temporary
>> command may fail with an error.
>
Thats correct. However handling missing objects (IP interfaces for our
case) is something that we were planning on doing in the next phase of
the project. In the first phase we will be displaying this error message.
> If we figure out how to handle missing objects, then we can remove that
> may.
> For instance, if I do
> dladm create-if -t bge0
> dladm create-addr -i bge0 10.1.2.3/24
>
> and then reboot it isn't much different than if bge0 goes missing (there
> is a difference between the datalink bge0 being missing and the IP
> interface being missing, but otherwise the same).
Once we start handling 'missing' interface case, we will re-apply the
above address after the interface reappears.
>
> With today's kernel there will be a difference with -f inet/inet6 for
> create-if, because we implicitly end up creating an ipif when we create
> the ill.
> But a future kernel might not do that. Hence the -f switch for *-if is
> something we probably want to remove down the road.
'-f' was provided for few customers who didn't want to create both the
interfaces in one shot. Further it's more of an option in the libipadm
'ipadm_create_interface()' library API. Once the future kernel is in
place we can get rid it.
>
> Section 3.2 says that about delete-if that
> All addresses configured on that interface will be torn down.
> That sounds counter-intuitive given the "missing" handling.
'delete-if' mimics the 'unplumb interface' logic which in the current
model removes all the addresses configured on the interface.
>
> Instead I think it makes sense to have delete-if return EBUSY if there
> are addresses. (Later we can have a -F which forces the interface to go
> missing even though there might be addresses that refer to it.)
> I don't think the EBUSY changes usability, because I expect the manual
> usage of ipadm would be around creating and deleting address objects.
OK.
So what's the real 'delete'? I am asking this because with what you are
saying there will be no way to delete all the addresses configured on
the interface. The user needs to delete each individual address and then
delete the interface.
>
> Section 3.4:
> Note that lo0 has different MTU for IPv4 and IPv6 today (so that 8k of
> payload fits with the different IP+TCP header sizes.) I think we should
> have the kernel move away from that, and until then ipadm somehow has to
> paper over that difference.
we will show lesser of the two MTU values. 8232
>
> Section 4.1. As I mentioned elsewhere, is the CIDR mask part of the name
> of the object or not?
> Thus can I do
> ipadm create-addr -i bge0 10.1.2.3/24
> followed by
> ipadm delete-addr -i bge0 10.1.2.3
> or do I need to specify /24 in the delete?
To keep the namespace uniform across create and delete we could have
/24, but it's not necesssary as such to specify /24 in the above case.
>
> [We have a separate thread on hostnames for create-addr and friends.]
>
> Section 4.4. I separately suggested show-addr output where the status
> doesn't have the admin up/down flag, but instead shows the RFC 4293
> address status.
> If the current kernel doesn't have IFF_UP set on an address, then
> representing that as the RFC 4293 notion of "invalid" would make sense.
yes we will use IPAddressStatusTC MIB values to specify the status of
the address and as of know it can have following values
(a) duplicate
(b) inaccessible (if interface is down or not operational)
(c) invalid
(d) deprecated and
(e) preferred
>
> Section 5.1:
> I'd suggested s/*-v6addrs/*-ipv6addrs/ globally.
>
Will change.
> We need to decide whether the label is globally unique or unique per
> interface, since that affects the set-addrprop and delete-ipv6addrs.
Thats correct. set-addrprop and delete-ipv6addrs would take "-i
interface" as a mandatory option. So having labels to be unique across
interface should work and we don't need globally unique 'labels'
We need "-i" option in set-addrprop to identify 'static' addresses. The
tuple <interface, address> uniquely identifies a static address.
>
> How will things work with the current kernel where I don't see to be
> able to change the token and have that change the link-local address? Is
> that a kernel CR that you will fix?
Ideally, we would like to have it that way. The ability to change the
token to change the link-local address.
Until then we might have to make the "token" an interface property
rather than an address property. It would mean that all the addresses on
that interface would use that token for auto configuration.
>
> Section 6 talks about a set of addresses for DHCPv4, but AFAIK for any
> given client-id/MAC address the server can only assign one address.
True. We will correct the design doc.
>
> Section 6.2: Will show-addresss display all the address objects, or do I
> have to do show-address, show-dhcp, show-ipv6addrs?
>
the idea was to have symmetry within ipadm subcommands. Every
'create-xx' command would have the 'show-xx' counterpart. However if
it's convenient for the system-admin to use one command to see all
the addresses, we can do that.
> Section 7.
> Instead of a "nolocal" property I suggest we name it "invalid". Or
> perhaps not - read on ...
>
> There is some overloading of IFF_ flags; ideally we'd like the kernel to
> be able to have a separate notion of the status of an address and the
> related onlink prefix. For instance, a duplicate address doesn't affect
> the validity of the onlink prefix. But the prefix (in ND) can go invalid.
>
> I don't know how far to take that separation. In its most extreme form
> there would be a separate <verb>-prefix, but that seems like overkill in
> the CLI. Note however that in.ndpd creates prefixes without associated
> addresses, in which case they have IFF_NOLOCAL set and a zero address.
> Thus it might make sense to have libipadm have <verb>-prefix functions
> for ndpd to use.
OK we will add them.
>
> In terms of show-addr things are a bit odd in that it pretends to show
> addresses, but when NOLOCAL is set it is really an address-less prefix.
> How do such things get reported by ifconfig in BSD?
True, it shows 'subnet' address. Is that OK?
>
> How about including an "auto" in stateful = {true, false}. auto would
> mean to do what the RA says, and would be the default. true would mean
> to do in independently of what the RA says.
>
> For symmetry having a stateless = {true, false} makes sense; if set as
> false no addresses are configured from RAs (but DHCPv6 would run
> independently.)
We will do that.
>
> Section 8:
> AFAICT an under interface can be added to a group in two ways:
> ipadm add-ipmp -i under0 ipmp0
> and
> ipadm set-ifprop -p groupname=foo under0
>
> Do those have identical semantics? For instance, what about the case
> when under0 is already part of a group? (Do I get EBUSY, or do they
> remove it from the existing group and then try to add to the specified
> group?)
> Note that doing a remove+add makes the failure semantics tricky. The
> remove might succeed, and then the add could fail. Wouldn't you want to
> add it back to the original group in that case? But that could also fail...
>
> Thus EBUSY sounds like better semantics.
> And perhaps we don't need to allow set-ifprop on the under.
We could return 'EBUSY' is the under interface is already part of
another group and for cases where we can reassign the interface to
different group, we will do it
So I guess we can have the 'groupname' intf-prop.
>
> Section 9.4. Let's not try to come up with arbitrary acronyms like
> frag_to and fragment; too short names are necessarily helpful.
>
OK
> In section 9 I don't see how per-interface things like ip_forwarding is
> set. Will that be done with ipadm set-ifprop?
Yes it will be done using 'ipadm set-ifprop'
>
> It would be good to separate out non-interfaces (from an ACR
> perspective). I believe section 9.3 falls in that category.
I think you meant ARC perspective. You are right we will separate that out.
>
> Section 11.2 talks about merging /etc/hostname* with ipadm peristent
> configuration, and I frankly don't know what that means.
> (It could be something complex e.g., detecting when /etc/hostname.bge0
> changes from 10.1.2.3 to 10.9.9.9 and moving that change into ipadm, or
> it could be something simpler.)
In the first phase we are not doing any migration of "/etc/hostname.*"
stuff to ipadm repository. Both the repositories will co-exist.
>
> From looking at docs.sun.com with Renee a while back it seems like the
> main (only?) documented use of /etc/hostname.<ifname> is various driver
> docs which suggests adding an IP address to that file.
there are several other places where it's mentioned.
(a) ifconfig manpage
(b) Solaris Administration Guide: IP services section
(c) Solaris Administration guide: IP tunneling configuration
>
> Things can potentially be added with an editor, or with
> echo 10.1.2.3 >>/etc/hostname.bge0
>
> If that is all we need to do we can do a few things:
> 1. If /etc/hostname*<ifname> doesn't exist or only contains comments, do
> nothing (leave it in place).
> 2. If /etc/hostname*<ifname> contains something other than comments,
> then take the non-comment stuff and propagate it to ipadm. (An issue is
> what we do if this fails due to ipadm not supporting something like
> modinsert.) Then replace the removed test with a comment that reads
> something like
> # This file has been obsoleted and its comments migrated to ipadm(1m)
I am not sure we could add 'comments' to those files. Lot of scripts
just cat the content of that file onto 'ifconfig(1m)'
#ifconfig `cat /etc/hostname.bge0`
If there are comments above command would fail.
>
> Can we realistically do this migration now, or do we need to wait until
> more of ifconfig is supported in dladm? (We'll always have things like
> modinsert which isn't likely to be carried into ipadm.)
I think we will have to wait for this migration as by the first putback
we might not have all the 'ifconfig' functionality. We will be having
the persistent store for 'ifconfig' and 'ipadm' and they need to
co-exist to begin with.
~Girish
